← package.json Exports Drift Check
Different scope and a different moment: publint is a broad packaging linter that audits a package you already have installed, packed, or published, against a wide set of publish-readiness rules. This tool does one narrow thing, from two pasted text blocks alone: name every literal exports target that doesn't exist — no install, no publish, no network call.
publint is a free, open-source linter, published as
both a website and a npx publint CLI. Its own
documentation describes checking a package against a broad set of
publish-readiness problems: issues with the exports,
main, module, and types fields
among them, alongside CJS/ESM resolution mismatches, deprecated
fields, and other packaging mistakes that only surface for a consumer
after install. The website version points at a package already
published to npm (by name and version) or an uploaded tarball; the
CLI runs against a local package directory. Today's exact rule list
and any change to it are publint's own to state, not repeated here
since this session cannot verify them live against publint's own
site.
This tool does none of what publint's broader rule set does. It has
no install step, reads no node_modules, and never talks
to the npm registry. It takes exactly two things you paste — a
package.json and a listing of the files you actually
publish — and flattens every subpath, every nested condition
(import/require/types/...),
and every fallback array in the exports map, then
reports each literal target that is missing from that listing. A
wildcard target or a bare-specifier re-export is reported as
not checked, never as passing or failing. Because it
needs nothing installed or published, it works on a
package.json you are still editing, against a
hypothetical file listing of what a build would produce
— a question publint's own workflow, built around an
already-existing package, is not shaped to answer.
| Question | Where to answer it |
|---|---|
| I want the broad, well-established publish-readiness audit — CJS/ESM resolution, deprecated fields, and more — against a package that's already installed, packed, or on the registry. | publint — that is the audit it is built for. |
| I want to know right now, for free, exactly which exports targets are missing, from a package.json I'm still editing and a file listing I haven't built yet. | This tool — paste both, get the list, nothing installed. |
| I want a website that checks a package already published to npm by name and version. | publint — this tool reads only what you paste, never the registry. |
I want a zero-dependency CI gate that runs after my build step and before npm publish, reading only local files with no network call. | Either works locally; this tool's CLI (cli.mjs) needs no install of its own. |
| I want CJS/ESM resolution and other packaging checks beyond whether an exports target file exists. | publint — this tool checks existence only, nothing about resolution or module format. |
| I want the exports map flattened and diffed against a file listing that isn't real yet — planning a refactor, say — with no package to point a tool at. | This tool — that's the one job it does, and it needs nothing to exist on disk. |
A maintainer can reasonably use both: publint as the broad, periodic
publish-readiness audit against a real package, and this tool as a
fast, any-time sanity check on the exports map itself — useful
even before a build has produced anything to point a broader linter
at. This page does not evaluate publint's accuracy or coverage and
makes no claim about it either way — it only describes
publint's documented product shape and states what this tool does
differently. A clean result from either one is not a guarantee your
package will install or import cleanly; verify with
npm publish --dry-run and a real install.
This tool needs no account, no install, and no network call: it is a static page that runs entirely in your browser, or a zero-dependency Node CLI that reads only local files.
publint's own documentation describes it as a broad packaging linter: it audits a package.json against a wide range of publish-readiness problems — among them, issues with the exports, main, module, and types fields — as one part of a much larger rule set covering CJS/ESM resolution, deprecated fields, and other packaging mistakes. It normally runs against a package you point it at: a name and version already published to npm (via its website), an uploaded tarball, or a local package directory (via its own CLI). This tool does one thing only, from two pasted text blocks with nothing installed or published: flatten every subpath, condition, and fallback array in the exports map and name each literal target that is missing from a file listing you provide.
They overlap on one question and differ on scope and when you can run them. publint is the broader publish-readiness linter — reach for it to catch the wider set of packaging mistakes it documents, against a package that already exists on disk or on the registry. This tool answers one narrower question, before that: given a package.json you are still editing and a hypothetical or planned file listing, which exports targets would be missing right now? That makes it usable earlier — before a build has run, before anything is packed or published — and it needs nothing installed and no network call either way. A maintainer can reasonably use both: this tool as an any-time sanity check on the exports map itself, publint as the broader pre-publish audit.
No. This page is not affiliated with, endorsed by, or sponsored by publint or its author. publint is named here only to describe what this tool is and is not, based on publint's own publicly documented product.