(VSCode) False positive of rule import-x/no-unresolved in monorepo with multiple packages open

[auirarrazaval]

Hello! Im having the following issue when using VSCode with Eslint and Import-x. I'm opening this issue here because this is the only package where the issue arises, all other work properly. If this is not correct, please let me know

I have monorepo setup with a shared config file. there, I have "bundles" of plugins that my apps and packages can use. The bundle that sets up this extension is the following:

import { createTypeScriptImportResolver } from 'eslint-import-resolver-typescript';
import { importX } from 'eslint-plugin-import-x';
import noRelativeImportPaths from 'eslint-plugin-no-relative-import-paths';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  importX.flatConfigs.recommended,
  importX.flatConfigs.typescript,
  {
    settings: {
      'import-x/resolver-next': [
        createTypeScriptImportResolver({
          project: [
            'tsconfig.json',
            'apps/*/tsconfig.json',
            'packages/*/tsconfig.json',
          ],
          alwaysTryTypes: true,
        }),
      ],
    },
  },
  {
    rules: { //... },
  },
);

This works well in the case I open just one app (lets say I open the workspace apps/my-app-1 directly instead of the root directory of the monorepo. However, when I open the root directory, i have the following behavior:

• I open a file inside apps/my-app-1, then the extension detects imports properly, without issues
• After opening the previous file, I open any file in apps/my-app-2, then the extension fails to find the local aliased imports:
  

It seems to me like there's an issue with the path alias @/ that is not being updated when I change apps inside the monorepo, but I could be totally wrong.

I have created a small reproduction link, with instructions in the readme:
https://github.com/auirarrazaval/import-x-bug-no-unresolved-bug

[petercat-assistant]

It seems like you're experiencing an issue with the import-x/no-unresolved rule in a monorepo setup when using VSCode. The problem arises when you open the root directory of the monorepo, and the extension fails to resolve local aliased imports after switching between different apps.

Here are a few suggestions to troubleshoot and potentially resolve this issue:

1. Check Path Aliases in tsconfig.json: Ensure that the path aliases are correctly defined in each tsconfig.json file within your apps and packages. The path alias @/ should be consistently defined across all configurations.

2. Verify ESLint Configuration: Double-check your ESLint configuration to ensure that the resolver settings are correctly applied. The createTypeScriptImportResolver should be properly configured to handle multiple tsconfig.json files.

3. VSCode Settings: Sometimes, VSCode might cache certain settings or extensions. Try reloading the VSCode window or restarting it to see if the issue persists.

4. Reproduction Repository: Since you've provided a reproduction link, it might be helpful to share this with the maintainers of the eslint-plugin-import-x to get more specific insights or fixes.

5. Check for Updates: Ensure that all your dependencies, including VSCode, ESLint, and the relevant plugins, are up to date. Sometimes, issues are resolved in newer versions.

If these steps do not resolve the issue, you might want to reach out to the maintainers of the eslint-plugin-import-x with the reproduction repository link you provided. They might be able to offer more targeted assistance or identify if it's a bug that needs fixing.

If you need further assistance or have any more questions, feel free to ask!

🪧 Tips

For further assistance, please describe your question in the comments and @petercat-assistant to start a conversation with me.

[EDM115]

yup, started to see this recently too, and when running ESLint in the CLI it works perfectly fine

[EDM115]

@auirarrazaval I got really tired of issues between packages of the ESLint ecosystem, ever since the switch to the (very great) Flat config it seems like there's something that breaks every week, package authors release more updates than ever and sometimes it's hard to keep up.
In the 16 weeks of my internship, i had to fix 4 times issues between ESLint plugins, whether it being import, typescript or something else. Broken support in VS Code is a hassle too and getting it to work properly in a monorepo with shared configs is an absolute nightmare

I would really recommend to anyone trying to keep their sanity to switch to OxLint, they got most if not all rules you need (both from import-x and typescript-eslint), besides you should not rely on ESLint to catch TS issues, IDE integrations should get you covered and i'll advise for running a good tsc --noEmit alongside your lint commands to double-check

finally, if you really depend on plugins that don't have their rules ported to OxLint, keep ESLint but enable just those to remove the performance hit and all the goddamn inconsistencies between all those plugins.
doing so saved us 2min40 in lint times (95%, now barely at 5s for 17 packages), dropped 118 dependencies (8%) and finally allows me to sleep without fearing of the next breakage of the lints right before I finish my internship

[JounQin]

I think you should report to https://github.com/microsoft/vscode-eslint instead.

[EDM115]

linked issue : microsoft/vscode-eslint#1994

[JounQin]

@auirarrazaval Would you like to give the following a try?

# npm
npm i -D https://pkg.pr.new/eslint-plugin-import-x@388

# yarn
yarn add -D eslint-plugin-import-x@https://pkg.pr.new/eslint-plugin-import-x@388

See also #388