★ wanayoo — archive 1999 https://github.com/nodejs/node/pull/16648Nouvelle recherche | Portail wanayoo
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

tools: auto fix custom eslint rule for prefer-assert-iferror.js #16648

Conversation

Copy link
Contributor

@shobhitchittora shobhitchittora commented Oct 31, 2017 •

This implements an eslint fixer function to replace if(err) throw err;, usages to assert.ifError(err);.

Refs: #16636

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • Extended the current tests for custom eslint rule.
  • commit message follows commit guidelines
  • python ./tools/test.py parallel/test-eslint-prefer-assert-iferror
Affected core subsystem(s)

Tools

@nodejs-github-bot nodejs-github-bot added the tools label Oct 31, 2017
Copy link
Member

@apapirovski apapirovski left a comment •

Thanks for starting the work on this @shobhitchittora — for all of these fixers, could you expand the existing tests located in test/parallel/test-eslint-*?

See https://eslint.org/docs/developer-guide/nodejs-api#ruletester and https://github.com/eslint/eslint/blob/master/tests/lib/rules/arrow-body-style.js for more info.

@shobhitchittora
Copy link
Contributor Author

@shobhitchittora shobhitchittora commented Oct 31, 2017

Thanks for pointing tests out. I'll start working on them after reading the docs you mentioned. Thanks again.

@shobhitchittora
Copy link
Contributor Author

@shobhitchittora shobhitchittora commented Nov 1, 2017

After going through test-eslint-prefer-assert-iferror.js, I didn't find any cases to add to the existing test rules. Please highlight if any.

@apapirovski
Copy link
Member

@apapirovski apapirovski commented Nov 1, 2017 •

The idea would be to expand the following:

    {
      code: 'if (err) throw err;',
      errors: [{ message: 'Use assert.ifError(err) instead.' }]
    },
    {
      code: 'if (error) { throw error; }',
      errors: [{ message: 'Use assert.ifError(error) instead.' }]
    }

with output which would test your fixer.

https://eslint.org/docs/developer-guide/nodejs-api#ruletester

output (string, optional): Asserts the output that will be produced when using this rule for a single pass of autofixing (e.g. with the --fix command line flag). If this is null, asserts that none of the reported problems suggest autofixes.

@shobhitchittora
Copy link
Contributor Author

@shobhitchittora shobhitchittora commented Nov 1, 2017 •

Done. Extended the current tests with the output key. Expecting your review @apapirovski. Thanks.

},
{
code: 'if (error) { throw error; }',
errors: [{ message: 'Use assert.ifError(error) instead.' }]
errors: [{ message: 'Use assert.ifError(error) instead.' }],
output: 'assert.ifError(error)'
Copy link
Member

@apapirovski apapirovski Nov 1, 2017 •

Choose a reason for hiding this comment

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

These should be assert.ifError(err); and assert.ifError(error); with an ending semicolon.

Copy link
Contributor Author

@shobhitchittora shobhitchittora Nov 1, 2017

Choose a reason for hiding this comment

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

@apapirovski Done. 👍🏻

fix: (fixer) => {
return fixer.replaceText(
node,
`assert.ifError(${argument})`
Copy link
Member

@apapirovski apapirovski Nov 1, 2017

Choose a reason for hiding this comment

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

You'll need a semicolon at the end.

Copy link
Contributor Author

@shobhitchittora shobhitchittora Nov 1, 2017

Choose a reason for hiding this comment

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

@apapirovski Done. 👍🏻

Copy link
Member

@apapirovski apapirovski left a comment

LGTM — thanks for the adjustments @shobhitchittora

Copy link
Member

@gibfahn gibfahn left a comment

Seems correct (although I haven't tested it)

@apapirovski
Copy link
Member

@apapirovski apapirovski commented Nov 1, 2017

CI: https://ci.nodejs.org/job/node-test-pull-request/11134/

@shobhitchittora
Copy link
Contributor Author

@shobhitchittora shobhitchittora commented Nov 2, 2017

Thank you all for being good sport. @apapirovski just wondering why the build is failing for linux and windows.

Finished Build : #13726 of Job : node-test-commit-linux with status : FAILURE
Finished Build : #13071 of Job : node-test-commit-windows-fanned with status : FAILURE

@apapirovski
Copy link
Member

@apapirovski apapirovski commented Nov 2, 2017

We have a test that's failing on those platforms. It's not related to this PR. :)

@not-an-aardvark
Copy link
Contributor

@not-an-aardvark not-an-aardvark commented Nov 4, 2017

This seems like it would cause incorrect code if the assert module has not been imported. This isn't necessarily a big problem (since assert would get reported as an undefined variable after the autofix), but it's possible that a user could get confused about it.

@joyeecheung
Copy link
Member

@joyeecheung joyeecheung commented Nov 6, 2017

@not-an-aardvark I think this comes down to what the expectation the user sets for the fixers...personally I would take it with a grain of salt and fix the tricky ones by myself before I run it to fix something like whitespace changes, but it may be just me.

@BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Nov 23, 2017

Hm, we could further check if assert is imported or not and fix that as well. But it might be a bit to much?

@not-an-aardvark what is your call about the PR?

@apapirovski
Copy link
Member

@apapirovski apapirovski commented Nov 23, 2017

Not a fan of fixing missing requires. It's pretty hard to detect where exactly the require needs to go within the file.

@not-an-aardvark
Copy link
Contributor

@not-an-aardvark not-an-aardvark commented Nov 23, 2017

I agree that it could be difficult to automatically insert require calls. I have no strong opinion either way on whether this would be worthwhile without inserting require calls.

Another option would be to only do an autofix if there is an assert variable in scope.

@BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Nov 23, 2017

Another option would be to only do an autofix if there is an assert variable in scope.

I think that would be best!

@BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Dec 6, 2017

@shobhitchittora would you be so kind and update the PR to also check if there is an assert variable in the scope and only fix it if that is the case?

@apapirovski apapirovski added the wip label Dec 9, 2017
@shobhitchittora
Copy link
Contributor Author

@shobhitchittora shobhitchittora commented Dec 10, 2017

@BridgeAR Done 👍🏻.

@@ -15,11 +15,13 @@ new RuleTester().run('prefer-assert-iferror', rule, {
invalid: [
{
code: 'if (err) throw err;',
errors: [{ message: 'Use assert.ifError(err) instead.' }]
errors: [{ message: 'Use assert.ifError(err) instead.' }],
output: 'assert.ifError(err);'
Copy link
Member

@apapirovski apapirovski Dec 10, 2017 •

Choose a reason for hiding this comment

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

I'm guessing this won't work without having require('assert'); in code and output. Same thing below.

Copy link
Member

@BridgeAR BridgeAR Jan 5, 2018

Choose a reason for hiding this comment

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

@shobhitchittora would you be so kind and have a look at this comment?

Copy link
Contributor Author

@shobhitchittora shobhitchittora Jan 5, 2018

Choose a reason for hiding this comment

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

The test would actually work without the require('assert') specified. While using assert the user has to require assert to use it right. Also in every other test for rules, this is what is followed.

Copy link
Member

@BridgeAR BridgeAR Jan 19, 2018

Choose a reason for hiding this comment

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

As far as I can tell @apapirovski is right about his comment. I am going to run a CI anyway, so we do not have to speculate on it.

@BridgeAR BridgeAR removed the wip label Dec 10, 2017
@BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Jan 19, 2018

Mini CI (should be enough to test the rule): https://ci.nodejs.org/job/node-test-commit-light/145/

@BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Jan 19, 2018

not ok 410 parallel/test-eslint-prefer-assert-iferror
  ---
  duration_ms: 0.407
  severity: fail
  stack: |-
    /data/iojs/build/workspace/node-test-commit-linuxone/nodes/rhel72-s390x/tools/node_modules/eslint/lib/testers/rule-tester.js:148
            throw err;
            ^
    
    AssertionError [ERR_ASSERTION]: Output is incorrect. ('if (err) throw err;' == 'assert.ifError(err);')

@BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Jan 31, 2018 •

@shobhitchittora
Copy link
Contributor Author

@shobhitchittora shobhitchittora commented Jan 31, 2018

@BridgeAR apologies for keeping this hanging. Been a little pre-occupied. Looking into it.😇

1. Fixes the failing test for the rule. Adds require("assert") to code and output.

Refs: nodejs#16636
@shobhitchittora
Copy link
Contributor Author

@shobhitchittora shobhitchittora commented Feb 4, 2018

@BridgeAR I pushed a change and now the tests are working locally. Used this to test - python ./tools/test.py parallel/test-eslint-prefer-assert-iferror.

Thanks for being so patient.

@BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Feb 7, 2018

@BridgeAR BridgeAR added the author ready label Feb 7, 2018
Copy link
Member

@BridgeAR BridgeAR left a comment

LG if CI is green.

BridgeAR pushed a commit to BridgeAR/node that referenced this issue Feb 7, 2018
PR-URL: nodejs#16648
Refs: nodejs#16636
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
@BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Feb 7, 2018 •

Landed in d797775 🎉

@BridgeAR BridgeAR closed this Feb 7, 2018
MylesBorins pushed a commit that referenced this issue Feb 21, 2018
PR-URL: #16648
Refs: #16636
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
MylesBorins pushed a commit that referenced this issue Feb 21, 2018
PR-URL: #16648
Refs: #16636
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
MylesBorins pushed a commit that referenced this issue Feb 21, 2018
PR-URL: #16648
Refs: #16636
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
@MylesBorins MylesBorins mentioned this pull request Feb 21, 2018
gibfahn pushed a commit that referenced this issue Apr 13, 2018
PR-URL: #16648
Refs: #16636
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
@MylesBorins MylesBorins mentioned this pull request May 2, 2018
MayaLekova pushed a commit to MayaLekova/node that referenced this issue May 8, 2018
PR-URL: nodejs#16648
Refs: nodejs#16636
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready tools
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants