fix(import/order): do not compare first path segment for relative paths #2885
Conversation
mihkeleidast
force-pushed
the
fix-issue-2682
branch
from
8acf528
to
795a9b1
Compare
mihkeleidast
changed the title
| import index from '.'; | ||
| import relParent3 from '../'; | ||
| import relParent1 from '../foo'; | ||
| import sibling from './foo'; |
There was a problem hiding this comment.
This test confuses me. The default group order is has index last so why is it first here?
There was a problem hiding this comment.
I think this configuration ends up so that all other groups are grouped, so the imports are mingled together. Then they are sorted alphabetically, which puts this first.
That's also how it worked in 2.26.0, which is why I added it here. Ideally I would also sort it last, as that would be most logical - for that we can use either pathGroups and distinctGroups options, or your other PR.
|
Can you add the exact test case from the OP of #2682? |
|
@ljharb added! This was a good suggestion, as that particular case needed additional handling. |
|
Not sure what is going on with the failing actions, do not seem related to my changes? |
|
Likely not; i'll rerun. |
|
Hi everyone, do you reckon this PR has a reason to be blocked? Like a lot of people, I've been sticking with v2.26.0 of this plugin since #2682 has been a thing, and I'd very much like to get back to being up-to-date and with imports in the right order 😉 |
|
Any news here? PR looks fine, any blockers I can help getting rid of? |
I think while my fix does work for some of the reported issues, some would still not be fixed by this, e.g. #2722 I could not fix the other issues, so gave up as it does not affect my usecases as much. But probably would help if the fix would resolve all of the different issues that have been reported. |
Should fix the regression in #2682.
The gist of the fix is that for relative paths, siblings always start with "." and parents always start with "..". When comparing them, it will always result in "." being first, which was the bug. The sorting based on subpath segments should start from the second path segment, when there is a possibility that one of them is different.