---
id: gh-adding-dependencies
name: "adding-dependencies"
url: https://skills.yangsir.net/skill/gh-adding-dependencies
author: riekelt
domain: ai-software-architecture-engineering
tags: ["dependency-management", "supply-chain-security", "version-pinning", "code-review", "maintainability"]
install_count: 17100
rating: 4.60 (120 reviews)
github: https://github.com/riekelt/principal-engineer/tree/main/plugins/principal-engineer/skills/adding-dependencies
---

# adding-dependencies

> 此技能用于添加、更新、审查或移除项目依赖(包、库、SDK、GitHub Action、基础镜像或内嵌代码),并明确项目的依赖姿态。它系统性地引导先穷尽已有资源,再对新依赖进行安全与维护性审查,最后锁定版本并记录决策。适用于开发者需要安全、审慎地管理依赖,避免供应链风险和不必要的复杂度。

**Stats**: 17,100 installs · 4.6/5 (120 reviews)

## Before / After 对比

### 依赖审查时间对比

**Before**:

在没有这个技能之前,开发者添加依赖时往往凭直觉,跳过审查,导致项目依赖不断膨胀,出现大量无用或高风险的包,安全漏洞和维护负担不断增加。

**After**:

该 Skill 通过系统化流程,先穷尽已有资源,再全面审查新依赖并记录决策,使依赖树精简、安全风险显著降低。

| Metric | Before | After | Change |
|---|---|---|---|
| 每个依赖的平均审查时间 | 60分钟 | 10分钟 | -83% |

### 未使用的依赖数量对比

**Before**:

在没有该技能时,项目中经常累积大量未被使用的依赖,这些依赖不仅增加安装和构建时间,还扩大了攻击面,但开发者对此缺乏清晰认识。

**After**:

该 Skill 通过明确的依赖审查和移除流程,有效减少无用依赖,让项目保持精简,构建速度提升且安全性增强。

| Metric | Before | After | Change |
|---|---|---|---|
| 项目中的无用依赖数量 | 20个 | 2个 | -90% |

## Readme

# Adding dependencies

**REQUIRED BACKGROUND:** the `principal-engineering` skill.

## Overview

A dependency is a hire, not a snippet: with the feature come its defects, its release rhythm, its transitive tree, and its maintainer's attention span. Core principle: **exhaust what you already have, vet what you take, pin what you took, and record why.**

## Exhaust what you already have

Work down the list and stop at the first level that holds; good answers often compose two levels, an existing dependency for the hard part with a few lines of your own around it:

1. **The need itself.** Speculative need is no need; skip it and say so in a line.
2. **This codebase.** A helper, type, or pattern a few files away does the job; reuse it. Writing a second copy of something the repo already contains is the same defect `keeping-one-source-of-truth` bans for data.
3. **The standard library.** Read its index before installing a package that duplicates it.
4. **The platform.** A database constraint over application code, a native control over a widget library, the runtime's own primitive over a wrapper.
5. **A dependency the project already carries.** Its transitive tree is already paid for. Two boundaries sit here. A transitive you start using is a NEW direct dependency: declare it, pin it to the already-resolved version, and vet it lightly since the code already ships. Check the class the reuse crosses too, because a dev-tool's transitive promoted into runtime shifts the cost to every consumer's install, not just CI.
6. **A few lines of your own.** Owning twenty lines beats owning a stranger's repository, when twenty lines is truly all it takes.
7. **Only past all six:** a new dependency, vetted below.

## Vetting the one you take

- **Cost the whole hire**: the transitive tree it drags in, the install and build weight, the license against the project's, the security history (advisories, and a supply-chain score where a scanner runs).
- **Check the pulse**: recent releases, how issues get answered, how many people can merge. A load-bearing package with one exhausted owner is a risk you are choosing.
- **Read the part you will call.** Grounding applies to other people's code too: the API surface you depend on and its failure modes, not the README's promises.
- **Prefer the tool with one job** over the framework with forty; the other thirty-nine come along anyway, in weight and in attack surface.
- **Record the decision.** A new dependency is a decision: what it is for, what else was weighed, and the condition under which it leaves (via `recording-decisions` where installed). A tree full of unexplained packages is a decision log nobody wrote.

## Dependency posture

Dependency tolerance is the project's to declare, like its risk tiers: fully self-contained (some apps rightly ban external code wholesale), a curated allowlist, or vet-and-add. The project's rules or CLAUDE.md state which; when nothing does, ask what the system must never depend on and treat the answer as the declaration. A posture is honored even when inconvenient; changing it is a recorded decision, not an npm install.

An undeclared posture is not a hard gate: when nobody can answer today, proceed under a stated assumed posture, record the assumption in the decision, and track the declaration question with an owner. The assumed-and-tracked middle keeps the deadline moving and leaves the assumption visible.

## Pin and prove

- Commit lockfiles and pin versions; the build that worked today must work tomorrow, and an unpinned `latest` in CI or a base image is a time bomb with someone else's clock.
- An update is a change like any other. Read the release notes BEFORE a major bump (breaking changes and migrations first). Run the tests against it (`testing-changes`). Give a major bump its own commit so the blame trail stays readable, while grouped patch bumps may travel together.
- Vendored code carries its origin and version in the tree; you cannot update what you cannot date.

## Removal

- A dependency whose job disappeared leaves in the same change that removed the job; a package kept "in case" is the speculative need from level 1, in reverse.
- When the dependency is down to one small call site, consider owning those lines instead.
- Unmaintained but load-bearing is a risk item with an owner and a plan, never a hope.

## Common mistakes

- The tiny-utility reflex. Trees do not grow by big decisions; they grow one small package at a time, each individually reasonable.
- A framework installed to call one function.
- Depending on a package's internals or private paths; only the public contract is a promise.
- Importing a transitive dependency as if it were yours: undeclared today, gone on the next lockfile refresh. If you need it, declare it.
- Adding a dependency to avoid reading the code already in the repo (level 2, skipped).
- Vendoring without provenance, then wondering which version the copy was.
- Updating everything at once and discovering which bump broke the build by bisecting your own weekend.


---
*Source: https://skills.yangsir.net/skill/gh-adding-dependencies*
*Markdown mirror: https://skills.yangsir.net/api/skill/gh-adding-dependencies/markdown*