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

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.ts files 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.

Decision Checklist

Run publint before every package publish because it catches broken exports and package metadata problems that consumers feel immediately. Add Are The Types Wrong when TypeScript consumers are the core audience and you need confidence across NodeNext, bundlers, and declaration resolution. Use Knip as a repository hygiene tool, not a package-publish gate, because unused files and dependencies are broader maintenance signals.

A good release pipeline uses all three at different moments: Knip during cleanup, publint in CI before publishing, and Are The Types Wrong when changing exports, types, or build output. That separation keeps the checks actionable instead of turning one command into noisy release theatre.

Where each check belongs in CI

Treat Knip as the early cleanup pass, not the final gate. Run it on pull requests that remove entrypoints, rewrite examples, or bump build tooling so unused dependencies and forgotten files are cleaned up before reviewers inspect the release diff. Then run your normal test suite and build.

publint should sit much closer to publish time because it checks the package artifact and metadata shape. In a release workflow, run it after the package is built and before the registry publish step. Are The Types Wrong belongs next to publint whenever the release touches exports, types, declaration generation, or ESM/CJS compatibility, because those are the changes most likely to break consumers even when internal tests pass.

That is also why this guide differs from the pkg.pr.new package-quality comparison: pkg.pr.new is useful for evaluating a package before adding it, while this pipeline is for authors validating their own package before publishing. For dependency cleanup outside a publish flow, use the Knip vs depcheck guide.

Related reading

tsup vs tsdown vs unbuild 2026 · Publishing an npm Package: Complete Guide 2026