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

Update: add named imports and exports for object-curly-newline #9876

Merged

Conversation

nicholaschuayunzhi
Copy link
Contributor

What is the purpose of this pull request? (put an "X" next to item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[x] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

Resolves #8501

What changes did you make? (Give an overview)
Added configuration for named imports and exports.

Is there anything you'd like reviewers to focus on?
Due to code reuse, the config allows for the consistent option which acts the same way in ObjectExpression and ObjectPattern. Would that be fine as it was not discussed in #8501.

Are the test cases comprehensive enough?

@jsf-clabot
Copy link

jsf-clabot commented Jan 23, 2018

CLA assistant check
All committers have signed the CLA.

@aladdin-add aladdin-add added enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules accepted There is consensus among the team that this change meets the criteria for inclusion labels Jan 23, 2018
@nicholaschuayunzhi
Copy link
Contributor Author

@platinumazure Would you be able to assist in getting this merged? Thank you :)

@platinumazure platinumazure self-assigned this Jan 29, 2018
@platinumazure
Copy link
Member

Hi @nicholaschuayunzhi, thanks for following up, this one slipped past me somehow. I'll review in the next day or two. Thanks!

Copy link
Member

@platinumazure platinumazure left a comment

Choose a reason for hiding this comment

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

Left some comments/questions. The only thing I would really want changed is the extraction of the needsLineBreaks check into its own function. Thanks for contributing and sorry again for letting this slip by!

@@ -19,19 +19,23 @@ Or an object option:
* `"minProperties"` requires line breaks if the number of properties is at least the given integer. By default, an error will also be reported if an object contains linebreaks and has fewer properties than the given integer. However, the second behavior is disabled if the `consistent` option is set to `true`
* `"consistent": true` requires that either both curly braces, or neither, directly enclose newlines. Note that enabling this option will also change the behavior of the `minProperties` option. (See `minProperties` above for more information)

You can specify different options for object literals and destructuring assignments:
You can specify different options for object literals, destructuring assignments, named imports and exports:
Copy link
Member

Choose a reason for hiding this comment

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

Nit: Could you please add "and" before "named imports and exports"? Thanks!

*/
function normalizeOptions(options) {
if (options && (options.ObjectExpression || options.ObjectPattern)) {
if (options &&
Copy link
Member

Choose a reason for hiding this comment

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

Wondering if this could be replaced with something like lodash.isPlainObject(options)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Considering that the options can take different forms, more checks must be made for more node specific options.

I've made changes in 75bea25 to make the code more readable.

Explanation:

"never"
"always"

{ "multiline": true }
{ "minProperties": 2 }
{ "consistent": true }

// want to identify this
{ "ObjectExpression": "always" }
{ "ObjectExpression": { "multiline": true } }
  1. find options that are objects.
  2. find the options that have a string or object as its value.

closeBrace = sourceCode.getLastToken(node);
} else {
closeBrace = sourceCode.getTokenAfter(node.specifiers.slice(-1)[0], token => token.value === "}");
Copy link
Member

Choose a reason for hiding this comment

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

Could we use sourceCode.getLastToken(node, token => token.value === "}") in both this code path and the one for ObjectExpression/ObjectPattern?

)
);

let needsLinebreaks;
Copy link
Member

Choose a reason for hiding this comment

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

I think it would be good to extract this code into its own function to make things a little more readable.

"} from 'module';"
].join("\n"),
options: [{ ImportDeclaration: "always" }],
parserOptions: { sourceType: "module" }
Copy link
Member

Choose a reason for hiding this comment

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

You could add { parserOptions: { sourceType: "module" } } to the RuleTester constructor, in order to avoid having to specify it in each of your tests. I don't think there's a need for any test to specify { sourceType: "script" }, but let me know if I'm mistaken.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for the information. I'm not too sure about { sourceType: "script" }. To be honest, I'm learning from the other tests in the repo and I'm still unsure where to find more information about this.

export { foo, bar } from 'foo-bar';
export { foo as f, bar } from 'foo-bar';
```

## Compatibility

* **JSCS**: [requirePaddingNewLinesInObjects](http://jscs.info/rule/requirePaddingNewLinesInObjects) and [disallowPaddingNewLinesInObjects](http://jscs.info/rule/disallowPaddingNewLinesInObjects)
Copy link
Member

Choose a reason for hiding this comment

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

Is there a JSCS rule we are now compatible with for padding new lines for import/export specifiers?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There doesn't seem to be any JSCS rule regarding new lines and import/export specifiers. Only ones for spaces in the import braces.

requireSpacesInsideImportedObjectBraces
disallowSpacesInsideImportedObjectBraces

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for checking!

@nicholaschuayunzhi
Copy link
Contributor Author

Thank you for reviewing my pull request :) I have responded to some of the comments in the review and made changes as requested.

Copy link
Member

@platinumazure platinumazure left a comment

Choose a reason for hiding this comment

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

This looks great! I unfortunately was unclear on my earlier comment about the docs, so I apologize for requesting changes once again but once that is fixed, this should be ready to merge as a semver-minor change. Thanks so much for contributing!

@@ -19,19 +19,23 @@ Or an object option:
* `"minProperties"` requires line breaks if the number of properties is at least the given integer. By default, an error will also be reported if an object contains linebreaks and has fewer properties than the given integer. However, the second behavior is disabled if the `consistent` option is set to `true`
* `"consistent": true` requires that either both curly braces, or neither, directly enclose newlines. Note that enabling this option will also change the behavior of the `minProperties` option. (See `minProperties` above for more information)

You can specify different options for object literals and destructuring assignments:
You can specify different options for object literals and destructuring assignments, named imports and exports:
Copy link
Member

Choose a reason for hiding this comment

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

Sorry, I wasn't clear in my last comment. The removal of the original "and" was correct, but I wanted a new "and" before the named import/export.

This is what I was going for:

You can specify different options for object literals, destructuring assignments, and named imports and exports:

Thanks for your patience!

@nicholaschuayunzhi
Copy link
Contributor Author

Hi i think I've got nothing left to change. Do I need to do anything else?

@ilyavolodin
Copy link
Member

@platinumazure Could you check if all of your comments were addressed?

Copy link
Member

@platinumazure platinumazure 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 contributing!

@ilyavolodin ilyavolodin merged commit 47ac478 into eslint:master Feb 10, 2018
@nicholaschuayunzhi
Copy link
Contributor Author

Thanks for your guidance!

This was referenced Mar 19, 2018
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Aug 10, 2018
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Aug 10, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules
Projects
None yet
6 participants