Error unable to resolve path to module. eslint import/no-unresolved but only in VSCode, not in ESLint CLI

[alexleboucher]

I upgraded the package eslint-import-resolver-typescript from 3.7.0 to 4.2.1 and VSCode ESLint shows errors unable to resolve path to module. eslint import/no-unresolved on my imports.

I created an issue on the eslint-import-resolver-typescript repo (import-js/eslint-import-resolver-typescript#396) but as the error is related to VSCode and not ESLint CLI, the main contributor suggested me to create an issue on your repository.
The package uses a napi module: rspack-resolver under the hood.

You can easily reproduct the issue by cloning my project : docker-express-postgres-boilerplate and upgrading the library eslint-import-resolver-typescript

[dbaeumer]

I am not able to reproduce this

Any additional things I need to do?

[thewilkybarkid]

I'm seeing something similar. I'm also seeing:

(There's one of these for each of the import/* rules enabled.)

This could be a macOS-only problem?

[alexleboucher]

Yes, I'm on mac.

Nope, no additional things you need to do. I only have to upgrade this library and I see errors...

[hyorimitsu]

I'm also facing the same issue. It seems to be reproducible when upgrading eslint-import-resolver-typescript to version 3.9.0 or later. For reference, I'm also using a macOS.

[alexleboucher]

I am not able to reproduce this

Any additional things I need to do?

I saw you tagged the issue as info-needed. Is someone in the repo team able to reproduce it now?

[renchap]

I am also facing this issue. It happens for the non-relative imports that use aliases defined in tsconfig.json, and only for the non-type imports somehow:

If I run eslint manually from this file in the terminal, it does work correctly.

I am using a monorepo, with "eslint.workingDirectories": [{ "pattern": "./packages/*/" }].

Is there a way to get more information to understand what is different between eslint ran from the VSCode extension vs from the CLI?

[dbaeumer]

@renchap do you have a GitHub repository I can clone that demos this. May be I can reproduce it there. Without being able to reproduce the error it is very hard to say what is the root cause of this.

[Serhansolo]

Hi, I am also facing this issue!

You don't need a repo, just install vue with create vue (npm create vue@latest)

I have a fresh installation of Vue with vue-create. I am therefore using the flat-config.

With these settings (w/o OxLint):

For some reason, the default installation of Vue does not use the '@' alias. Once I change the imports to use the alias, I see the mentioned error.

Vue comes with a default eslint.config.ts file. In my new project, I tried numerous setups. With the TS config file. Using the Vue helpers and also a config from scratch… I noticed that sometimes, for pure random reasons, the IDE does resolve the paths… but after a while, it stops working.

--EDIT--

Using the same command, I created a Vue project without TS.

The CLI creates an eslint.config.js file instead. With this setup, it does work.

I hope you can locate the issue… Because the issue is definitely in the vscode plugin for ESLint. When running ESLint in the CLI in both setups, I get the expected results. As in, no import errors.

--EDIT--
I use a Windows x64 machine, by the way.

[dbaeumer]

@Serhansolo I would really prefer a GitHub repository I can clone. This ensures that I do use the same exact content and settings as you do. This repository should also contain you local VS Code settings if you changed any.

[Serhansolo]

Ah, gotcha.

I will get to it asap. I am occupied right now. I will make a report with all relevant local settings also. I will put those in a settingsfile in the repo..

[Serhansolo]

Okay, I cannot believe this. I just arrived at my workplace only to realize that the screenshots I took earlier were fixed by elves. I cannot reproduce it anymore.

[renchap]

I still do not have a repository reproducing this, but I managed to figure out how to fix it:

In my package's eslint.config.mjs if I add:

    settings: {
      "import/resolver": {
        typescript: {
          project: "<root>/packages/web/tsconfig.json",
        },
      },
    },

Then it works. My package is located in packages/web from the root of the git repository (and root of the VSCode project).

So it looks like the cwd is somehow incorrect when eslint is invoked from vscode, and/or eslint-import-resolver-typescript does not set it correctly?

[renchap]

And another update: it worked for a few minutes, I continued to try to figure out a working config without this hardcoded path, and now the no-unresolved errors are back in vscode.

Could it be a different behaviour depending on the current active file when the eslint server is started, or something similar?

When hardcoding this path to the full absolute path of the tsconfig.json file, then I am not able to reproduce it in any situation.

[Serhansolo]

Yo @renchap, I have had the same problems after the overnight elves fixed my vscode, I returned to work over the weekend, and guess what, red scribbles everywhere....

Then, after some vigorous googling, I found this baby: https://www.npmjs.com/package/eslint-import-resolver-typescript

Important notice: I am using import-x instead of import, according to the docs, it's faster. The rules are pretty much the same, you have to change the package and rule prefix.

This is my entire config, take out of it what you need, but pay attention to the import-x/resolver-next bit, that does the magic.

  // import plugin
  flatConfigs.recommended,
  flatConfigs.typescript,
  {
    rules: {
      "import-x/consistent-type-specifier-style": ["error", "prefer-top-level"],
      "import-x/first": "warn",
      "import-x/newline-after-import": ["error", { count: 1 }],
      "import-x/no-absolute-path": "error",
      "import-x/no-relative-packages": "error",
      "import-x/order": "off",
      "sort-imports": "off",
      "sort-keys": "off",
    },
    settings: {
      "import-x/resolver-next": [
        createTypeScriptImportResolver({
          project: "./tsconfig.app.json",
        }),
      ],
    },
  },

[iwan-uschka]

I faced the same issue after migrating from yarn (v1) to pnpm. According to https://stackoverflow.com/a/78709106/3042035 i added the packages to the devDependencies of the root package.json and voilá, VS Code is happy. I am sure, this is not a fix but hopefully a workaround for now.

EDIT: Damn, i tricked myself :(

[lucaslcode]

I encountered this and was able to fix it by uninstalling the VSCode eslint plugin (both on remote and local, I am using WSL), restarting vscode, and reinstalling the plugin

[iwan-uschka]

People never get tired of switching it off and on again :) Thx @lucaslcode. Unfortunately it doesn't really fix the problem on my machine/in my situation.
I am working in a monorepo with different packages. Each package has a name like @repo/package-a and a tsconfig.json like

{
  "compilerOptions": {
    "paths": {
      "@repo/package-a/*": ["./*"]
    }
  }
}

to enable absolute-ish imports like

import SomeComponent from '@repo/package-a/src/components/SomeComponent

in this package.

To be able to do the same import in another package @repo/package-b that package must have a tsconfig.json like

{
  "compilerOptions": {
    "paths": {
      "@repo/package-a/*": ["../../packages/package-a/*"],
    }
  }
}

Everything works outside of VS Code. ESLint, TS check.

---

I just noticed something odd: ESLint in VS Code works for aliases defined in tsconfig of the package which has been opened first. So if i start a blank VS Code and open a file from package-a everything works. If i then open a file from package-b VS Code displays

Unable to resolve path to module '@repo/ui/src/util/testAttributes'.eslintimport/no-unresolved

This is odd.

[iwan-uschka]

@renchap do you have a GitHub repository I can clone that demos this. May be I can reproduce it there. Without being able to reproduce the error it is very hard to say what is the root cause of this.

Hi @dbaeumer, can you have a look at https://github.com/iwan-uschka/vscode-eslint-issue-1994/tree/feature/with-flaky-error please? I added a README how to reproduce the odd behavior.

I have to say that i wasn't able to create a monorepo from scratch reproducing this error. I ended up forking my project, removing everything unnecessary and adding some more code for testing purposes. Admitting that i am not sure if this is really/only a bug in some plugin or a misconfiguration of ESLint and/or TS in this repo.

---

My setup:

• [email protected]
• VS [email protected]
• [email protected]

[dbaeumer]

@renchap in general ESLint is very sensitive to the working directory. So if you have a mono repository you need to let the extension know the working directory that should be used when validating files. This is best done using the eslint.workingDirectories setting.

If you specify this then relative pathes in the config files should work as expected.

[renchap]

I have this config:

    "eslint.workingDirectories": [
      { "pattern": "./packages/*/" },
    ],

I also tried to list the packages directly, but it still sometimes stop working randomly

Right now the only way I found to not have those random breakages is to hardcode the path in the eslint import config:

    settings: {
      "import/resolver": {
        typescript: {
          project: "/Users/renchap/dev/project/packages/web/tsconfig.json",
        },
      },
    },

If I omit it, or use a relative directory, after some point eslint ran by the vscode plugin stops resolving the paths proprely.

[iwan-uschka]

Thank you @renchap!! After referencing TS config in ESLint config like

import path from 'node:path';
import { fileURLToPath } from 'node:url';

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);
const tsConfigEsLintPath = path.resolve(__dirname, 'tsconfig.eslint.json');

const config = [
  ...
  {
    settings: {
      'import/resolver': {
        typescript: {
          project: tsConfigEsLintPath,
        },
      },
    },
  },
];

export default config;

(iwan-uschka/vscode-eslint-issue-1994@36405e5)

i couldn't reproduce the issue 🎉 So cool. Hopefully the problem is now fixed and not just less flaky.

---

@dbaeumer Before in my demo monorepo i gave

"eslint.workingDirectories": [{ "pattern": "./{apps,packages}/*/" }]

and

"eslint.workingDirectories": ["./apps/storybook-ui", "./packages/ui", "./packages/ui2"]

a try without any luck.

[JounQin]

Seems same of import-js/eslint-import-resolver-typescript#447 (comment)

Maybe eslint.runtime：node: https://github.com/microsoft/vscode-eslint#:~:text=is%20false.-,eslint.runtime,-%2D%20use%20this%20setting would help.

[dbaeumer]

@iwan-uschka I tried your original repository and even without any tweaking I was not able to reproduce this.

[dbaeumer]

@renchap do you have repository I can clone that demos what you are seeing. I would like to understand why relative paths don't work for you.

[JounQin]

@dbaeumer Did you check import-js/eslint-import-resolver-typescript#447 (comment)?

I think this issue could happen when installing VSCode as arm64 arch, but installing unrs-resolver in terminal in x86_64 although I don't know what's happening, maybe the system Node binary is installed via Rosetta 2? cc @valleywood

Anyway, maybe a new target universal-apple-darwin for napi-rs would help.

[dbaeumer]

@JounQin thanks. This comment #1994 (comment) is definitely related to your link. @thewilkybarkid

[iwan-uschka]

Thanks @dbaeumer for looking into it!

Curious about #1994 (comment). I am running macOS on an Apple M1 (Silicon, arm64).

[JounQin]

@iwan-uschka Can you help to confirm:

1. What's installed under node_modules/@unrs/resolver-binding-*
2. What's your VSCode's binary arch?
3. What's your Node's binary arch?
4. Does eslint.runtime: node VSCode setting works for you?

[iwan-uschka]

@JounQin, here we go:

1. Does the info about an existing node_modules/.pnpm/@[email protected]/node_modules/@unrs/resolver-binding-darwin-arm64/package.json help?
2. How to determine that?
3. How to determine that?
4. No

[JounQin]

@iwan-uschka Thanks.

1. Yes, it indicates arm64 is resolved instead of x86_64
2. 
3. node -p "process.arch"
4. OK, unfortunate

[iwan-uschka]

Missing bits:

2. VS Code:

Version: 1.99.3 (Universal)
Commit: 17baf841131aa23349f217ca7c570c76ee87b957
Date: 2025-04-15T23:18:46.076Z (3 wks ago)
Electron: 34.3.2
ElectronBuildId: 11161073
Chromium: 132.0.6834.210
Node.js: 20.18.3
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.4.0

3. arm64

[JounQin]

OK, then that's really a new issue compared with import-js/eslint-import-resolver-typescript#447 (comment)... I have no idea.