publint vs Are The Types Wrong vs pkg.pr.new: Package Quality Checks

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.24`, published 2026-08-19, with 4,458,465 downloads from 2026-07-21 through 2026-08-19.
@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.5`, published 2026-07-09, with 2,319,304 downloads from 2026-07-21 through 2026-08-19.
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.88`, published 2026-08-14, with 665,270 downloads from 2026-07-21 through 2026-08-19.

Package health snapshot

Package-health block

Registry signals checked 2026-08-20

publintVersion 0.3.24, MIT, one listed npm maintainer, and four runtime dependencies.Source: npm registry snapshot.

@arethetypeswrong/cliVersion 0.18.5, MIT, one listed npm maintainer, and seven runtime dependencies.Source: npm registry snapshot.

pkg-pr-newVersion 0.0.88, MIT, two listed npm maintainers, and zero runtime dependencies.Source: npm registry snapshot.

Maintenance velocity and release cadence

The current npm releases are publint 0.3.24 from 2026-08-19, @arethetypeswrong/cli 0.18.5 from 2026-07-09, and pkg-pr-new 0.0.88 from 2026-08-14.

Use release status as a compatibility check, not a ranking. These tools solve different problems, and a higher release count does not make a linter, type analyzer, or preview service a better fit.

Download trend snapshot

Package	Last-month downloads	What the trend can tell you	What it cannot prove
publint	4,458,465	Broad distribution for package-lint workflows.	That every package should use only publint.
@arethetypeswrong/cli	2,319,304	Broad distribution for TypeScript package validation.	That release cadence or issue response is currently high.
pkg-pr-new	665,270	Distribution for preview-package workflows.	That it replaces static checks in CI.

These counts cover 2026-07-21 through 2026-08-19. They measure package distribution, not correctness or security. Pair them with release dates, dependency count, maintainer visibility, 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

The earlier OSV snapshot is not carried forward as a current safety claim. Advisory results apply only to the exact packages, versions, and query time, and they do not inspect transitive provenance, maintainer account controls, release signing, CI hardening, or 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

Run publint in CI before publishing any public package.
Add @arethetypeswrong/cli for TypeScript-first packages where declaration maps, conditional exports, or dual ESM/CJS support matter.
Use pkg-pr-new on pull requests that need installable preview artifacts and reviewer feedback before merge.
Treat a passing preview install as evidence that the artifact can be consumed, not proof that the package metadata or type declarations are correct.
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. npm registry and last-month download data were refreshed on 2026-08-20. The comparison uses signals maintainers can verify: package purpose, current version, publication date, maintainer count, runtime dependency count, and the exact failure mode each tool checks.

Limits: registry data changes and download counts are time-windowed. A current advisory claim requires a fresh, version-specific scan. 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.24, published 2026-08-19, MIT, one listed npm maintainer, and four runtime dependencies.
Are The Types Wrong CLI npm registry metadata: latest 0.18.5, published 2026-07-09, MIT, one listed npm maintainer, and seven runtime dependencies.
pkg.pr.new npm registry metadata: latest 0.0.88, published 2026-08-14, MIT, two listed npm maintainers, and zero runtime dependencies.
publint npm Downloads API point query: 4,458,465 downloads from 2026-07-21 through 2026-08-19.
Are The Types Wrong CLI npm Downloads API point query: 2,319,304 downloads from 2026-07-21 through 2026-08-19.
pkg.pr.new npm Downloads API point query: 665,270 downloads from 2026-07-21 through 2026-08-19.
publint repository: official package-linting scope and packaging checks.
Are The Types Wrong repository: official TypeScript declaration and module-resolution analysis scope.
pkg.pr.new repository: official pull-request preview-package workflow.

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. Teams that need all three checks can lint the package, validate its types, and then install the preview build before merge.