-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Enable curly spacing check for children #1177
Conversation
I think I'll add a few tests that have both attributes and children set to check that the defaults are being properly set. |
30f36dd
to
7ff31f5
Compare
@@ -30,34 +32,87 @@ module.exports = { | |||
fixable: 'code', | |||
|
|||
schema: [{ | |||
enum: SPACING_VALUES |
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.
this seems like it's removing the old schema, which makes it a breaking change - the idea would be to allow all existing configuration possibilities to continue to work, but provide an alternative that people could migrate to.
Specifically, this also means that (separate from bugfixes) zero existing tests should be modified, and should all continue to pass.
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.
Ok, will do.
I mistakenly removed the branch -.- |
Sure. |
@fatfisz please rebase on the command line and force push, so that there's no merge commits |
0979686
to
998e356
Compare
Rebased. Just curious, why do you want to avoid merge commits? It's less time-consuming to solve the conflicts once; also the history is being lost. |
I've added back the old tests (avoiding duplication) and restored the old config behavior. Should I leave any comments about what is from where? |
Git logs aren't history, they're change logs - nobody ever needs to know how many times you merged master. Also, merge conflict resolutions in a rebase are preserved for future cherry pickers; conflicts resolved in a merge potentially force developers to re-resolve the same conflicts. It also generally takes precisely the same amount of time to solve a conflict in a merge as it does in a rebase. |
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.
This is looking great; just a few questions about the tests.
@@ -32,7 +32,52 @@ module.exports = { | |||
fixable: 'code', | |||
|
|||
schema: [{ | |||
enum: SPACING_VALUES | |||
definitions: { |
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 not familiar with the "definitions" rule schema key - what version of eslint added 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.
I've just read in the ESLint docs that it's using JSON schema - then went over to the JSON schema reference page (this one is very good) and saw that this technique there.
After a little investigation, it should be supported since the schema validation itself was added: eslint/eslint@fd8fbe7. According to the changelog, the version was 0.22.0, released on 2015-05-30.
The version of is-my-json-valid used then is 2.10.0, which already handled refs: https://github.com/mafintosh/is-my-json-valid/blob/21aa9b8916a2efb3172d17d2d3d1b517668834c7/test/json-schema-draft4/ref.json
Btw. "definitions" is just a convention; the ref can reference any path in the schema.
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.
Wow, awesome. I had no idea.
code: '<App>{ { bar: true, baz: true } }</App>;', | ||
options: [{children: false}] | ||
}, { | ||
code: '<App foo={bar} />;', |
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.
It seems like some of the <App foo={bar} />
tests have been removed - for any code pattern, we need explicit tests for a) no options, b) all explicit options on the old (current) schema, c) all explicit options on the new schema, d) autofixes
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 changed a few of them to include children too - they should be at the top. I did not remove any tests, just enhanced a few. The tests without the options should mostly be at the top of the list.
Should I split them to test attributes and children separately?
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.
Yes please :-) when existing test cases are utterly untouched, it adds confidence that a change is not breaking.
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.
Ok, now all tests that are currently on the master branch are also added here.
I was asking because in my experience it takes much longer to do a rebase, especially when there are many commits already. E.g. yesterday merge took < 5 mins, but the rebase took over half an hour. But the argument about cherry-picking speaks to me. Just for the future reference - would it be ok to squash the commits next time while rebasing? |
Commits should ideally be atomic and thus each represent a conceptual change. Naive squashing is fine, but it can cause two changes to be combined where they should be separate. |
98eb4f4
to
51466df
Compare
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.
Seems good
Sorry, forgot about updating the docs. Will do that around tomorrow, I'm pumped out after work today. |
2727e58
to
0c7a226
Compare
Took a bit more time, but here it is. |
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!
This should get a review from at least one other collab before merging.
Would it be possible for some other collaborators to review this? |
It seems that resolving conflicts through GitHub results in a merge. Will rebase instead. |
Use the "spaces" name.
Previously when "spacing" was set and "allowMultiline" was missing, it was set to `undefined` and not `true` (as it should).
This change does not make sense by itself, but it will with the added children config.
912ec6b
to
d57c115
Compare
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.
Thanks for making this better!
@@ -135,6 +221,41 @@ When `"never"` is used and `objectLiterals` is `"always"`, the following pattern | |||
|
|||
Please note that spacing of the object literal curly braces themselves is controlled by the built-in [`object-curly-spacing`](http://eslint.org/docs/rules/object-curly-spacing) rule. | |||
|
|||
### Shorthand options |
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.
Do we see value in supporting these shorthand options indefinitely, or might we want to deprecate them to simplify in a major release? If we plan to deprecate them eventually, it might be worth noting that here so people can avoid using them now.
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'd say we might want to deprecate them (string options are horrible for extensibility), but there's not really any pressing need to.
(The appveyor failure appears to be an npm install fluke, so i'm going to merge as-is) |
Thanks a lot! |
@ljharb is there any ETA for this to be released? |
This is a feature discussed in #857.
TODO: