Running in production mode doesn't allow for easy tagging of internal-only files (as opposed to internal exports)

[bryan-codaio]

Reproduction url

https://codesandbox.io/p/devbox/k23sxr

Description of the issue

In the above repro, you can see that in other_util.ts I was able to appease knip by tagging the test-specific export as /** @internal */. However, if every export (i.e. the entire file) is only used by tests, then there's no recourse I'm aware of (other than the ignore in the config) to allow knip to pass.

Ideally we could tag every export of test_util.ts with /** @internal */ and the result would be knip not reporting it as unused in production mode.

Please let me know if I'm somehow made a mistake in my configuration. I'm still wrapping my head around entry vs. project vs. ignore, and production vs. not.

This is related to #706 and there may be overlap, but my gut said the solution to the two issues would be separate.

[webpro]

Oh no:

Devbox not found
It's likely that the Devbox you're trying to access doesn't exist or you don't have the required permissions to access it.

[bryan-codaio]

Oh no:

Devbox not found
It's likely that the Devbox you're trying to access doesn't exist or you don't have the required permissions to access it.

my bad, changed sharing settings to public. First time dealing with a devbox via codesandbox 😅

[webpro]

I think what you're after is to exclude test_util from the production project file set:

{
  "$schema": "https://unpkg.com/knip@5/schema.json",
  "entry": ["index.ts!", "test.ts"],
  "project": ["*.ts!", "!test_util.ts!"]
}

The general case with e.g. **/*.test.ts is handled automatically for plugins (i.e. they're excluded in production mode). This "test util" case is a weak spot indeed, yet can be overcome by manually excluding them in production mode using double exclamation marks.

[bryan-codaio]

I think what you're after is to exclude test_util from the production project file set:

we could do that, but I agree with the philosophy in #706 that ideally we wouldn't have a typical workflow that involves users changing arrays in config files.

That example ought to demonstrate what I see the issue being. For a file that's got internal and production exports i.e. other_util.ts, it suffices to add /** @internal */ to the one internal export testOnlyUtil. However, say someone comes along and refactors other_util.ts and removes usedUtil - it's awkward that it suddenly becomes a necessity to add this file to knip.json.

[webpro]

Let's keep only #706 open for discussion.