You asked a coding agent to fix a date-formatting bug. The diff includes the fix, a test, and three new lines in package.json, plus a few hundred changed lines in the lockfile. The fix is small, but the dependency change affects every install, every build, and every developer machine that runs your project.

This guide covers what to check when an agent adds, removes, or upgrades a dependency. The examples use npm and pnpm, but the same questions apply to other package managers and their lockfiles.

Start by asking whether a dependency was needed at all

Agents often add a package to solve a problem the standard library or an existing dependency already handles. Before you look at versions or lockfiles, ask:

  • What does the new package do in this change? Find the import and read the code that uses it.
  • Does the project already have something that does the same job?
  • Would a few lines of code be clearer than a new dependency?

A new package is not wrong by default. But each one adds code you did not write, a maintainer you depend on, and more updates to review later. That trade-off deserves a deliberate decision rather than a side effect of a bug fix.

Read the manifest change line by line

For package.json, check each changed line:

  • Which section it is in. A package under dependencies ships with your application. One under devDependencies is used for development and builds. An agent can put a build tool in the wrong section or move a package between sections without saying so.
  • The version range. A range like ^2.1.0 allows newer minor and patch versions, while 2.1.0 pins one version. A change from a pinned version to a range, or to * or latest, changes what future installs can resolve to.
  • Removals. If a package disappeared, search the codebase for imports of it. A removal the agent made while "cleaning up" can break code outside the files it edited.
  • New scripts. A new postinstall, prepare, or preinstall entry in your own package.json runs on install. Read what it does.

Also check whether the package name is exactly what you expect. Names that differ from a well-known package by a character or a scope are worth a second look on the registry before you accept them.

Check that the lockfile matches the manifest

The lockfile records the exact versions that installs will use. When a manifest changes, the lockfile should change with it, and only as much as that manifest change requires.

Things to check:

  • It changed at all. A manifest change without a lockfile change means the agent edited package.json by hand without installing. Your CI may then fail or resolve different versions than you tested. For example, npm ci exits with an error if the lockfile and package.json don't match, and it requires an existing lockfile (npm docs).
  • The size is proportional. Adding one small package should not rewrite most of the lockfile. A large, unexplained lockfile diff can mean the agent deleted and regenerated it, which upgrades many transitive dependencies at once.
  • The package manager is the one your project uses. If your project uses pnpm and a package-lock.json suddenly appears, the agent probably ran the wrong tool. Delete the stray file rather than keeping two lockfiles.

You don't need to read every lockfile line. Look for the new top-level entry, spot-check a few changed transitive versions, and look for unexpected registry URLs.

Know which install scripts can run

Installing a dependency can run code from that dependency. npm runs lifecycle scripts such as preinstall, install, and postinstall as part of npm install (npm scripts). Setting ignore-scripts stops npm from running those scripts automatically.

Current pnpm versions take a different default. Dependency build scripts are blocked unless you approve them in allowBuilds, and with strictDepBuilds enabled (its default) an install fails if a dependency has unreviewed build scripts.

That gives you two things to check in an agent's diff:

  • If the new package, or something it pulls in, has an install script, read what it does before running the install yourself.
  • If the agent changed your package manager's configuration, for example adding a package to allowBuilds, setting dangerouslyAllowAllBuilds, or changing .npmrc, treat that as a security decision that needs its own review.

Separate the dependency change from the feature

If the dependency is justified, it is still easier to review as its own change. A separate commit lets you:

  • revert the dependency without reverting the fix, or the reverse
  • see the lockfile diff next to the manifest change that caused it
  • explain the reason for the package in one commit message

If the dependency is not justified, ask the agent to rewrite the fix without it, or remove it yourself and adjust the code.

Where Diffward fits

Diffward is a VS Code extension for reviewing a local coding agent session. It recognizes common manifests (such as package.json, pyproject.toml, Cargo.toml, and go.mod) and lockfiles (such as package-lock.json, pnpm-lock.yaml, and yarn.lock) by file name and brings them forward as high-risk changes. It also shows files that look unrelated to your request first, so a dependency change during a bug fix is less likely to get buried.

It does not check package reputation, scan for vulnerabilities, or read install scripts for you. You can keep or discard each hunk and undo either decision, but a lockfile is generated output: if you discard the manifest change, rerun the install rather than hand-editing the lockfile to match.

A short checklist

  • Is the new dependency needed for this request, and is there no simpler option?
  • Is it in the right section, with a version range you intended?
  • Did the lockfile change, by a proportional amount, with the right package manager?
  • Does the package or anything it pulls in run install scripts, and did the agent change settings that control them?
  • Should this be its own commit?

Conclusion

Dependency changes are easy to accept because they look small in package.json and too large to read in the lockfile. Reviewing them takes a few specific questions: why this package, what version, what runs on install, and whether the lockfile tells the same story as the manifest. Asking them before you run the install is much cheaper than asking afterwards.