💡 Entries may have unused exports

[remcohaszing]

Suggest an idea for Knip

Knip treats the exports of all entries as used. However, not all exports are always used. For example, consider the following project:

// package.json
{
  "type": "module",
  "bin": "./lib/bin.js",
  "exports": "./lib/exports.js",
  "devDependencies": {
    "knip": "^5.0.0"
  }
}

// lib/exports.js
// This function is exported via `package.json` exports. So it’s actually used.
export function used() {}

// lib/bin.js
// This function is only exported via the `package.json` `bin` field. So it’s unused.
export function unused() {}

// knip.config.js
// This module is used by Knip. Only the default export is used.
export function unused() {}
export default {}

I imagine entry could be a mapping of file name patterns to export name patterns instead of an array. So this project structure would yield a Knip config equivalent to:

{
  "entry": {
    "lib/bin": [],
    "lib/exports": ["*"],
    "knip.config.js": ["default"]
  }
}

For backwards compatibility, an array could be equivalent to a mapping where each entry maps to a value of ["*"].

[webpro]

Interesting idea, this would enable some ultimate fine-grained control. Should also work the other way: a config hint if an export name/pattern no longer applies to any actual export.

I like the API is, it's similar to ignoreIssues. Knip usually accepts regexes for such patterns (instead of globs), but also "*" is perhaps intuitive here.

Knip treats the exports of all entries as used.

That's indeed the default behavior. But I should add that there is includeEntryExports (and --include-entry-exports). This is mostly useful in monorepos and to be enabled in only eligible workspaces. Plugins can mark entries for inclusion here using allowIncludeExports when emitting entry points (by default this is disabled because Knip/plugins shouldn't track exports of scripts ("bin") and proprietary exports, such as getStaticProps in Next.js page).

All this to say that the need for what you are proposing here is tried to be kept to a minimum so far. Still a good idea for those that want it.

[remcohaszing]

I think it’s good to keep the API consistent and use regexes for this, not glob patterns. That’s also more flexible.

I think Next.js is a good example where this is useful. They have quite a lot of exports which add have subtle effects. It’s easy to make typos in those exports, which Knip would detect.

[webpro]

The comment in the linked issue makes me wonder a bit if we're on the same page here. To clarify: we're not going to maintain lists of such module exports within Knip, it'd be userland configuration, regardless of the modules being internal or external.

[remcohaszing]

I meant for this to be usable with user configuration, but especially with plugins. So for example in a Next.js project, a file named app/page.tsx with the following content:

export const metadata = {}
export const meatdata = {}

export function Page() {}
export default Page

will have Knip report meatdata and Page. This is really helpful to catch typos where TypeScript can’t help.