VisCommandsvis inspect

vis inspect

Dry-run every marshall against a package without installing it.

vis inspect

vis inspect <pkg>[@<spec>] runs the pre-install marshall pipeline against a single package and reports its findings without touching the lockfile or node_modules. Use it to vet a third-party dependency before a vis add, or in code review to surface red flags on a proposed addition.

Usage

vis inspect <package>[@<spec>] [options]

<spec> may be a version (1.2.3), a semver range (^18), or a dist-tag (latest, next). Defaults to latest when omitted.

Quick examples

vis inspect express                       # latest dist-tag
vis inspect lodash@4.17.21                # exact pin
vis inspect react@^18                     # resolve range, inspect best match
vis inspect express --json                # JSON for CI integration
vis inspect express --strict              # exit non-zero on warnings too
vis inspect express --only author,downloads
vis inspect express --only signatures     # signatures are off by default; opt in here

Marshalls

Every marshall is identical to the one run during vis add / vis install / vis update:

MarshallWhat it checks
authorRecent version + new-publisher + dormant-maintainer heuristics from the packument time.
provenanceRegression: prior version had dist.attestations, current version dropped them.
s1ngularityComposite: a version that both changed an install hook AND dropped provenance vs. the prior stable (the Aug 2025 s1ngularity / Nx shape).
newBinThe new version introduces additional bin scripts not present in the immediately prior one.
metadataREADME/license/repository presence, repo URL validity, placeholder README detection.
downloadsMonthly downloads below a configurable warn/error threshold (npm stats API).
expiredDomainsMaintainer email domains whose authoritative NS records return NXDOMAIN/ENOTFOUND.
signaturesECDSA P-256 verification of dist.signatures against /-/npm/v1/keys.
archivedRepoThe package's GitHub repo is archived (no longer maintained) or returns 404.

Options

--json

Emit findings as a JSON document instead of the human-readable table:

vis inspect express --json | jq '.findings[] | select(.severity == "error")'

The schema is:

{
    errors: MarshallFinding[];
    warnings: MarshallFinding[];
    findings: MarshallFinding[];        // errors + warnings, stable order
    summary: { errorCount: number; warningCount: number };
}

--strict

Exit non-zero on any finding — warnings included. Default behavior exits 0 when only warnings fire, mirroring the auto-continue countdown semantics on the install path.

--only <list>

Run only the listed marshalls (comma-separated). Known names: author, provenance, s1ngularity, newBin, metadata, downloads, expiredDomains, signatures, archivedRepo.

vis inspect lodash --only author,signatures

Signatures are opt-in. When --only is omitted, signatures is skipped — matching the pre-install pipeline default in vis add / vis update. npm's signing-key coverage still produces noisy warnings on legitimate packages, so the marshall only runs when you explicitly request it via --only signatures.

Exit codes

CodeMeaning
0No error findings (warnings allowed unless --strict).
1At least one error finding (or any finding with --strict).
2Package not found, or <spec> did not resolve to a published version.

Environment variables

Every MARSHALL_DISABLE_* toggle and MARSHALL_DISABLE_ALL documented in Wrap your package manager applies here as well.

See also

Support

Contribute to our work and keep us going

Community is the heart of open source. The success of our packages wouldn't be possible without the incredible contributions of users, testers, and developers who collaborate with us every day.Want to get involved? Here are some tips on how you can make a meaningful impact on our open source projects.

Ready to help us out?

Be sure to check out the package's contribution guidelines first. They'll walk you through the process on how to properly submit an issue or pull request to our repositories.

Submit a pull request

Found something to improve? Fork the repo, make your changes, and open a PR. We review every contribution and provide feedback to help you get merged.

Good first issues

Simple issues suited for people new to open source development, and often a good place to start working on a package.
View good first issues