dependencies
GitHub规范 Docusaurus monorepo 中 npm 依赖的管理流程,包括使用 pnpm catalogs、执行 dedupe 及 lint 检查。涵盖依赖的添加移除、版本分组策略(如 Babel 包)及 catalog 与显式版本的例外处理规则。
Trigger Scenarios
Install
npx skills add meta/docusaurus --skill dependencies -g -y
SKILL.md
Frontmatter
{
"name": "dependencies",
"description": "Add, remove or upgrade npm dependencies in the Docusaurus monorepo. Use before editing any `package.json` dependency field, running `pnpm add`\/`pnpm remove`\/`pnpm update`, or changing `pnpm-lock.yaml`."
}
Dependencies
Lockfile
- Run
pnpm dedupeafter any lockfile change. CI fails ifpnpm-lock.yamlis not deduplicated (pnpm lint:deps). - Site template dependencies live in
packages/create-docusaurus/templates/. Never editexamples/, it is CLI-generated.
Catalogs
All the monorepo dependencies are declared in the pnpm catalogs of pnpm-workspace.yaml. Packages reference them with the catalog protocol instead of a version range:
"catalog:": the default catalog, for dependencies used at runtime by at least one package (dependencies,optionalDependenciesorpeerDependencies)."catalog:dev": the dev catalog, for dependencies only used asdevDependencies.
Use pnpm commands to add and remove dependencies:
pnpm addonly accepts catalog versions (catalogMode: strict), and adds new dependencies to the default catalog. Move dev-only dependencies to the dev catalog.pnpm removeremoves the catalog entries that are no longer used (catalogPrune: true). Manualpackage.jsonedits don't.
Move a dev catalog entry to the default catalog as soon as a package uses it at runtime.
Exceptions, keeping explicit versions:
- The site templates, copied to user sites. Their versions must match the catalogs.
- pnpm
overrides. Their versions must match the catalogs. - Peer dependencies whose range intentionally differs from the catalog (see the ignored version groups of
.syncpackrc.ts).
Two checks enforce it:
pnpm lint:syncpack: dependencies must use a catalog.pnpm lint:catalogs(admin/scripts/lintCatalogs.js): catalog entries are used and in the right catalog, templates and overrides match the catalogs, and dependency group members use matching versions.
Dependency groups
Some packages must always be upgraded together. They are declared as groups in .github/dependabot.yml:
- Dependabot upgrades them atomically in a single PR, instead of opening broken intermediate PRs.
pnpm lint:catalogsfails if their catalog versions differ (only their major versions for thebabelgroup, seeadmin/scripts/lintCatalogs.js).
Packages belong to a group when, for example:
- One package pins an exact version of the other (
@svgr/webpackpins@svgr/coreand@svgr/plugin-*). - One package has a peer dependency on the exact same version of the other (
@types/react-domand@types/react). - The packages check at runtime that their versions match (
reactandreact-dom). - Mixing versions duplicates a singleton package (
react-routerandreact-router-dom). - The packages are released in lockstep and mixing versions breaks typechecking (
typescript-eslint).
When you add a dependency, check whether it belongs to a group:
- If an existing group already matches it (
@svgr/*matches@svgr/plugin-jsx), there is nothing to do. - Otherwise, add it to the matching group, or create a new group. Follow the existing groups: one group per package family, with a comment explaining why the packages must stay in sync.
Do the same when a Dependabot PR can't pass CI on its own because a related package wasn't upgraded with it.
Version History
-
2a89055
Current 2026-11-02 21:14
新增依赖分组管理说明,解释为何需将特定包(如 Babel)归组以原子升级,并修正关于分组内版本一致性的描述。
- 7b6826b 2026-10-19 04:29


