中文
devexamples
← Workflows

阅读中文版本

Third-Party Dependency Adoption Workflow

Evaluate a new dependency for maintenance, security, license, and alternatives, approve deliberately, and record the decision before adopting it.

intermediate~90 mindependenciesgovernancesupply-chain

Objective

Adopt a third-party dependency only after reviewing the long-term cost and risks.

Environment

  • Dependency evaluation criteria
  • A decision record location

Steps

1. Evaluate maintenance activity, release cadence,

Evaluate maintenance activity, release cadence, and issue responsiveness.

Expected state: Health is assessed from evidence.

2. Review security posture, known vulnerabilities,

Review security posture, known vulnerabilities, and license.

Expected state: Risk is understood.

3. Consider alternatives including building it yourself

Consider alternatives including building it yourself.

Expected state: The decision is comparative.

4. Record the decision with rationale

Record the decision with rationale and re-review at intervals.

Expected state: The choice is deliberate and revisable.

Decision points

Adopt a small maintained library or build it?

  • Adopt if maintained
  • Always build

Adopt small, healthy libraries; build only the core logic you must own and where the dependency churn is high.

Allow abandoned dependencies?

  • No, unless vendored
  • Yes

Avoid abandoned dependencies unless you vendor and own them, since unpatched risk is on you.

Expected outcome

A deliberate, recorded decision to adopt or reject a dependency after reviewing its health, risk, and alternatives.

Verification

Confirm the decision record lists the criteria, the chosen option, and a review date, and that no critical-license or severe-vulnerability dependency was adopted without justification.

Cleanup

Store the decision record and link it from the dependency entry.

Overview

Adopt a third-party dependency only after reviewing the long-term cost and risks. Confirm the decision record lists the criteria, the chosen option, and a review date, and that no critical-license or severe-vulnerability dependency was adopted without justification.

Steps

  1. Evaluate maintenance activity, release cadence, and issue responsiveness. Expected state: Health is assessed from evidence.
  2. Review security posture, known vulnerabilities, and license. Expected state: Risk is understood.
  3. Consider alternatives including building it yourself. Expected state: The decision is comparative.
  4. Record the decision with rationale and re-review at intervals. Expected state: The choice is deliberate and revisable.
npm view some-lib version time.modified maintainers
# assess activity, then record the adoption decision

Verification

  • A deliberate, recorded decision to adopt or reject a dependency after reviewing its health, risk, and alternatives.

Decision points

  • Adopt a small maintained library or build it? Options: Adopt if maintained; Always build. Recommended: Adopt small, healthy libraries; build only the core logic you must own and where the dependency churn is high.
  • Allow abandoned dependencies? Options: No, unless vendored; Yes. Recommended: Avoid abandoned dependencies unless you vendor and own them, since unpatched risk is on you.