-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
tools: eslint rule for assert.throws -> common.expectsError #17557
Conversation
|
||
module.exports = function(context) { | ||
return { | ||
CallExpression(node) { |
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.
Could no-restricted-syntax
handle 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.
Hmm, possibly but it'll definitely be a pretty convoluted rule in that case. There's no "or" for AST selectors, as far as I know, so it would get super verbose and repetitive to account for all these possibilities. Even with "or" it would be super long.
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.
You don't need the "or" condition since that checks for a function as the first argument to assert.throws()
, which is always required. This selector seems to match all of the cases you have in this PR:
"CallExpression[callee.object.name='assert'][callee.property.name='throws'][arguments.length<3][arguments.1.type='CallExpression'][arguments.1.callee.object.name='common'][arguments.1.callee.property.name='expectsError']"
It's not beautiful, but it might be able to be simplified further.
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.
Good point. That should work. Will update.
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.
A possible problem with no-restricted-syntax
here is that this is a rule that should only apply in test
. I'm not sure if there's a way to specify no-restricted-syntax
in test
in a way that won't override no-restricted-syntax
from the config file in the parent directory. /cc @not-an-aardvark
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 guessing that's why we also have prefer-common-mustnotcall
rule.
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.
Unfortunately, there's not a good way to do that at the moment. As a workaround, you could copy-paste the configuration from the parent directory, add the new entry, and put the resulting config in test/.eslintrc.yaml
. This would have the desired effect, but it could cause the two configs to get out of sync if someone updates .eslintrc.yaml
later on and forgets to update the copied version in test/.eslintrc.yaml
.
There is some discussion on improving this in eslint/eslint#9192.
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.
That's unfortunate. I'm not a fan of adding custom rules that we don't need, but keeping the two config files in sync seems like a worse idea.
This might be overly ambitious but here's an idea: Instead of forcing Doesn't have to be in this PR, though, especially since it might stall due to some resistance. Can be a future enhancement. |
ed808a6
to
229e049
Compare
I've thought about that before but is that something we even want? The Node.js core error objects are pretty specific and the functionality within |
155251f
to
849a7a1
Compare
@cjihrig PTAL — I've updated it to use AST selectors instead. Thanks for the suggestion. |
Add lint rule to validate that common.expectsError is being used instead of assert.throws(fn, common.expectsError(err));
849a7a1
to
a8e3c37
Compare
CI: https://ci.nodejs.org/job/node-test-pull-request/12004/ (had an extra space in one of the error messages, force pushed a fix) |
@Trott as @apapirovski already pointed out |
PR-URL: #17557 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Add lint rule to validate that common.expectsError(fn, err) is being used instead of assert.throws(fn, common.expectsError(err)); PR-URL: #17557 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
PR-URL: #17557 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Add lint rule to validate that common.expectsError(fn, err) is being used instead of assert.throws(fn, common.expectsError(err)); PR-URL: #17557 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
PR-URL: #17557 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Add lint rule to validate that common.expectsError(fn, err) is being used instead of assert.throws(fn, common.expectsError(err)); PR-URL: #17557 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Could this be backported to |
From now on it is possible to use a validation object in throws instead of the other possibilites. PR-URL: nodejs#17584 Refs: nodejs#17557 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Ron Korving <ron@ronkorving.nl> Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
From now on it is possible to use a validation object in throws instead of the other possibilites. PR-URL: nodejs#17584 Refs: nodejs#17557 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Ron Korving <ron@ronkorving.nl> Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
From now on it is possible to use a validation object in throws instead of the other possibilites. Backport-PR-URL: #19230 PR-URL: #17584 Refs: #17557 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Ron Korving <ron@ronkorving.nl> Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
From now on it is possible to use a validation object in throws instead of the other possibilites. Backport-PR-URL: #19230 PR-URL: #17584 Refs: #17557 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Ron Korving <ron@ronkorving.nl> Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
From now on it is possible to use a validation object in throws instead of the other possibilites. PR-URL: nodejs#17584 Refs: nodejs#17557 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Ron Korving <ron@ronkorving.nl> Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
From now on it is possible to use a validation object in throws instead of the other possibilites. Backport-PR-URL: #23223 PR-URL: #17584 Refs: #17557 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Ron Korving <ron@ronkorving.nl> Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Pretty straight-forward — eslint rule that checks for usage of
assert.throws(fn, common.expectsError(err));
and suggests usingcommon.expectsError(fn, err);
instead.First commit fixes all remaining instances that violate this rule. Second commit introduces the rule & a test for it.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test, tools