publint vs arethetypeswrong vs Knip 2026
TL;DR
Run all three if you publish libraries. If you can only add one first, start with publint for exports correctness, then add arethetypeswrong for consumer type safety and Knip for cleanup.
Quick Comparison
| Library | npm package | Weekly downloads | Latest | Best for | Biggest tradeoff |
|---|---|---|---|---|---|
| publint | publint | ~600K/week | 0.3.18 | Catching broken exports, main/module mistakes, and packaging errors right before publishing. | It does not tell you whether your TypeScript types or dependency graph are clean. |
| arethetypeswrong | @arethetypeswrong/cli | ~401K/week | 0.18.2 | Verifying that consumers actually resolve your .d.ts files the way you think they will. | The CLI output can feel unfamiliar if you have not debugged modern TS resolution issues before. |
| Knip | knip | ~6.2M/week | 6.4.1 | Pruning unused files, dependencies, and exports before a release ships avoidable baggage. | You often need configuration for monorepos, generated files, or unusual entrypoints. |
Why this comparison matters in 2026
These tools are often mentioned together, but they are not substitutes. publint checks package metadata shape, arethetypeswrong checks how TypeScript consumers resolve your package, and Knip checks whether your package has dead weight before you publish it.
Shipping packages in 2026 is harder than 'npm publish'. Dual ESM/CJS expectations, TypeScript resolution modes, and strict exports maps create failure modes that do not show up in your local app. That is why package authors increasingly run several narrow quality checks instead of relying on tests alone.
This topic is intentionally adjacent to existing PkgPulse coverage, not a duplicate. PkgPulse already has knip-vs-depcheck coverage. To avoid overlap, this article shifts from dependency cleanup into the pre-publish validation pipeline for package authors.
What actually changes the decision
- publint is about package metadata correctness, not code correctness.
- arethetypeswrong is about consumer experience under different TypeScript and module-resolution modes.
- Knip is about reducing noise and catching unused dependencies, exports, or files before they leak into the release.
publint
Package: publint | Weekly downloads: ~600K | Latest: 0.3.18
publint is the fastest high-leverage check to add when your package ships dual module formats or several subpath exports.
npx publint
# or inside package.json
# "lint:package": "publint"
Best for: Catching broken exports, main/module mistakes, and packaging errors right before publishing. Tradeoff: It does not tell you whether your TypeScript types or dependency graph are clean.
Strengths:
- Excellent for exports-map validation
- Fast and easy to drop into CI
- Purpose-built for packaging mistakes
Watch-outs:
- Narrow scope by design
- Some warnings still require human judgment
arethetypeswrong
Package: @arethetypeswrong/cli | Weekly downloads: ~401K | Latest: 0.18.2
arethetypeswrong is the tool that catches the embarrassing case where your package seems fine locally but breaks TypeScript consumers in the wild.
npx @arethetypeswrong/cli --pack .
Best for: Verifying that consumers actually resolve your .d.ts files the way you think they will.
Tradeoff: The CLI output can feel unfamiliar if you have not debugged modern TS resolution issues before.
Strengths:
- Targets real TypeScript consumption problems
- Great for ESM/CJS packages
- High signal for library authors
Watch-outs:
- Very specific to type-resolution problems
- Requires some module-resolution literacy
Knip
Package: knip | Weekly downloads: ~6.2M | Latest: 6.4.1
Knip belongs in the same release pipeline because dead dependencies and dead files are still package quality issues even though they are a different class of problem.
npx knip
Best for: Pruning unused files, dependencies, and exports before a release ships avoidable baggage. Tradeoff: You often need configuration for monorepos, generated files, or unusual entrypoints.
Strengths:
- Very strong unused-dependency detection
- Catches dead files and exports
- Helps keep published tarballs lean
Watch-outs:
- Can require tuning
- Not a packaging metadata validator
Which one should you choose?
- Choose publint when catching broken exports, main/module mistakes, and packaging errors right before publishing.
- Choose arethetypeswrong when verifying that consumers actually resolve your
.d.tsfiles the way you think they will. - Choose Knip when pruning unused files, dependencies, and exports before a release ships avoidable baggage.
Final recommendation
Run all three if you publish libraries. If you can only add one first, start with publint for exports correctness, then add arethetypeswrong for consumer type safety and Knip for cleanup.
Related reading
tsup vs tsdown vs unbuild 2026 · Publishing an npm Package: Complete Guide 2026