Tooling for finding unused files within sites/*-site packages

[bobular]

I was originally trying to find a way to find unused library code (e.g. within packages/libs/*) so we could have a clean-out, but this wasn't quite up to that task.

It will still be useful though. There are a bunch of unused files in packages/sites/*-site that we could probably delete. Not today though.

Anything not bundled by webpack is listed by the new task

yarn workspace @veupathdb/genomics-site bundle:find:unused

For the original task, knip may be what we need.

[bobular]

Generic potential gotchas here (from Claude, not Claude Code)

Beyond the exported packages gotcha you mentioned, here are several important gotchas to consider:

We only publish the *-site packages on npm (pre-mono-repo libs are deprecated on npmjs.com) so I guess we're not using the libs anywhere else.

Additional Gotchas

Dynamic imports and requires - The plugin relies on webpack's static analysis. If your code uses dynamic imports like require(variableName) or import(\./${moduleName}`)`, webpack won't trace those dependencies, and the files will appear unused even though they're actually loaded at runtime.

Server-side code - If you have any Node.js server code, build scripts, or tooling scripts in your repo that aren't processed by webpack, those will be flagged as unused. The plugin only knows about files that webpack touches.

Test files and fixtures - Even if you're excluding *.test.js, you might have test utilities, mocks, fixtures, or other testing infrastructure that aren't imported by your webpack builds but are essential.

Configuration files - Files like .eslintrc.js, babel.config.js, jest.config.js, etc. won't be picked up since they're consumed by other tools, not webpack.

Static assets referenced outside JS/CSS - Images, fonts, or other assets that are referenced directly in HTML templates or accessed via public URLs rather than imported through webpack.

Entry points and HTML templates - Your actual HTML files, webpack config files, and any templates that bootstrap the applications won't be traced.

Documentation and type definitions - README files, TypeScript .d.ts files that are consumed by other packages, JSDoc comments, etc.

CI/CD and deployment scripts - Anything used in your build pipeline that isn't part of the webpack bundle.

Future/staged code - Code behind feature flags that isn't currently imported in any active code path may appear unused.

Your multi-flavor approach is smart, but I'd recommend also maintaining an allowlist of known "legitimately unused" patterns and doing a careful manual review before any bulk deletions!