Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

Tiriel
Copy link
Contributor

@Tiriel Tiriel commented Jan 10, 2018

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 [email protected]
Reviewed-By: Colin Ihrig [email protected]
Reviewed-By: Rich Trott [email protected]
Reviewed-By: James M Snell [email protected]

Original PR: #17848

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

test

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 <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@nodejs-github-bot nodejs-github-bot added test Issues and PRs related to the tests. v9.x labels Jan 10, 2018
@Tiriel
Copy link
Contributor Author

Tiriel commented Jan 10, 2018

I don't know if this is the correct way to adapt this test, but I figured it was the best.

For the explanation:
The initial commit could not be backported on v9.x . After some investigation, the problem did not come from the require test modification, but from the deprecation warning expectations. From what I saw, these expectations where failing because require is now throwing ReferenceError when the internal deps are not properly called (ie internally to Node, not in a loop, and in the proper order).
So, this solution appeared the best to me. But I'll gladly amend in any way, or even remove this PR if this cannot be backported as it is now.

(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);
Copy link
Member

@lpinca lpinca Jan 10, 2018

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.

Copy link
Contributor Author

@Tiriel Tiriel Jan 10, 2018

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?

Copy link
Member

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

Copy link
Member

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!

Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Trott this is an attempt to backport #17848.

Copy link
Member

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

Copy link
Contributor

@cjihrig cjihrig Jan 10, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this should actually be backported.

EDIT: The test was added in #16392, which is semver-major. It was then updated in #15566, which is marked as don't land on v4, v6, v8, and v9. Then, there were only two tweaks to the test itself.

Copy link
Contributor Author

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.

Trott
Trott previously requested changes Jan 10, 2018
}
};

assert.throws(throwingModules, ReferenceError);
Copy link
Member

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!

@Tiriel
Copy link
Contributor Author

Tiriel commented Jan 10, 2018

@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?

@Trott
Copy link
Member

Trott commented Jan 10, 2018

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

@Tiriel
Copy link
Contributor Author

Tiriel commented Jan 11, 2018

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.

@Trott Trott dismissed their stale review January 11, 2018 22:22

requested change has been made

@Tiriel
Copy link
Contributor Author

Tiriel commented Jan 15, 2018

Just a small up.
Does anyone thinks this can/should be merged, or do I drop this PR?

@Trott
Copy link
Member

Trott commented Jan 16, 2018

@nodejs/testing

@BridgeAR
Copy link
Member

Ping @nodejs/lts

@jasnell
Copy link
Member

jasnell commented Feb 13, 2018

Why is this targeting v9.x instead of master?
And if it is v9.x, then pinging @nodejs/lts is not necessary since 9.x is not an LTS branch.

@richardlau richardlau changed the title test: fix require-deps-deprecation for installed deps [v9.x backport] test: fix require-deps-deprecation for installed deps Feb 14, 2018
@richardlau
Copy link
Member

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.

MylesBorins pushed a commit that referenced this pull request Feb 20, 2018
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 <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@MylesBorins
Copy link
Contributor

Landed in b5752ee

@Tiriel
Copy link
Contributor Author

Tiriel commented Feb 20, 2018

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants