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

Enable curly spacing check for children #1177

Merged
merged 9 commits into from Jun 11, 2017

Conversation

fatfisz
Copy link
Contributor

@fatfisz fatfisz commented May 7, 2017

This is a feature discussed in #857.

TODO:

  • move all the bugfixes to separate branches
  • merge the master after the fixes are merged
  • add more tests for attributes and children
  • add more tests for config inheritance
  • restore the old config behavior alongside the new one
  • update the README

@fatfisz
Copy link
Contributor Author

fatfisz commented May 7, 2017

I think I'll add a few tests that have both attributes and children set to check that the defaults are being properly set.

@fatfisz fatfisz force-pushed the curly-spacing-for-children branch from 30f36dd to 7ff31f5 Compare May 7, 2017 13:29
@@ -30,34 +32,87 @@ module.exports = {
fixable: 'code',

schema: [{
enum: SPACING_VALUES
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, will do.

@fatfisz fatfisz closed this May 7, 2017
@fatfisz fatfisz deleted the curly-spacing-for-children branch May 7, 2017 20:43
@fatfisz fatfisz restored the curly-spacing-for-children branch May 7, 2017 20:45
@fatfisz
Copy link
Contributor Author

fatfisz commented May 7, 2017

I mistakenly removed the branch -.-

@fatfisz fatfisz reopened this May 7, 2017
@ljharb
Copy link
Member

ljharb commented May 9, 2017

Seems like with #1179 and #1180 merged, this needs a rebase?

@fatfisz
Copy link
Contributor Author

fatfisz commented May 9, 2017

Sure.

@ljharb
Copy link
Member

ljharb commented May 9, 2017

@fatfisz please rebase on the command line and force push, so that there's no merge commits

@fatfisz fatfisz force-pushed the curly-spacing-for-children branch from 0979686 to 998e356 Compare May 9, 2017 21:13
@fatfisz
Copy link
Contributor Author

fatfisz commented May 9, 2017

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.

@fatfisz
Copy link
Contributor Author

fatfisz commented May 9, 2017

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?

@ljharb
Copy link
Member

ljharb commented May 9, 2017

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.

Copy link
Member

@ljharb ljharb left a 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: {
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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} />;',
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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.

@fatfisz
Copy link
Contributor Author

fatfisz commented May 10, 2017

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?

@ljharb
Copy link
Member

ljharb commented May 10, 2017

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.

@fatfisz fatfisz force-pushed the curly-spacing-for-children branch from 98eb4f4 to 51466df Compare May 10, 2017 19:17
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

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

Seems good

@fatfisz
Copy link
Contributor Author

fatfisz commented May 19, 2017

Sorry, forgot about updating the docs. Will do that around tomorrow, I'm pumped out after work today.

@fatfisz fatfisz force-pushed the curly-spacing-for-children branch from 2727e58 to 0c7a226 Compare May 21, 2017 22:43
@fatfisz
Copy link
Contributor Author

fatfisz commented May 21, 2017

Took a bit more time, but here it is.

Copy link
Member

@ljharb ljharb left a 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.

@fatfisz
Copy link
Contributor Author

fatfisz commented Jun 5, 2017

Would it be possible for some other collaborators to review this?

@fatfisz
Copy link
Contributor Author

fatfisz commented Jun 11, 2017

It seems that resolving conflicts through GitHub results in a merge. Will rebase instead.

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.
@fatfisz fatfisz force-pushed the curly-spacing-for-children branch from 912ec6b to d57c115 Compare June 11, 2017 17:10
Copy link
Collaborator

@lencioni lencioni 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 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
Copy link
Collaborator

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.

Copy link
Member

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.

@ljharb
Copy link
Member

ljharb commented Jun 11, 2017

(The appveyor failure appears to be an npm install fluke, so i'm going to merge as-is)

@ljharb ljharb merged commit 32bcb48 into jsx-eslint:master Jun 11, 2017
@fatfisz
Copy link
Contributor Author

fatfisz commented Jun 11, 2017

Thanks a lot!

@102
Copy link
Contributor

102 commented Jun 13, 2017

@ljharb is there any ETA for this to be released?

@ljharb
Copy link
Member

ljharb commented Jun 13, 2017

@102 #1251 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

4 participants