How to Review an AI-Suggested npm Package Before Installing It

Short answer

Never install a package merely because an AI assistant suggested it. First confirm the exact name and version, repository, maintainer, release history, lifecycle scripts, alternatives, and transitive impact; then install an approved exact version, review the lockfile, run audit and tests, and record why the dependency was needed.

The five-minute package review

Before accepting an AI-generated install command, answer these questions:

1. Can a built-in API or an existing dependency solve the problem?
2. Is the package name exact, and does the registry page point to the expected source repository?
3. Who publishes and maintains it, and is there a credible release history?
4. Does it run preinstall, install, postinstall, or prepare scripts?
5. Which direct and transitive packages will the change introduce?

The goal is not to reject open source. It is to turn “plausible package name” into an accountable engineering decision before code executes on a developer laptop or CI runner.

Inspect metadata before adding anything

# npm
npm view <package-name> repository maintainers version

# Bun
bun pm view <package-name> repository maintainers version

# pnpm
pnpm view <package-name> repository maintainers version

Review the linked repository directly. Look for a clear purpose, active maintenance, release notes, security policy where appropriate, and a package name that matches the project. A package with a familiar-looking name is not evidence that it is the intended one.

Install only an approved version

# npm
npm install <package-name>@<approved-version> --save-exact

# Bun
bun add <package-name>@<approved-version> --exact

# pnpm
pnpm add <package-name>@<approved-version> --save-exact

Afterward, review the package.json and lockfile diff. Then run the audit, tests, type check, and production build used by that repository. If the assistant cannot provide enough information to complete the review, it should propose options and wait for human approval instead of installing a package.

Record the decision in the pull request

Add a short dependency note to the pull request: the problem solved, exact package and version, alternative considered, owner, and verification results. This prevents a later maintainer from treating the package as accidental or upgrading it blindly. For higher-risk packages, link the registry and repository review and note any lifecycle-script decision. The goal is an auditable reason for every new executable dependency.

A directive worth adding to project instructions

Do not add, upgrade, remove, or replace packages without explicit approval.
Prefer platform APIs and existing dependencies. For every proposed package, report
the exact version, publisher, source repository, lifecycle scripts, alternatives,
and expected dependency impact. After approval, pin the version, review the
lockfile, run audit and verification, and report the result.

For the broader AI supply-chain threat model, read Supply-Chain Security in the AI Coding Era. For commands and CI controls across package managers, read JavaScript Dependency Security.