[import/no-internal-modules] no-internal-modules not checking configured tsconfig paths that have @ prefix

[rudwna]

The problem is I have project with configured tsconfig.paths that have pattern/substitution style similar to those from the tsconfig documentation:

{
  "compilerOptions": {
    "paths": {
        "@modules/*": ["src/modules/*"],
        "@shared/*": ["src/modules/shared/*"],
        "@notification/*": ["src/modules/notification/*"],
        "@forbidden/*": ["src/modules/forbidden/*"]
    },
}

For these modules, I want to use import/no-internal-imports to enforce dependency control by allowing import of a module to only certain allowed dependency at what's exported at top level index files only.

For example, if I'm inside notification modules with the configured rule:

    "import/no-internal-modules": [ "error", {
          "allow": [ "@modules/shared" ]
    } ]

it should allows

import { something } from '@modules/shared'` 

and disallows

import { someDeepThing } from '@modules/shared/internals/code'

and

import { fobiddenThing } from '@modules/forbidden'

but seems like using @ symbol for tsconfig.paths is getting in the way.
Currently, if I have a file inside src/modules/notification that have an import from @modules/forbidden, currently it'll pass the check.

From looking into the code, I've found this part where we drop the scope of an import path:

eslint-plugin-import/src/rules/no-internal-modules.js

Lines 85 to 86 in 6d34c88

	const nonScopeSteps = steps.filter((step) => step.indexOf('@') !== 0);
	if (nonScopeSteps.length <= 1) { return false; }

And left with only ["forbidden"], which will result in returning false and make the rule passed. Trying to change @ prefix to something else like an emoji make it works as expected

I have eslint-import-resolver-typescript installed
Is this expected behavior or actually the path that checked against the rule should be resolved path from ts-resolver before checking?

From what I know, using @ as a tsconfig path pattern is quite common.

[ljharb]

quite common

hmm, that'd be surprising to me, since @ is already a meaningful character in npm packages - it means it's a scope. I'd strongly suggest considering an alternate character that can't mean anything else.

I'm not sure yet whether I consider this a bug or not.

[rudwna]

I probably overstated about commonality. But at least that’s what I’ve seen in tsconfig.paths examples around the web. Will switch to another character. Thanks for the information.