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

jsx-sort-props rule is not working as it should #1692

Closed
zalishchuk opened this issue Feb 13, 2018 · 12 comments · Fixed by #1883
Closed

jsx-sort-props rule is not working as it should #1692

zalishchuk opened this issue Feb 13, 2018 · 12 comments · Fixed by #1883

Comments

@zalishchuk
Copy link

Rule configuration:

'react/jsx-sort-props': [
  'error',
  {
    noSortAlphabetically: false,
    ignoreCase: true,
    callbacksLast: false,
    shorthandLast: true,
    reservedFirst: true,
  },
],

As a result callbacksLast, shorthandLast options are overridden by noSortAlphabetically, so props are sorting only by alphabet ignoring shorthands at the end. Also, how can I reach this sort order:

  • object spread props
  • reserved props
  • common props (html attributes, etc.)
  • callback props
  • shorthand/boolean props

Example:

<button
  {...rest}
  key={1}
  type="button"
  onClick={() => {}}
  disabled
/>
@ljharb
Copy link
Member

ljharb commented Feb 13, 2018

It would be dangerous to enforce object spread props on any particular order, as you might intend props before it to be overridden, and props after it to override.

The collision between options sounds like it might be a bug.

@zalishchuk
Copy link
Author

We can discard issue about object spread props, but what about noSortAlphabetically bug?

@ljharb
Copy link
Member

ljharb commented Feb 13, 2018

What error do you get from your example?

@zalishchuk
Copy link
Author

zalishchuk commented Feb 13, 2018

As I mentioned before noSortAlphabetically: false option overrides callbacksLast and shorthandLast, that's why props are sorted only by alphabet and shorthand prop is on the top, but it should be at the end of component props.

@ljharb
Copy link
Member

ljharb commented Feb 15, 2018

In your example, the shorthand prop is on the bottom.

Can you provide example code and config, combined with actual and expected output?

@fleischie
Copy link
Contributor

Hey I just stumbled over this as well. I figured I just add some requested data:

Example Code + Config

Code

import React from 'react';

export const Test = () => (
  <p z="test" a />
);

Config

{
  "root": true,
  "extends": ["eslint:recommended", "plugin:react/recommended"],
  "parser": "babel-eslint",
  "parserOptions": {
    "ecmaFeatures": {
      "experimentalObjectRestSpread": true,
      "jsx": true
    },
    "sourceType": "module"
  },
  "plugins": [
    "react"
  ],
  "rules": {
    "react/jsx-sort-props": [2, {
      "reservedFirst": true,
      "shorthandLast": true
    }
  }
}

Expected Output

Note: I run node_modules/.bin/eslint <file> to produce the following output.

Actual Output

/Users/kfle/Documents/Programming/work/OetkerDigital/backen/test.js
  4:15  error  Props should be sorted alphabetically  react/jsx-sort-props

✖ 1 problem (1 error, 0 warnings)
  1 error, 0 warnings potentially fixable with the `--fix` option.

"Interesting" Observation

If I only supply the shorthandLast linting rule I get the expected result (also the expected output, if I incorrectly sort the shorthand prop before any others).

Example working config for only shorthand rule:

  ...
  "rules": {
    "react/jsx-sort-props": [2, {
      "shorthandLast": true
    }]
  }

@zalishchuk
Copy link
Author

zalishchuk commented Jun 21, 2018

My own opinion, this rule should be remade to be similar to sort-comp.

@fleischie
Copy link
Contributor

@zalishchuk can you elaborate a little on what you mean specifically? Do you mean the documentation, the rule's structure, the validation algorithm? I'm just curious...

@zalishchuk
Copy link
Author

@fleischie I want the rule configuration to look like this.

"react/jsx-sort-props": ['error', {
  order: [
    'reserved',
    'everything-else',
    'callbacks',
    'shorthands',
  ]
}]

@fleischie
Copy link
Contributor

Hmm, yes. And the ignoreCase and noSortAlphabetically would then be additional attributes to the options-object I guess? That would sound awesome indeed...

@fleischie
Copy link
Contributor

Before I dive deeper into this issue code-wise, I still have some questions as this will be a breaking change (the configuration structure will drastically change):

  • How would be a good way to get started on this?
  • Should I first fix the colliding options?
  • Should I directly break everything just for the sake of some awesom-o feature? (Probably not)
  • Should I wait for a maintainer to give his consent/guidance on this? (Probably)

Any additional pointers will be gladly taken.

@ljharb
Copy link
Member

ljharb commented Jun 23, 2018

We should avoid a breaking change.

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

Successfully merging a pull request may close this issue.

3 participants