-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Alphabetize imports within groups #1360
Conversation
…n groups Fixes #1406. Fixes #389. Closes #629. Closes #1105. Closes #1360. Co-Authored-By: dannysindra <[email protected]> Co-Authored-By: Radim Svoboda <[email protected]> Co-Authored-By: Soma Lucz <[email protected]> Co-Authored-By: Randall Reed, Jr <[email protected]> Co-Authored-By: Jordan Harband <[email protected]>
Can anybody help? Is there any way to test incorrect configuration passed to the eslint rule? It seems like such errors are handled already by the Or should we just delete the checks to make coveralls happy ? |
Please don’t open duplicate PRs; now i have to maintain both in sync, open, until both are merged together. Instead, post a link to your commits on the original PR, and a maintainer will update it. |
ok, got it |
Is this ready to merge ? This feature will be great. |
I believe it is ready. I created a fix based on the suggestion in #1105 . And now, probably some of the maintainers have to say "it's ok" and merge it. |
I think example still needs correction: import assert from 'assert';
import buffer from 'buffer';
import foo from 'foo';
import bar from 'bar';
import Baz from 'Baz'; It's unclear if imports should be sorted by module name or imported symbols. Also, it's uncertain what behaviour is expected using star imports (import * as) and symbol imports (import { A, B }) It would be best to make example with some real life imports like import * as classnames from 'classnames';
import PropTypes from 'prop-types';
import React, { PureComponent } from 'react';
import { compose } from 'recompose'; |
Or a more clear example like Pass: import c from 'a';
import b from 'b';
import a from 'c'; Fail: import a from 'c';
import b from 'b';
import c from 'a'; |
@ljharb Could you please look at this PR? |
Fixed the example. Travis CI failed but it has the same errors as master branch did https://travis-ci.org/benmosher/eslint-plugin-import/builds/553254212 . So I don't think there is anything I can do about it right now. |
The tests don't seem to be failing on |
@deb0ch should be mergable; thanks for the reminder, just rebased 🍾 🎉 🍾 🎉 |
@ljharb Could you look into merging this PR? It is a long-wanted feature, and also would come with a few benefits, since it:
Thank you. |
src/rules/order.js
Outdated
groupedByRanks[groupRank].sort(function(importA, importB) { | ||
return ignoreCase | ||
? importA.localeCompare(importB) | ||
: (importA < importB ? -1 : (importA === importB ? 0 : 1)) |
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.
Scary. Could it be replaced with if... return
?
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.
Btw it is also incorrect I think. The default sensitvity
option is variant
in localeCompare
for the default sort
ing usage (applies in the above snippet), which does not ignore casing.
I don't want to meddle in this PR, but I suggest the following:
groupedByRanks[groupRank].sort(function(importA, importB) {
return importA.localeCompare(importB, undefined, { sensitivity: ignoreCase ? 'accent' : 'case' })
})
@stropho, since I have no write access to this, in order to get this PR finally merged before any further conflicts emerge, I would like to ask you to
to this:
Thank you! |
@luczsoma I haven't really investigated the code much, just wanted to help to merge it.... anyway, I just tried to fix it myself since you've told me exactly what to do :-D About 4 tests fail now. That is ok but it seems to be nearly impossible for me to find which tests are failing. |
Thank you @stropho! As I tried to extend the functionality with configurable numeric sorting (1 < 2 < 10 vs 1 < 10 < 2) and configurable casing options (a-z < A-Z vs a-z > A-Z), I found out that I also fixed @syabro's concerns. |
I think this should be mergeable now. |
I bet it could be done later :) We badly need a basic sort |
Planning to do it some time later. :) |
thx @luczsoma - I'm not a fan of rewriting code to make it bigger but as long as it is more readable and everybody's happy about it.. why not... What got my attention though is that the
Let's vote!!! |
alright, |
@ljharb any news? any suggestions to get it merged ? |
any updates on this? really want it to be merged. |
tests/src/rules/order.js
Outdated
@@ -335,10 +335,10 @@ ruleTester.run('order', rule, { | |||
// Option newlines-between: 'always' with multiline imports #3 | |||
test({ | |||
code: ` | |||
import foo | |||
import a |
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.
why does this need to be changed? can this test be reverted?
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 think the intention of this commit (which is not my own) was to show how the alphabetical sorting in a clearer way, with minimal examples. I would not revert that.
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.
If your comment is concerned about only this particular test case (which tests multiline, not ordering), I will revert that part to its original state.
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, my comment is because for it not to be a breaking change, no existing test cases should be altered.
(additionally, please rebase this on latest master) |
Requested changes are done, rebased onto master. |
I tried the PR and it breaks the |
Putting the newlines test first seems to fix it : if (newlinesBetweenImports !== 'ignore') {
makeNewlinesBetweenReport(context, imported, newlinesBetweenImports)
}
if (alphabetize.order !== 'ignore') {
mutateRanksToAlphabetize(imported, alphabetize.order)
}
makeOutOfOrderReport(context, imported) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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.
Because of the autofixer, if this ends up breaking side effecty modules by sorting anything across bindingless imports (which should never themselves be sorted), then the autofix for this entire rule will be promptly disabled in a patch.
Please do feel motivated to quickly open a followup PR with test cases that cover those cases if you're interested in ensuring this rule remains autofixable.
…n groups Fixes import-js#1406. Fixes import-js#389. Closes import-js#629. Closes import-js#1105. Closes import-js#1360. Co-Authored-By: dannysindra <[email protected]> Co-Authored-By: Radim Svoboda <[email protected]> Co-Authored-By: Soma Lucz <[email protected]> Co-Authored-By: Randall Reed, Jr <[email protected]> Co-Authored-By: Jordan Harband <[email protected]>
Manually alphabetize import groups and lines pending the merging of import-js/eslint-plugin-import#1360, using WebStorm's Optimize imports
I'm not the real author of these commits. I just rebased the existing #1105 . I'm looking forward to use this new feature.
Closes #1105. Fixes #1406.