There's a lot of layers and indirection to this repro - tsconfigs extend tsconfigs, ESLint configs extend ESLint configs which extend utility functions from npm, linting is done by a separate tool.

Could you please slim the repro down a bit? Ideally the only npm deps should be TS, ESLint, and our parser+plugin.

Thanks @bradzacher - i've simplified the repository now.

• Removed the config packages, and put the config directly into one and two packages.
• Remove the dependency on the linting setup and put the minimal eslint config into the packages.

I'm not sure what you mean by "linting is done by a separate tool". It's only using eslint. There is Nx (monorepo tooling) invoking this on each package but that's it.

If you would like to avoid this you can:

1. cd packages/two
2. pnpm lint

It's worth noting that whilst this is using the flat config, I was previously using the .eslintrc.js file and had the same issues.

I've also tried using the EXPERIMENTAL_useProjectService option based on this issue:
#2094

But that doesn't seem to make a difference in this scenario.

I haven't had a chance to check things out locally yet but looking around at the setup - it makes sense that it's not working.

Even though your second package is part of the monorepo - it's imported as if it were an npm package and its source is included via a symlink that's managed by pnpm.

TypeScript doesn't respect the tsconfig of npm packages. If you want it to understand that the you will need to leverage project references like we do in our repo.

Ah, I see what you're saying. And you're right even though VSCode shows the name of the type, it doesn't know what that type actually is. I'll close the issue as you're right it's about how typescript is behaving and not the linting.

FYI, I just tried to use project references, and got the same errors. I believe it's because of this:

From Caveats for Project References

Because dependent projects make use of .d.ts files that are built from their dependencies, you’ll either have to check in certain build outputs or build a project after cloning it before you can navigate the project in an editor without seeing spurious errors.

If this requires a build step, then I think I might prefer to build the package and its types and expose it through the package.json module and types properties.

Something like:

  "module": "./dist/index.js",
  "types": "./dist/index.d.ts",

The downside is that things won't be as dynamic for a development experience. This can be worked around by having a build watch the files for changes. I was trying to avoid doing that, hoping there was a lighter weight solution.

Thanks for your help, and quick responses :)