dependencies

Governs dependency version upgrades using exact pins, pnpm overrides, and release-age waiting periods.

1|Updated Jan 14, 2024
One-click install
npx skills add https://github.com/Eyhenij/rt-tools --skill dependencies-eyhenij
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dependencies
Source: https://github.com/Eyhenij/rt-tools/tree/main/.claude/skills/dependencies
Command: npx skills add https://github.com/Eyhenij/rt-tools --skill dependencies-eyhenij

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Upgrading dependencies in a pnpm monorepo breaks builds silently: version ranges install different trees over time, fresh releases get withdrawn, formatter updates reformat unrelated files, and styling packages break visuals without any test catching it. This rule defines how to declare, pin, and upgrade dependencies so the lockfile, peer ranges, and CI stay consistent. ## Core Features & Use Cases - Exact version pinning: All dependencies in package.json use exact numbers with no ^ or ~ ranges, keeping the installed tree reproducible. - Centralized overrides management: Foreign transitive dependency substitutions live in pnpm-workspace.yaml overrides, split into vulnerability floors and parent>child ceilings, revisited at every update. - Release-age gating: Fresh versions wait out a minimumReleaseAge period; urgent ones are listed explicitly in minimumReleaseAgeExclude. - Use Case: When raising TypeScript or Playwright in the monorepo, follow the flowchart to derive the upper bound from peer ranges, hold the snapshot runner's Jest/Playwright ceilings, and rerun visual tests after browser or faker bumps. ## Quick Start Load the dependencies rule before editing package.json, pnpm-lock.yaml, or pnpm-workspace.yaml, then follow its upgrade flowchart to pick the version bound and run the full check suite.

Frequently Asked Questions about dependencies

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I upgrade dependencies in a pnpm monorepo safely?

Write the new version as an exact number in package.json, derive the upper bound from dependent peer ranges rather than the latest registry version, rebuild pnpm-lock.yaml in the same commit, and run the full check suite including visual tests for layout-affecting packages.

Why pin exact dependency versions instead of semver ranges?

Exact pins guarantee the same installed tree today and a week later, and reverting an edit actually restores the prior state. A range like ^0.2.0 can declare a version the lockfile never installed, leaving the build broken while the manifest looks correct.

What is minimumReleaseAge in pnpm and when should I exclude a package?

minimumReleaseAge makes freshly published versions wait before installation, protecting against releases their authors later withdraw. A package needed urgently before the term expires is written out by exact number in minimumReleaseAgeExclude with the reason named.

How do pnpm overrides handle vulnerable transitive dependencies?

Overrides in pnpm-workspace.yaml collect substitutions in one list: bare package names act as floors against build-graph vulnerabilities, while parent>child keys scope ceilings to specific consumers. The list is revisited at every update so stale substitutions do not silently roll dependencies back.

Why do visual tests fail after a Playwright or faker upgrade?

A newer Playwright ships a newer Chromium that renders native controls like scrollbars a pixel differently, and a newer faker generates different seeded text. Both divergences are bound by pinned versions and ceilings, not by application defects.

Should styling-related packages be upgraded together with other dependencies?

No. A package carrying styling is raised in its own task and branch because visual breakage passes linters, builds, and unit tests undetected. Isolating the upgrade lets the breakage be reverted alone without a separate investigation.