-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v9.x backport] test: fix require-deps-deprecation for installed deps #18077
Conversation
Test test-require-deps-deprecation.js was failing when user already had node installed with acorn in require.resolve range. Modified test to acknowledge the possibility and throw only if acorn is found in the deps directory. Also changed the deprecation test for v9.x: common.expectWarning was failing because the required deps now throw ReferenceErrors when not properly called internally in the right order. PR-URL: nodejs#17848 Fixes: nodejs#17148 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
I don't know if this is the correct way to adapt this test, but I figured it was the best. For the explanation: (Obviously though, I can't run the CI job as explained in the backporting guide as I don't have permissions) |
} | ||
}; | ||
|
||
assert.throws(throwingModules, ReferenceError); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem correct, it should be inside the loop or it will only test the first require()
call that throws.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, but that's one of the problems: I'm not sure every require
throws.
From what I've seen, some tools throw (typically v8/tools/profile
), some other don't. Should I remove every module not throwing? Or is there a better way to test this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure either, let's ping the reviewers of the original PR.
cc: @TimothyGu @cjihrig @Trott @jasnell
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The checking for ReferenceError
appears to only check that require(m)
is the wrong way to include two of the modules in the list. The correct way to include (for example) 'v8/tools/tickprocessor'
is not require('v8/tools/tickprocessor')
but rather something like eval(process.binding('natives')['v8/tools/tickprocessor'])
when run with --expose-internals
.
I think the test for ReferenceError
should be removed entirely. The important thing to test is that a DeprecationWarning is being emitted, using common.expectsWarning()
or whatever it is that's in the common
module for that. I'm going to change my review to Request Changes for that. Sorry that I missed that on first review!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, wait, I didn't approve it or even review this until now. It's only 8 hours old. Never mind. But still, the comment stands: Yeah, that should be changed. Sorry if I'm directly or indirectly responsible for that code in the first place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lpinca Thanks. I don't see a ReferenceError
check in this file on the master branch so now I'm even more confused. :-D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following @cjihrig 's comment I'm inclined to close my PR. It does not seem needed in v9 in fact.
However I wonder, is at least the acorn
testing usefull? If no, I'll close this and ask for a 'don't land on v9' tag to be added on the original PR.
} | ||
}; | ||
|
||
assert.throws(throwingModules, ReferenceError); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The checking for ReferenceError
appears to only check that require(m)
is the wrong way to include two of the modules in the list. The correct way to include (for example) 'v8/tools/tickprocessor'
is not require('v8/tools/tickprocessor')
but rather something like eval(process.binding('natives')['v8/tools/tickprocessor'])
when run with --expose-internals
.
I think the test for ReferenceError
should be removed entirely. The important thing to test is that a DeprecationWarning is being emitted, using common.expectsWarning()
or whatever it is that's in the common
module for that. I'm going to change my review to Request Changes for that. Sorry that I missed that on first review!
@Trott That’s why I changed the test in fact: no warning is emitted, because an error is thrown as they are not properly required. The test was failing because no warning was emitted, so I removed the try-catch and got errors saying that CodeMap wasn’t defined in profile.js . It seems this test is pointless if these deeps cannot be required without throwing. Or is there some other way? |
Ah, yeah, you'll need to remove any modules that aren't deprecated in 9.x. If that means removing all of them, then yeah, we don't need the test in 9.x. :-D |
Made some more tests and I can confirm, the test on acorn still seems relevant, but I don't know if it's worth keeping it. As for the other tests, no v8/tool seem to be emitting warnings on v9.x so I just dropped them. |
Just a small up. |
@nodejs/testing |
Ping @nodejs/lts |
Why is this targeting v9.x instead of master? |
This is a requested backport (#17848 (comment)) of a PR that has already landed on master. I've amended the PR title so that it is clearer. |
Test test-require-deps-deprecation.js was failing when user already had node installed with acorn in require.resolve range. Modified test to acknowledge the possibility and throw only if acorn is found in the deps directory. Also changed the deprecation test for v9.x: common.expectWarning was failing because the required deps now throw ReferenceErrors when not properly called internally in the right order. Bacport-PR-URL: #18077 PR-URL: #17848 Fixes: #17148 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Landed in b5752ee |
Thanks! |
Test test-require-deps-deprecation.js was failing when user already had
node installed with acorn in require.resolve range.
Modified test to acknowledge the possibility and throw only if acorn is
found in the deps directory.
Also changed the deprecation test for v9.x: common.expectWarning was failing
because the required deps now throw ReferenceErrors when not properly called
internally in the right order.
PR-URL: #17848
Fixes: #17148
Reviewed-By: Tiancheng "Timothy" Gu timothygu99@gmail.com
Reviewed-By: Colin Ihrig cjihrig@gmail.com
Reviewed-By: Rich Trott rtrott@gmail.com
Reviewed-By: James M Snell jasnell@gmail.com
Original PR: #17848
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test