--- og_image: "/images/guides/publint-vs-arethetypeswrong-vs-knip-2026.webp" title: "publint vs arethetypeswrong vs Knip 2026" description: "Compare publint, arethetypeswrong, and Knip for package quality checks in 2026. Exports validation, TS resolution, and dependency cleanup before publish." date: "2026-04-17" tier: 2 authors: ["team"] tags: ["npm", "typescript", "tooling", "package-publishing", "javascript", "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. ```bash 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. ```bash 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. ```bash 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](/guides/publint-vs-arethetypeswrong-vs-pkg-pr-new-package-quality-2026): 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](/guides/knip-vs-depcheck-2026). ## Related reading [tsup vs tsdown vs unbuild 2026](/guides/tsup-vs-tsdown-vs-unbuild-typescript-library-bundling-2026) · [Publishing an npm Package: Complete Guide 2026](/guides/publishing-npm-package-complete-guide-2026)