💡 Exclude unused files from findings by annotating the exports with `@public`

[MatissJanis]

Suggest an idea for Knip

Currently the unused-files rule reports all unused files. The only way to exclude some files is by modifying the global config object. Which is not ideal for large monorepos.

Ideally we would like individual teams to own which files should not be reported as unused.

Hence the recommendation: if a unused file has annotated the export as @public - exclude this file from "unused-files" violations.

[webpro]

Currently, Knip doesn't even read the unused files at all.

Semantically, not sure if your suggestion results in clear DX. Maybe some annotation in the head of the file so not even the whole needs to be parsed might make sense.

For now, perhaps it's an option for the root config to read from workspaces so they can be managed separately?

[fregante]

Perhaps: https://jsdoc.app/tags-file

So:

/**
 * @file Manages the configuration settings for the widget.
 * @public
 */

But I'm sure there are better ways to mark files as public, for example by having a clear way to define them as public as part of your specific package (see exports field in package.json) rather than touching knip's config

[webpro]

The file isn't necessarily meant to be public, maybe it should just be excluded (temporarily) from the report for whatever reason.

[MatissJanis]

For now, perhaps it's an option for the root config to read from workspaces so they can be managed separately?

Would you mind expanding on this? I don't follow the idea here.

[webpro]

Ah sorry, forgot some words.. what I wanted to express is that it could import files that contain the partial lists of files to ignore. E.g. from the root knip.config.ts:

import knipConfigWorkspaceA from "./packages/A/knip.config.ts";

export default { ignore: [...knipConfigWorkspaceA.ignore] }

[MatissJanis]

That gets complicated real fast. We would need to get a list of all the workspaces and then dynamically scan all of them to see if they have a knip.config.ts file. Next we would have to dynamically require these and merge them in the root config file whilst also mutating all the paths in the workspace config files (since they would not be FULL paths, but relative paths to the workspace).

And then there are unanswered questions.. should all config values be merged (i.e. entries too? what about exclude or the plugin-specific configs)? If they are not merged: how will the consumers (workspaces) know that these configs are not used?

IMO it gets hairy really quick with this proposal.. I would love if there was an easier first-party solution for this.