I have import statements which leads to symlinks
import something from 'my-module/some/symlink';
If file is a symlink, I can't use import/external-module-folders because it check path of the actual file (which could lead to a temporary build directory of Bazel), not an import name. Path will not be ...package-folder/my-module/some/symlink, in will be file in some random dolder on disk.
Then, there is a problem.
If file exists, then it considered internal, because it is not in node_modules.
If it not exists, then in considered external, because path can't be resolved and isExternalPath function contains !path condition.
But in our development process these files exists only inside Docker container. So they will be considered external when ESLint runs outside of Docker, and internal if ESLint runs inside Docker.
And, most of all IDE's launced outside of Docker.
I found some relative discussion here. If unresolved file will return 'unknown' I be able to got, at least, consistant output.
https://github.com/benmosher/eslint-plugin-import/pull/1295#issuecomment-467661146
But the real issue can be fixed with ability to mark modules as external/internal by name. Not by path only. Then I be able to mark 'my-module' as external or internal, and it will be considerate so, even if files in it are symlinks.
issues that can be potentialy fixed with ability to mark modules as external/internal by name
https://github.com/benmosher/eslint-plugin-import/issues/1306
https://github.com/benmosher/eslint-plugin-import/issues/1510
PR with feature
https://github.com/benmosher/eslint-plugin-import/pull/1524
Actualy, adding an ability to set module group by regexp could be more flexible.
'import/order': [
'error',
{
groups: [
[
'builtin',
'external',
'absolute',
{match: 'my-module'},
{match: 'bazel-([\s\S]+)'},
],
'internal',
[
'parent',
'sibling',
'index',
],
],
'newlines-between': 'always',
},
],
If it would be concidered as a good decision, I can made a PR.
What does node's require.resolve do? Note that there's a preserve-symlinks option, and we should be matching that default behavior.
Most helpful comment
Actualy, adding an ability to set module group by regexp could be more flexible.
If it would be concidered as a good decision, I can made a PR.