You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I have noticed when updating eslint dependencies on an existing config that post 2.26.0 version (it's an ancient version, but has been a blocker on our end for upgrading this particular dependency) that it apparently breaks sort order of imports within ["parent", "sibling", "index"] group (see screenshot visual diff after upgrade and autofix).
👇🏼 Noticed that in other places the sort didn't make sense to me as it seemed to go ["sibling", "relative", "sibling"] 🤷🏼
Update #1
Digged into the code a bit and as far as I understand that the following lines split A/B import paths into segments by / and wort by each segment accordingly. But that would also mean that first relative traverse parts e.g. .. vs . would always sort to . > .. ignoring the type of the import, right?
Update #2
Found a open discussion about the same problem #2682
alphabetize.order: "asc" no longer sorts imports within "sub-group" as before where it first sorted parent imports, than sibling, index, but threats all group imports as a whole. Before that was a powerful feature to mentally group dependencies in a file from outside in in contextual blocks of what we control and what is related to the file.
My config for import/order:
"import/order": [
"error",
{
"newlines-between": "always",
pathGroupsExcludedImportTypes: ["builtin"],
groups: [
["builtin", "external"],
["internal"],
["parent", "sibling", "index"],
["object"],
/**
* NOTE: There is also "type" group, but we are not specifying so it groups depending on its import path
* and then get alphabetized depending on path
*/
],
alphabetize: {
order: "asc",
caseInsensitive: true,
},
},
],
I found a possible workaround by splitting the parent into its own group. But it is unfavorable as it would touch pretty much all files in the project.
Temporary workaround is to:
"import/order": [
"error",
{
"newlines-between": "always",
pathGroupsExcludedImportTypes: ["builtin"],
groups: [
["builtin", "external"],
["internal"],
- ["parent", "sibling", "index"],+ ["parent"],+ ["sibling", "index"],
["object"],
/**
* NOTE: There is also "type" group, but we are not specifying so it groups depending on its import path
* and then get alphabetized depending on path
*/
],
alphabetize: {
order: "asc",
caseInsensitive: true,
},
},
],
The text was updated successfully, but these errors were encountered:
Reopened as while no errors I had with the config (see details) on existing code, the lack of sorting actually prevents new code from getting properly sorted in the first place.
Hi,
I have noticed when updating eslint dependencies on an existing config that post 2.26.0 version (it's an ancient version, but has been a blocker on our end for upgrading this particular dependency) that it apparently breaks sort order of imports within
["parent", "sibling", "index"]
group (see screenshot visual diff after upgrade and autofix).👇🏼 Noticed that in other places the sort didn't make sense to me as it seemed to go
["sibling", "relative", "sibling"]
🤷🏼Seems like changes by adding
orderImportKind
within v2.26.0...v2.27.0#diff-2825fcc427c846fe18d501930e1a3d83be722027f1f643801afdcc2c255dd4a8R4 has caused the issue, which seems unexpected as the defaultorderImportKind: "ignore"
should have kept previous ordering.Update #1
Digged into the code a bit and as far as I understand that the following lines split A/B import paths into
segments
by/
and wort by each segment accordingly. But that would also mean that first relative traverse parts e.g...
vs.
would always sort to.
>..
ignoring the type of the import, right?Update #2
Found a open discussion about the same problem
#2682
alphabetize.order: "asc"
no longer sorts imports within "sub-group" as before where it first sortedparent
imports, than sibling, index, but threats all group imports as a whole. Before that was a powerful feature to mentally group dependencies in a file from outside in in contextual blocks of what we control and what is related to the file.My config for
import/order
:I found a possible workaround by splitting the parent into its own group. But it is unfavorable as it would touch pretty much all files in the project.
Temporary workaround is to:
The text was updated successfully, but these errors were encountered: