Open saiichihashimoto opened 5 months ago
what's your eslint config?
I'm having the exact same issue in an Nx monorepo with the import/no-extraneous-dependencies
rule
@timostroehlein me too! I made an issue for that but, for whatever reason, it got marked as a duplicate of this one.
@saiichihashimoto are they different issues? It read like they were the same.
Maybe they come from the same problem, but they're two different eslint rules
Yeah it's the same issue but for two different rules, so it might be caused by an underlying issue. I'm not using the import/no-unused-modules
rule, so I can't say anything regarding that
I'd assume the import/resolver
should have picked up my tsconfig
s and been fine. I use the compilerOptions.paths
, it seems like that might be where it can't follow anymore? Either way, my repo is littered with // eslint-disable-next-line import/no-unused-modules -- TODO https://github.com/import-js/eslint-plugin-import/issues/3013
from this, so lmk if there's any additional information I can provide.
Would it help to have a minimal repro gist? How can I help?
Curious if it works when you don't have the tsconfig path aliases?
@saiichihashimoto yes, it would help.
So this ended up solving my issue (albeit, causing many other ones). I noticed that, if I ran the linter before building, it acted as expected but didn't after running a build. I believe, since it's using the typescript resolver, it picks up those fields to include regardless of include
and exclude
in a tsconfig.json
. Since in a monorepo the built packages live next to the source for each package, the including package will pick up the built files instead of src, so then all the src seem unused.
Example for clarity:
packages
- a
- package.json
- tsconfig.json
- src
- index.ts
- dist (ONLY after being built)
- index.js
- index.d.ts
- b
- package.json
- tsconfig.json
- src
- index.ts
- dist (ONLY after being built)
- index.js
- index.d.ts
Assume packages/b/src/index.ts
imports @monorepo/a
and that packages/a/package.json
has the main
, types
, and files
as I have in the screenshot.
Before building, packages/b/src/index.ts
will resolve @monorepo/a
to packages/a/src/index.ts
, which is great! After a build however, it will resolve @monorepo/a
to packages/a/dist/index.ts
which is bad because ALL of packages/a/src/index.ts
will be considered unused, even though a linter shouldn't concern itself with built files.
With private packages, deleting those lines in package.json
are fine, because nothing needs them. Also, when you're not in a monorepo you can leave them and be fine, because you don't have anything attempting to import the package itself.
But in a monorepo with public packages (ie, packages meant to be published) this is unavoidable. We can't delete those lines because npm needs them. We can't fix it in tsconfig.json
because, regardless of what's in the include
or exclude
, everything listed in files
is always included. Also, it seems like this must be solvable because, somehow, VSCode knows to resolve those imports to the source files regardless of whether the files are built or not so, whatever they do, it's theoretically replicate-able here.
That thorough analysis seems like a very plausible path forward. Anyone who has time to figure out how they differentiate, and make a PR, would be appreciated.
I'm using a turborepo monorepo and I'm seeing if
packages/A/a.ts
imports frompackages/B/b.ts
, theb.ts
will have it's exports marked as "not used within other modules".