`no-unresolved` JS alias regression in 3.8+

[RobHannay]

Since 3.8 aliases are no-longer being resolved in .js files.

I've read a few of the issues raised about 3.8, but I think this is separate. I have tested with 3.8.3 and still face the issue.

We use aliases that are actually defined in three possible places:

• webpack.config
• jsconfig
• tsconfig

Perhaps it was never intended to resolve imports from js files?

It's fine is I use relative paths with lots of ../.

We have a verbose config but the key details are:

{
  eslint.configs.recommended,
  ...tseslint.configs.recommendedTypeChecked,
  importPlugin.flatConfigs.recommended,
  {
    languageOptions: {
      parserOptions: {
        projectService: true,
        tsconfigRootDir: import.meta.dirname,
      },
    },
  },
  {
    files: ['**/*.js', '**/*.mjs'],
    ...tseslint.configs.disableTypeChecked,
  },
  {
    languageOptions: {
      globals: {
        ...globals.node,
        ...globals.jest,
      },
    },
    settings: {
      'import/parsers': {
        '@typescript-eslint/parser': ['.ts', '.tsx'],
        '@babel/eslint-parser': ['.js', '.mjs'],
      },
      'import/resolver': {
        typescript: {
          alwaysTryTypes: true,
        },
      },
      // Gives false positives because RRD has two versions in our dependency tree.
      'import/ignore': ['react-router-dom'],

      'import/internal-regex': aliasesRegex,
    },
    rules: {
      'import/order': [
        'error',
        {
          'newlines-between': 'always',
          groups: ['type', 'external', 'internal', ['parent', 'sibling', 'index'], 'object'],

          alphabetize: {
            order: 'asc',
          },
        },
      ],

      'import/no-cycle': 'error',

      'import/no-unresolved': [
        'error',
        {
          caseSensitiveStrict: true,
        },
      ],

      'workspaces/no-cross-imports': [
        'error',
        {
          allow: '@blink/core',
        },
      ],

      'no-restricted-imports': [
        'error',
        {
          patterns: [
            {
              group: ['*.css', '!*.module.css'],
              importNames: ['default'],
              message: 'For CSS modules, use the `.module.css` extension.',
            },
          ],
        },
      ],

    },
  },
}

Happy to try and create a proper repro repo. Do you have a base I can clone?

[carlocorradini]

The aliases are resolved only if the file is included from the corresponding tsconfig.json or jsconfig.json.
If you specificy an alias (i.e. A) in tsconfig.json, and file X has the alias but it's not present in include or files of tsconfig.json then it's not resolved.
How do you include the corresponding file in your configuration?

[RobHannay]

tsconfig just has a blanket

   "include": ["**/*.ts", "**/*.tsx"],

jsconfig has none of the above.

I can't work out what specifically in 3.8 has changed this behaviour

I've also tried adding

  "include": ["**/*.js"],

to my jsconfig but it's not removed the error.

I know it's possible this could have been an unintentional feature, supporting alias resolution in JS files, but should it revert to Webpack resolution throughout ts/js files as that's what's really being done during builds?

Is there a way that I can debug the resolved alias paths?

[carlocorradini]

Can you create a repro for a better context (Thanks)

[mkosir]

Not sure if the same issue 🤔 but I’m experiencing similar in project react-parallax-tilt.
You can reproduce it by upgrading the dependency version to latest 3.8.3 and running npm run lint

[carlocorradini]

Mhmhm I see a lot of ../ in both include and exclude.
Tomorrow I'll try to find the cause.
@SuperchupuDev do you think we have something similar to the other issue?

[SuperchupuDev]

oh! @mkosir just to confirm, if you do <your package manager of choice> why tinyglobby it shows up as 0.2.12, right?

@carlocorradini probably! it's definitely related to the same function :P but i need a minimal repro (as in glob calls, not an entire react project) to investigate regardless

[estiller]

HI, I'm using NX as a monorepo tool, and I see the exact behaviour as well. NX relies on aliases in tsconfig to manage inter-package dependencies, and when I upgrade to eslint-import-resolver-typescript version 3.8.0 or above (including 3.8.3) I get the exact same error as OP. It works fine up to version 3.7.0.

I ran pnpm why tinyglobby, and it indeed resolved to 0.2.12. I tried overriding it to use 0.2.10, but I got the same result.

[carlocorradini]

@estiller Can you provide a repro?
Thanks

[RobHannay]

Here's a repro https://github.com/RobHannay/typescript-import-resolver-repro

Version pinned to 3.7.0 which works fine. Bumping up to 3.8.3 causes the lint error in app/app.js

[pralkarz]

Not sure if the same issue 🤔 but I’m experiencing similar in project react-parallax-tilt. You can reproduce it by upgrading the dependency version to latest 3.8.3 and running npm run lint

I'm not sure about the other issues listed here, but I investigated this one in particular, and it seems like it's potentially a problem with get-tsconfig. After https://github.com/mkosir/react-parallax-tilt/blob/main/tsconfig.json is resolved by extending https://github.com/mkosir/react-parallax-tilt/blob/main/scripts/tsconfig.dev.json, "include": ["../.", "../.storybook/**/*", "../.commitlintrc.ts"] gets parsed as [ '', '.storybook/**/*', '.commitlintrc.ts' ] and passed to tinyglobby there:

eslint-import-resolver-typescript/src/index.ts

Line 463 in b61fb4a

? globSync(tsconfigResult.config.include, {

The empty string doesn't match anything and the no-unresolved errors are raised. When manually patching that string to be '.' or './**/*', everything works fine.

A workaround could be to change ../. to .././**/* (in which case get-tsconfig parses it as **/*), but a more robust fix should probably happen in get-tsconfig. I'm not sure why it parses ../. into an empty string instead of ..

[carlocorradini]

@pralkarz Wow thanks for your discovery/help.
Tomorrow I'll try the other repro

[RobHannay]

Here's a repro RobHannay/typescript-import-resolver-repro

Version pinned to 3.7.0 which works fine. Bumping up to 3.8.3 causes the lint error in app/app.js

Just went through a bunch of stuff to clean out some definitely-unrelated bits of the config and have pushed that up now too.

Here's the evidence of that repro:

[pralkarz]

Here's a repro https://github.com/RobHannay/typescript-import-resolver-repro

Version pinned to 3.7.0 which works fine. Bumping up to 3.8.3 causes the lint error in app/app.js

I took a look at this one too. Seems like mapping aliases is handled differently in 3.8.x vs 3.7.0. In

eslint-import-resolver-typescript/src/index.ts

Line 414 in b61fb4a

mappers = projectPaths

the mappers are created, but aren't used in any way while globbing, and only returned at the end. I'm not very familiar with this logic, so I can't gauge what goes wrong there, but it seems like it's unrelated to tinyglobby. 🤔

EDIT after some more digging (disregard the above guess): Adding '**/*.js' to tsconfig.json fixes the issue. Without it, app.js file isn't matched, and so the .has check at

eslint-import-resolver-typescript/src/index.ts

Line 309 in b61fb4a

.filter(({ files }) => files.has(file))

never returns true. I've compared that to how it was handled in 3.7.0, and removing the filter seems to fix the issue as well, although it makes the linting a little bit longer.

CC: @carlocorradini @RobHannay @SuperchupuDev

[carlocorradini]

@pralkarz @RobHannay
This is the correct behavior.
If app.js (or any other file) is not included in your tsconfig.json, how does that file determine the correct path mapping?
Version prior to 3.8 check if that path is known even if it is not found in any of the known tsconfig.json (or jsconfig.json) files. This raises multiple issues. One example is where the same mapping alias appears in various tsconfig.json files, but the destination (file referred to) differs. The latter is widely used in monorepo, where each package might have the same mapping alias (i.e. @), but the destination corresponds to the src directory of that package.
See issue #246

[RobHannay]

Thanks @carlocorradini, that makes sense! As I suspected then, in that we were actually relying on a bug.

I know bug fixes aren't usually considered "breaking" in the traditional sense, but I wonder if this (correct) behavioural change might cause breakages for a number of people that were relying on it.

Are you saying that adding include to my jsconfig should also match the paths in there to resolve this issue for me?