🐛 Non-standard workspace package names always reported as unused

[adamaveray]

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 the issue reproduction guide

Reproduction url

https://codesandbox.io/p/devbox/knip-bun-isolated-installs-bug-gzzpkv

Reproduction access

• [x] I've made sure the reproduction is publicly accessible

Description of the issue

~~Bun's isolated installs require explicitly declaring workspace dependencies within the same project, however Knip always flags those workspace dependencies as "unused".~~

Defining internal workspace packages using non-standard/non-NPM-compatible names (e.g. @/package-name, _.package-name, etc) resolves and works without issue (at least with Bun), however Knip will always report them as "unused dependencies" even if they are used.

There is also no way to suppress these issues as even after adding the workspace dependencies to ignoreDependencies the "Unused dependencies" error is shown.

[webpro]

@/internal isn't a valid package name?

[adamaveray]

@webpro Thanks for checking the issue, while that is an "invalid" name Bun does allow that for workspace packages and I find that kind of pattern useful to make it obvious what are internal packages and prevent any shadowing of a real NPM package.

I've updated the demo to also try a "valid" package name and that does work correctly, so it turns out the issue I wanted to report was that Knip doesn't support non-NPM-compatible package names (I've renamed this issue accordingly). Is that by design?

[webpro]

Knip doesn't support non-NPM-compatible package names (I've renamed this issue accordingly). Is that by design?

Yes. Not sure we should even try and go there. There is already a lot going on around module resolution and detecting package names, etc. Sorry!

[adamaveray]

@webpro Fair enough. The current rules however do not identify some strange yet completely valid NPM package names (e.g. @!!!!!/elemental, @-ui/grid, etc) which run into the same false positive issue, so perhaps the rules do need tweaking to handle those kinds of valid package names?

From what I can tell the regex in modules.ts is the issue there. Would you accept a small PR (including tests) to handle these kinds of additional valid package names?

[webpro]

Thanks, but we don't need to find such absolute edge cases for unused packages just for the sake of it that might lead to issues. See https://github.com/npm/validate-npm-package-name/pull/156 for an example + reasoning.