Added knip

[nico-martin]

At React Norway I listened to a talk by @TkDodo about knip.

With this I added a knip command to npm that checks fo unused dependencies and unused code in Transformers.js. It already found a couple of lines. @xenova, do you think it makes sense to keep it in the project?

Summary

• Add Knip to the monorepo with a workspace-aware configuration for root scripts and packages/transformers.
• Add a dedicated knip CI job in the unit test workflow using Node.js 24.10.0.
• Fix dependency issues surfaced by Knip by declaring direct imports and removing unused Jest environment dependency.
• Resolve unused and duplicate export findings by making internal helpers local, removing dead helpers/constants, and preserving compatibility exports without duplicate aliases.
• Fix a stale JSDoc import path in tokenizer tests.

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[xenova]

Very cool! It definitely caught some old/dead code and other code smells (unused exports, etc.)

I think I need to start using knip for a currently-unreleased library I'm working on 🤫

My one minor gripe with the library is that it introduces quite a few dev dependencies, but since it's quite a well-used library across the ecosystem, I don't see this as a blocker. We also so happen to be removing many other dev dependencies in #1665, so we can consider it a fair swap haha.

PS: Big fan of @TkDodo ❤️ -- would love to see the talk if it's available online?

[xenova]

can you explain the jest-environment-node -> jest/globals package change?

[nico-martin]

This was one of the suggestions from knip since we don't use it.

[nico-martin]

Oh and about the "@jest/globals": knip found that we import @jest/globals in two places in the project but we don't have it in the dependencies. It never caused an issue because I think its still somewhere in the dependency tree, but as I said in the "onnxruntime-common", whenever we import a package directly, we should also have it in our dependencies.

[xenova]

I remember someone mentioned this before, but since onnxruntime-node and onnxruntime-web depend on it, I don't think it's necessary to define here.

but I suppose if there is a mismatch one day between e.g., Tensor from onnxruntime-node and onnxruntime-web, it may cause some issues.

Lmk what you think!

[nico-martin]

I think we should keep this as a direct dependency because @huggingface/transformers imports onnxruntime-common directly. And in my opinion as soon as we have a direct import, we should have it as a direct dependency and not rely on being provided by sub-dependencies.

The version mismatch concern is valid, but declaring it directly makes the resolved version explicit instead of depending on hoisting. If ORT node/web diverge further, we should probably revisit the ORT versions together rather than rely on a transitive copy.

[nico-martin]

@xenova, btw, the talk is online 😊:
https://www.youtube.com/live/Ge0DbLf-2R0?si=omYvDPwNaD9_k5DV&t=10975