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

shobhitchittora
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 Issues and PRs related to the tools directory. label Oct 31, 2017
Copy link
Member

@apapirovski apapirovski left a comment

Choose a reason for hiding this comment

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

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

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

@shobhitchittora
Copy link
Contributor Author

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

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

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

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

Choose a reason for hiding this comment

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

LGTM — thanks for the adjustments @shobhitchittora

Copy link
Member

@gibfahn gibfahn left a comment

Choose a reason for hiding this comment

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

Seems correct (although I haven't tested it)

@apapirovski
Copy link
Member

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

@shobhitchittora
Copy link
Contributor Author

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

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

@not-an-aardvark
Copy link
Contributor

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

@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

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

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

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

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 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 Issues and PRs that are still a work in progress. label Dec 9, 2017
@shobhitchittora
Copy link
Contributor Author

@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

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

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

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 Issues and PRs that are still a work in progress. label Dec 10, 2017
@BridgeAR
Copy link
Member

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

@BridgeAR
Copy link
Member

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 commented Jan 31, 2018

Ping @shobhitchittora

@shobhitchittora
Copy link
Contributor Author

@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

@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 commented Feb 7, 2018

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 7, 2018
Copy link
Member

@BridgeAR BridgeAR left a comment

Choose a reason for hiding this comment

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

LG if CI is green.

BridgeAR pushed a commit to BridgeAR/node that referenced this pull request Feb 7, 2018
PR-URL: nodejs#16648
Refs: nodejs#16636
Reviewed-By: Anatoli Papirovski <[email protected]>
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
@BridgeAR
Copy link
Member

BridgeAR commented Feb 7, 2018

Landed in d797775 🎉

@BridgeAR BridgeAR closed this Feb 7, 2018
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
PR-URL: #16648
Refs: #16636
Reviewed-By: Anatoli Papirovski <[email protected]>
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
PR-URL: #16648
Refs: #16636
Reviewed-By: Anatoli Papirovski <[email protected]>
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
PR-URL: #16648
Refs: #16636
Reviewed-By: Anatoli Papirovski <[email protected]>
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Feb 21, 2018
gibfahn pushed a commit that referenced this pull request Apr 13, 2018
PR-URL: #16648
Refs: #16636
Reviewed-By: Anatoli Papirovski <[email protected]>
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
@MylesBorins MylesBorins mentioned this pull request May 2, 2018
MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
PR-URL: nodejs#16648
Refs: nodejs#16636
Reviewed-By: Anatoli Papirovski <[email protected]>
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. tools Issues and PRs related to the tools directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants