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
Fix: syntax errors created by object-shorthand
autofix (fixes #7574)
#7575
Conversation
@not-an-aardvark, thanks for your PR! By analyzing the history of the files in this pull request, we identified @NickHeiner, @platinumazure and @martijndeh to be potential reviewers. |
LGTM |
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.
Nice job on the quick turnaround time for this bug. Thanks a lot! I just have a few suggestion for additional tests, but otherwise LGTM
{ code: "({ foo: async function () {} })", output: "({ async foo () {} })", parserOptions: { ecmaVersion: 8 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | ||
{ code: "({ 'foo': async function() {} })", output: "({ async 'foo'() {} })", parserOptions: { ecmaVersion: 8 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | ||
{ code: "({ [foo]: async function() {} })", output: "({ async [foo]() {} })", parserOptions: { ecmaVersion: 8 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | ||
{ code: "({ [foo.bar]: function*() {} })", output: "({ *[foo.bar]() {} })", parserOptions: { ecmaVersion: 6 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, |
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 you add a test for the case when a generator function has a space before the star as well? Like in your PR overview example:
({ foo: function *() {} });
@@ -144,6 +144,11 @@ ruleTester.run("object-shorthand", rule, { | |||
{ code: "doSomething({y: function() {}})", output: "doSomething({y() {}})", parserOptions: { ecmaVersion: 6 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | |||
{ code: "doSomething({[y]: function() {}})", output: "doSomething({[y]() {}})", parserOptions: { ecmaVersion: 6 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | |||
{ code: "doSomething({['y']: function() {}})", output: "doSomething({['y']() {}})", parserOptions: { ecmaVersion: 6 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | |||
{ code: "({ foo: async function () {} })", output: "({ async foo () {} })", parserOptions: { ecmaVersion: 8 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | |||
{ code: "({ 'foo': async function() {} })", output: "({ async 'foo'() {} })", parserOptions: { ecmaVersion: 8 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | |||
{ code: "({ [foo]: async function() {} })", output: "({ async [foo]() {} })", parserOptions: { ecmaVersion: 8 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, |
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.
Just in case, how about an additional test for async and spaces inside the square brackets combined:
({ [ foo ]: async function() {} })
{ code: "({ 'foo': async function() {} })", output: "({ async 'foo'() {} })", parserOptions: { ecmaVersion: 8 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | ||
{ code: "({ [foo]: async function() {} })", output: "({ async [foo]() {} })", parserOptions: { ecmaVersion: 8 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | ||
{ code: "({ [foo.bar]: function*() {} })", output: "({ *[foo.bar]() {} })", parserOptions: { ecmaVersion: 6 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, | ||
{ code: "({ [foo ]: function() {} })", output: "({ [foo ]() {} })", parserOptions: { ecmaVersion: 6 }, errors: [{ message: "Expected method shorthand.", type: "Property" }] }, |
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 guess I'm being a bit picky (please don't hate me) but could we add a couple more tests, just in case, for when there are spaces only after the opening bracket, and for when there are spaces after the opening and the closing bracket?
({ [ foo ]: function() {} })
({ [ foo]: function() {} })
LGTM |
Updated to add the requested tests. |
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.
LGTM, but would like someone else to take a look and make sure there are enough test cases.
What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[x] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
See #7574
What changes did you make? (Give an overview)
This fixes several bugs in
object-shorthand
's autofixing.Previously, if an object had a computed key that was anything other than an identifier corresponding to a generator function property, the fixer would output unbalanced square brackets with
undefined
as the property name.Previously, the fixer would output invalid syntax if there was a space between a computed property and its closing bracket.
Previously, the fixer would output invalid syntax for generator functions if there was a space before the star.
Previously, the fixer would output incorrect fixes for async functions (Linting with auto-fix with rule 'object-shorthand' breaks properties with async/await functions #7574).
Is there anything you'd like reviewers to focus on?
This is a fairly bad bug, since the resulting code after autofixing an async function is still syntactically valid (so the user won't notice the issue), but it does something completely different than before. I'm hoping we can expedite this PR to get the fix into the upcoming release.
However, it is a semver-patch change, so it could also go into a patch release if we decide to create one for this release.