--- og_image: "/images/guides/publint-vs-arethetypeswrong-vs-pkg-pr-new-package-quality-2026.webp" title: "publint vs Are The Types Wrong vs pkg.pr.new: Package Quality Checks" description: "Compare publint, Are The Types Wrong, and pkg.pr.new for package quality: registry health, releases, types, dependencies, downloads, and CI fit." date: "2026-05-04" author: "PkgPulse Team" tags: ['publint', 'arethetypeswrong', 'pkg-pr-new', 'package-quality', 'npm', 'comparison', '2026'] tier: 1 ---

TL;DR verdict

Pick the check that matches the failure mode

publint is the default first CI gate when the risk is a broken npm package: bad exports, missing files, or packaging metadata that fails for real consumers. Are The Types Wrong is the focused TypeScript compatibility gate when declarations and module resolution are the risky part. pkg.pr.new is not a linter replacement; it is the preview-package workflow for installing a pull-request build before merge.

## Quick decision matrix | Check | Use it when | Do not treat it as | Source-backed health signal | | --- | --- | --- | --- | | publint | You need a fast CI check for package exports, files, and publish metadata before release. | A complete TypeScript compatibility or security scanner. | npm latest `0.3.21`, modified 2026-05-13, 3,743,400 last-month downloads from npm registry and downloads snapshots. | | @arethetypeswrong/cli | You need to catch declaration and module-resolution problems before TypeScript consumers do. | A broad package metadata, preview publish, or dependency-health gate. | npm latest `0.18.2`, modified 2025-06-09, 1,704,177 last-month downloads from npm registry and downloads snapshots. | | pkg-pr-new | You need reviewers to install a PR-specific package build without publishing a normal release. | A static quality linter; pair it with publint or Are The Types Wrong in CI. | npm latest `0.0.72`, modified 2026-05-13, 458,902 last-month downloads from npm registry and downloads snapshots. | ## Package health snapshot

Package-health block

Registry and repository signals checked 2026-05-14

publintMIT, one listed npm maintainer, four runtime dependencies, GitHub pushed 2026-05-15, 14 open issues in the API search snapshot.Sources: npm registry and GitHub repository snapshots.
@arethetypeswrong/cliMIT, one listed npm maintainer, seven runtime dependencies, GitHub pushed 2025-06-10, 27 open issues in the API search snapshot.Sources: npm registry and GitHub repository snapshots.
pkg-pr-newMIT, two listed npm maintainers, zero runtime dependencies, GitHub pushed 2026-05-14, 21 open issues in the API search snapshot.Sources: npm registry and GitHub repository snapshots.
## Maintenance velocity and release cadence publint and pkg-pr-new are the fresher release streams in the May 2026 snapshot. publint shipped `0.3.19`, `0.3.20`, and `0.3.21` between 2026-05-05 and 2026-05-13; pkg-pr-new shipped `0.0.70`, `0.0.71`, and `0.0.72` between 2026-05-02 and 2026-05-13. @arethetypeswrong/cli's latest npm release in this snapshot is `0.18.2` from 2025-06-09. That does not make it abandoned, but it does change how much you should rely on npm release recency as a health signal. Use release cadence as a risk input, not a ranking by itself. A stable type-resolution tool may need fewer releases than a preview-publishing service, while a package metadata linter often tracks ecosystem packaging edge cases and benefits from active maintenance. ## Download trend snapshot | Package | Last-month downloads | What the trend can tell you | What it cannot prove | | --- | ---: | --- | --- | | publint | 3,743,400 | Strong automation adoption for package-lint workflows. | That every package should use only publint. | | @arethetypeswrong/cli | 1,704,177 | Significant TypeScript package-validation adoption. | That release cadence or issue response is currently high. | | pkg-pr-new | 458,902 | A meaningful preview-package workflow audience. | That it replaces static checks in CI. | Download counts are directional demand signals from the npm Downloads API, not quality scores. Pair them with release dates, dependency count, maintainer visibility, open issues, and the failure mode you need to prevent. ## Dependency risk The dependency surface is smallest for pkg-pr-new in the registry snapshot: pkg-pr-new has zero runtime dependencies in the npm metadata snapshot. publint lists four runtime dependencies (`package-manager-detector`, `picocolors`, `sade`, and `@publint/pack`), while @arethetypeswrong/cli lists seven (`chalk`, `cli-table3`, `commander`, `marked`, `marked-terminal`, `semver`, and `@arethetypeswrong/core`). A lower dependency count is not automatically safer, but it is easier to audit. If your CI gate runs on every pull request, prefer tools whose runtime dependency tree you can explain during a security review. ## Security notes An OSV query batch run on 2026-05-14 returned no OSV advisory records for the queried package names: `publint`, `@arethetypeswrong/cli`, and `pkg-pr-new`. That result is useful as a current advisory check, but it is not a full supply-chain audit. It does not inspect transitive dependency provenance, maintainer account controls, release signing, CI hardening, or malicious future releases. For a stricter release gate, combine the selected quality check with lockfile review, npm provenance where available, dependency diffing, and a separate vulnerability scanner. ## How to wire the checks 1. Run publint in CI before publishing any public package. 2. Add @arethetypeswrong/cli for TypeScript-first packages where declaration maps, conditional exports, or dual ESM/CJS support matter. 3. Use pkg-pr-new on pull requests that need installable preview artifacts and reviewer feedback before merge. 4. Treat a passing preview install as evidence that the artifact can be consumed, not proof that the package metadata or type declarations are correct. 5. Keep the check output visible in pull requests so maintainers can distinguish packaging errors from type-resolution errors. ## Methodology This guide uses a source-backed packet rather than generic comparison prose. The packet records npm registry metadata, npm last-month download API results, GitHub repository activity snapshots, and an OSV batch advisory query, all accessed on 2026-05-14. The scoring favors current package-health signals that maintainers can verify: latest version, modified date, maintainer count, runtime dependency count, recent repository activity, and advisory-query result. Limits: registry and GitHub API snapshots change, download counts are time-windowed, and OSV results do not cover every supply-chain risk. Treat the recommendation as an automation fit decision, then rerun the checks before standardizing a release policy. ## Source notes - publint npm registry metadata: latest `0.3.21`, modified 2026-05-13, MIT, one listed npm maintainer, four runtime dependencies. - Are The Types Wrong CLI npm registry metadata: latest `0.18.2`, modified 2025-06-09, MIT, one listed npm maintainer, seven runtime dependencies. - pkg.pr.new npm registry metadata: latest `0.0.72`, modified 2026-05-13, zero runtime dependencies, MIT, two listed npm maintainers. - publint npm Downloads API point query: 3,743,400 downloads in the last-month window. - Are The Types Wrong CLI npm Downloads API point query: 1,704,177 downloads in the last-month window. - pkg.pr.new npm Downloads API point query: 458,902 downloads in the last-month window. - publint GitHub repository snapshot: repository pushed 2026-05-15; recent commits included package releases and packaging-rule changes. - Are The Types Wrong GitHub repository snapshot: repository pushed 2025-06-10; recent commits included package versioning and action updates. - pkg.pr.new GitHub repository snapshot: repository pushed 2026-05-14; recent commits included `release: v0.0.72` and CLI fixes. - OSV npm package advisory query: the batch returned no advisory records for the three queried npm package names; this is not a full supply-chain audit. ## Related guides - [20 fastest growing npm packages in 2026](/guides/20-fastest-growing-npm-packages-2026) - [20 npm packages losing downloads fastest in 2026](/guides/20-npm-packages-losing-downloads-fastest-2026) - [50 most underrated npm packages in 2026](/guides/50-most-underrated-npm-packages-2026) ## Bottom line Use publint as the first package-publishing lint gate, add Are The Types Wrong when TypeScript resolution is the expensive failure mode, and use pkg.pr.new when reviewers need installable pull-request artifacts. The strongest workflow is often all three in sequence: lint the package, validate the types, then let reviewers install the preview build before merge.