🐛 knip does not follow tsconfig paths

[jameshfisher]

Prerequisites

• I'm using the latest version
• I've read the relevant documentation
• I've searched for existing issues
• I've checked the list of known issues
• I've read the issue reproduction guide

Reproduction url

https://github.com/jameshfisher/knip-bug

Reproduction access

• I've made sure the reproduction is publicly accessible

Description of the issue

Steps to reproduce:

1. git clone https://github.com/jameshfisher/knip-bug, a minimal repro
2. pnpm i
3. pnpm run knip

Expected behavior: no unused files

Actual behavior:

pnpm run knip

> q@1.2.3 knip /Users/jim/dev/granola-inc/knip-bug
> knip

Unused files (1)
common/bar.ts

The file common/bar.ts is claimed to be unused. However it's used by src/main.ts, which is an entry point.

The import ... from "@qux/common/bar" should resolve to common/bar.ts because of the "@qux/common/*": ["common/*"] in tsconfig.json. This can be seen with pnpm run start, which resolves the import.

[jameshfisher]

I also ran with --debug, but couldn't make much sense of it. What I wanted to see was: where does knip believe "@qux/common/bar" resolves to, which is different to common/bar.ts? And that different filepath presumably points to a non-existent file, so why doesn't knip give an error about that?

[jameshfisher]

The debug tool I'm looking for is a dependency graph between files, e.g. dotfile output. I can see many knip outputs, but none that show me resolved file dependencies

[jameshfisher]

I've also tried knip-bun, but it gives the same unexpected result

[webpro]

The file is resolved fine. However, the issue is that while using tsonfig.json#compilerOptions.paths is obviously valid from a TS perspective, it's something that Knip doesn't handle well. That's because it's handling workspaces separately, and when wiring things back together this done by the dependencies cq package names (not path aliases).

The recommendation is to use dependencies from package.json#dependencies over tsonfig.json#compilerOptions.paths to target internal workspaces.

Briefly explained here: https://knip.dev/reference/faq#why-cant-i-use-path-aliases-to-reference-other-workspaces. Definitely could be documented better, and obviously, ideally shouldn't be an issue at all.

Basically dup of #961.

[jameshfisher]

@webpro aha, thanks! We'll give that a try. I think we have other reasons that we're using paths instead of dependencies, but maybe we can fix these reasons

[webpro]

Looked at the implementation again and came to the same conclusion, which I've now tried to document a bit better: https://knip.dev/guides/handling-issues#typescript-path-aliases-in-monorepos ↔ https://knip.dev/reference/faq#why-cant-i-use-path-aliases-to-reference-other-workspaces

[webpro]

🚀 This issue has been resolved in v5.46.0. See Release 5.46.0 for release notes.

Using Knip in a commercial project? Please consider becoming a sponsor.