"X" should be listed in the project's dependencies, in VSCode only

[QAnders]

Running two different node 18 projects from VSCode and get the Lint error on a file (in both separate projects), ESLint 8.48.0 and eslint-config-airbnb-base 15.0.0:
´´´
'@sentry/node' should be listed in the project's dependencies. Run 'npm i -S @sentry/node' to add iteslintimport/no-extraneous-dependencies
´´´
package.json has "dependencies": { "@sentry/node": "^7.69.0" } and it's installed under node_modules with "version": "7.69.0"

Running the lint in terminal it works fine, no linting errors, but VSCode still shows it as a lint error.
Other linting works fine and is "handled" by changing/correcting the lint errors but this won't go away...

VScode ESLint v2.4.2
VSCode v1.81.1

[dbaeumer]

Can you please provide me with a GitHub repository I can clone that demos this. This ensures that we are looking at the same problem / configuration.

[ken1987]

I have encountered the same problem.

In a monorepo project built with pnpm, If the import paths in both projects are the same and use aliases, such as @.

To reproduce the issue, follow these steps:

step 1

If both Project A and Project B have the following code:

// main.ts
import App from '@/other'

// other.ts
console.log('any code')

step 2

When you open main.ts in Project B, an error occurs. However, it works fine in Project A.

'project-a' should be listed in the project's dependencies. Run 'npm i -S project-a' to add it. eslint import/no-extraneous-dependencies

Conclusion of the debug

I found that the issue might be related to the getMappedPath function in eslint-import-resolver-typescript code.

The paths parameter represents a collection of all identical paths within the entire monorepo project. If there are multiple paths, it always returns the first one.

In the example mentioned earlier, this means that the value of paths could be

[
  '/some-path/packages/project-a/src/other.ts', 
  '/some-path/packages/project-b/src/other.ts'
]

and it always returns /some-path/packages/project-a/src/other.ts.

This is the root cause of the subsequent errors.

Possible solutions

The key is to identify the workspace where the file is located instead of treating the entire repository as a workspace. Therefore, the following solutions can be considered:

1

Raise an issue with eslint-import-resolver-typescript.
It is possible to infer the workspace based on the second parameter file in getMappedPath. Once the workspace is inferred, the paths collection will never exceed two paths. This modification can help resolve the issue.

2

In vscode-eslint, consider limiting the workspace: It may be possible to configure vscode-eslint to restrict the scope to the specific workspace, similar to the approach mentioned above. By doing this, the same effect as the solution above can be achieved.

[dbaeumer]

This sound like something that would even happen when executing eslint in the terminal. If this is the case then this should be addressed in the plugin and not in the extension.

[volnei]

Any news?

[dbaeumer]

As commented here #1708 (comment) this sounds like an issue in the plugin itself. I will close the issue for now. If you think this is something that should be addressed in ESLint extension please ping with a GitHub repository I can clone that

• demos the failure in the ESLint extension
• runs correctly in the terminal using eslint command line tooling.