Reject a new dependency when it adds an ongoing obligation without a demonstrated need. A working demonstration shows that one implementation can produce an output. The review must also establish why the project should take responsibility for another package, its updates, its compatibility constraints, and its place in the application.
Begin with the behavior the patch needs. Then compare the proposed package with what the project already has and what the runtime provides. A useful review decision connects the requirement, alternatives, costs, and evidence rather than treating every new package as either harmless or forbidden.
State the smallest real requirement
Consider an illustrative patch that changes the display format of an invoice due date. The application already uses a date-formatting library elsewhere, but the patch adds a second runtime library for the new label.
Clarify the date contract before comparing implementations. Is the input a calendar date or an instant? Which locale determines the display? Should a timezone conversion occur? What should happen for missing or invalid input? Preserve the existing behavior unless a deliberate change has been agreed.
A screenshot of one ordinary date cannot settle those questions. It also cannot demonstrate that the additional package is necessary.
Inspect the existing capability first
Read the dependency manifest and locate relevant imports. Check which version is actually installed and how nearby code handles the same kind of date. An existing helper may encode locale or timezone decisions that a new call bypasses.
Compare the required output using the existing library, the proposed library, and an applicable platform API. Use the same representative inputs and execution context. Similar-looking format strings do not establish equivalent semantics across different implementations.
If the installed library satisfies the contract, request a revision that uses it. State the condition precisely: the objection is a duplicate runtime dependency for a job the project can already perform. If the author identifies a missing capability, review that evidence before deciding.
Require a concrete reason for the addition
A dependency rationale should name the capability that is missing and explain why the alternatives are insufficient. “Easier to use” needs detail: which behavior becomes clearer, which failure modes are handled, and what complexity would otherwise remain in application code?
A package can be the safer choice when the requirement is substantial and implementing it locally would create difficult maintenance or correctness work. That still requires an assessment of the particular package and version.
Keep the comparison bounded. A small label change does not justify replacing the application's date conventions across unrelated modules. A larger migration can be proposed separately with its own compatibility plan and owner.
Inspect the resolved dependency change
Review the lockfile alongside the manifest. Identify the resolved version, additional transitive packages, and unrelated version movements. Determine whether each change follows from the addition or belongs in a separate patch.
Read the relevant changelog when an existing package version changes. Check for altered defaults, removed APIs, runtime requirements, and migration work that affect this application. A small manifest diff can conceal a larger resolved dependency change.
Confirm whether the package belongs in the runtime or development dependency set. Its placement should reflect where it is actually needed and how the project's build and deployment process handles dependencies.
Evaluate the ongoing obligations
Review maintenance activity, release history, issue handling, compatibility documentation, license requirements, and security posture for the proposed version. State what was checked and when; these facts can change.
One maintainer or an old release is a review signal, not a complete verdict. A stable package may need few releases, while frequent releases may bring substantial upgrade work. Connect the observation to the project's reliance on the package and its ability to maintain or replace it.
Check the project's process for license and security review. Installation behavior, new runtime access, and processing untrusted input can change which reviewers are needed. Resolve those requirements before accepting the dependency.
Measure impact at the relevant boundary
For a browser-delivered feature, compare the applicable build artifacts before and after the change. Identify the affected entry point or chunk and the measurement used. A package's published size alone does not establish what this application will deliver to users.
For a server-side dependency, inspect the deployment and runtime consequences that matter to the service. Additional installation steps, platform-specific components, or new configuration may deserve attention even when browser bundle size is irrelevant.
Keep estimates and observations separate. Record the revision, build configuration, and observed difference when measurement is available. If the environment is unavailable, request the check and name its owner instead of claiming negligible impact.
Ask for evidence that can change the decision
A compact review record helps expose an unsupported addition:
| Question | Evidence to request |
|---|---|
| What capability is missing? | Required behavior and a concrete failing or unsupported case. |
| Can the project already do it? | Comparison with the installed library or applicable platform API. |
| What enters the dependency graph? | Manifest and lockfile review, with relevant changelog findings. |
| What operational cost changes? | Relevant build, deployment, or runtime comparison. |
| Who maintains the decision? | Upgrade responsibility and a documented reason for acceptance. |
For the date label, propose checks for the agreed input types, timezone and locale behavior, and missing or invalid values. The chosen implementation should satisfy that contract without unrelated changes.
Give a specific verdict and next action
When rejecting the duplicate library, identify the existing capability and request the equivalent call using it. Ask for removal of the new dependency and review the resulting lockfile changes. Do not prescribe an unverified API signature merely to make the comment sound complete.
When accepting an addition, record the capability gap, alternatives considered, relevant costs, and remaining limits. Name who owns any required security, licensing, or deployment confirmation. Keep approval conditional on outstanding material checks rather than treating a rationale as proof that those checks passed.
The final review should leave the author with a concrete revision or an evidenced reason to retain the package. A successful demo belongs in that evidence, alongside the contract and maintenance decision.
The Agentic Developer Interview includes the Dependency Risk Review card covering existing-library and platform-API comparisons, maintenance, bundle size, licensing, security posture, and lockfile and changelog review.