🐛 False positive for `unlisted` when extending a tsconfig file from a package

[me4502]

Prerequisites

• [X] I'm using the latest version
• [X] I've read the relevant documentation
• [X] I've searched for existing issues
• [X] I've checked the list of known issues
• [X] I've read https://knip.dev/guides/issue-reproduction

Reproduction url

https://github.com/me4502/knip-reproduction

Description of the issue

When you include entries exported via package.json exports in a tsconfig file's types field, Knip looks for the full path rather than the package that it's included in for the unlisted check. For example in the reproduction codesandbox, it looks for @monorepo/helper-types/base and @monorepo/helper-types/other, rather than just @monorepo/helper-types which is already included in the dependencies field.

When you extend a shareable tsconfig file coming from a package, Knip will expect any packages mentioned in the "types" field of the shareable config to also be present in all configurations that extend it. This is unnecessary as those are dependencies of the package that serves the shareable tsconfig file.

[webpro]

The repro is inaccessible to me (404)

[me4502]

ah sorry, i seem to have a lot of issues with that codesandbox site disconnecting for me. i'll create a GitHub reproduction case tomorrow.

[me4502]

I've just switched it out with a GitHub repo, and after some investigation i've also slightly altered the issue to better reflect what I believe is the underlying cause.

[webpro]

Thanks for the reproduction.

The problem here is that Knip uses ts.readConfigFile which returns the final TS configuration (per workspace). There's no way to stop when descending into other local workspaces through extends (while we do want to recursively load TS config files local to the workspace).

A solution I can think is a custom TS config reader for the TypeScript plugin that does stop when traversing into other workspaces.

[webpro]

Working on some refactorings and things are coming together nicely, including recursively handling config files in their own workspace. Which is what should handle this case a lot better. It seems to handle the example repo well. This will be included in the next version. You could try an early build if you like:

npm i -D https://pkg.pr.new/knip@c03f963

[me4502]

Thanks, I can confirm that fixes the problem :)

[webpro]

Going to close with the release of v5.34.0