Prefer relative import instead of alias if the import is a subpath#160
Prefer relative import instead of alias if the import is a subpath#160dword-design wants to merge 4 commits intoHeroProtagonist:masterfrom
Conversation
|
@HeroProtagonist Let me know if there is anything left to be done. |
|
Hi @dword-design, Thanks for the information and PR. I like the idea of using the actually library to resolve aliases. The rule is written to not do anything with imports at the same level ( #161 has a windows fix that will get merged in |
|
Hey @HeroProtagonist, the PR should also keep imports at the same level at Regarding the windows, alright good to see there is another PR for it. I'd say wait for it until we have a state here that we can merge and then we can see how to deal with the windows paths (merge from default branch or do something else). Thanks for replying, let me know what you think. |
Summary
There is an inconsistent case when dealing with relative subpath imports.
When importing
./foo/bar, the import is kept and not replaced, which is good. When importingalias/barhowever, the import is not replaced back to./foo/bar, leading to non-deterministic behavior because the convention depends on the current code state. It should be replaced back to./foo/bar. Because then always holds:This has a few implications though. The current implementation is kinda 'specialized' on a single fixer, which is why the fixer is decoupled from the error detection. This will lead to a lot of duplicated code because the error detection has to be replicated in the fixer.
Actually I found this plugin recently and implemented my own one before, so I thought the best idea is to put both together. This PR includes some refactoring and the fixes I already had in my project.
babel-plugin-module-resolverlogic to resolve the aliases\separators in the fixed import pathsWould be great to have this merged! If there are questions or open things to be done, feel free to ask.