Abhaengigkeiten sicher verwalten mit Claude Code, npm, pnpm und Yarn

Abhaengigkeitsverwaltung ist kein blindes Update

In JavaScript- und TypeScript-Projekten aendern sich Abhaengigkeiten oft schneller als der eigene Anwendungscode. React, Vite, TypeScript, ESLint, Testwerkzeuge, UI-Bibliotheken, Payment-SDKs und Build-Plugins bilden schnell einen Baum aus hunderten direkten und transitiven Paketen.

Claude Code ist dafuer hilfreich, aber nicht als Knopf fuer npm install paket@latest. Der bessere Einsatz ist: Repository inspizieren, Paketmanager und Lockfile erkennen, Updates nach patch/minor/major trennen, Security-Audits einordnen, Renovate- oder Dependabot-PRs pruefen und am Ende klare CI-Belege liefern.

Ein Lockfile haelt exakt fest, welche Paketversionen und Integritaetswerte installiert wurden. npm nutzt package-lock.json, pnpm nutzt pnpm-lock.yaml, Yarn nutzt yarn.lock. package.json beschreibt erlaubte Bereiche; das Lockfile beschreibt das tatsaechliche Ergebnis. CI soll dieses Ergebnis reproduzieren, nicht heimlich neu schreiben.

Zum groesseren CI-Kontext passt Claude Code CI/CD Setup. Fuer Workspaces lies auch pnpm workspace mit Claude Code.

---

Empfohlener Ablauf

Teile die Arbeit in Inventur, Plan, Update-PR, CI und menschliche Entscheidung.

flowchart LR
  scan["Inventur\noutdated / audit"] --> plan["Plan\npatch / minor / major"]
  plan --> pr["Update PR\nRenovate / Dependabot"]
  pr --> ci["CI\ninstall / test / build"]
  ci --> review["Claude Code Review\nRisiken und Belege"]
  review --> merge["Menschliche Entscheidung\nmerge oder ablehnen"]

Die erste Aufgabe fuer Claude Code sollte keine Aenderung sein.

claude -p "
Inspect dependency management in this repository. Do not edit files yet.
Report package manager, lockfile, outdated direct dependencies,
security audit command, scripts that must pass, and risky major updates.
Return file paths and exact commands.
"

Das verhindert grosse Aenderungen ohne Kontext. Zuerst Inventur, dann Update.

---

npm, pnpm und Yarn im Vergleich

Vermische Paketmanager nicht in einem Repository. Jeder hat sein Lockfile und seinen passenden CI-Befehl.

Werkzeug	Lockfile	CI Installation	Veraltete Pakete	Security Audit
npm	package-lock.json	npm ci	npm outdated	npm audit --audit-level=high
pnpm	pnpm-lock.yaml	pnpm install --frozen-lockfile	pnpm outdated --format table	pnpm audit --audit-level high
Yarn modern	yarn.lock	yarn install --immutable	yarn up -i oder yarn up <pattern>	yarn npm audit --recursive --severity high

Die npm-Dokumentation beschreibt npm ci als Befehl fuer automatisierte Umgebungen und erklaert, dass er fehlschlaegt, wenn package.json und Lockfile nicht zusammenpassen. pnpm nutzt dafuer --frozen-lockfile, Yarn --immutable. Das Lockfile wird im PR geaendert, CI prueft die Reproduzierbarkeit.

---

Kopierbares Pruefscript

Speichere die Datei als scripts/verify-deps.mjs. Sie erkennt npm, pnpm oder Yarn, fuehrt eine eingefrorene Installation aus, prueft Security-Audits ab high und startet typecheck, test und build, wenn diese Scripts existieren.

#!/usr/bin/env node
import { existsSync, readFileSync } from "node:fs";
import { spawnSync } from "node:child_process";

function readPackageJson() {
  return JSON.parse(readFileSync("package.json", "utf8"));
}

function detectPackageManager(pkg) {
  const declared = pkg.packageManager || "";
  if (declared.startsWith("pnpm@")) return "pnpm";
  if (declared.startsWith("yarn@")) return "yarn";
  if (declared.startsWith("npm@")) return "npm";
  if (existsSync("pnpm-lock.yaml")) return "pnpm";
  if (existsSync("yarn.lock")) return "yarn";
  if (existsSync("package-lock.json")) return "npm";
  throw new Error("No package manager or lockfile detected.");
}

function run(command, args) {
  const label = [command, ...args].join(" ");
  console.log(`\n$ ${label}`);
  const result = spawnSync(command, args, {
    stdio: "inherit",
    shell: process.platform === "win32",
  });
  if (result.status !== 0) throw new Error(`Command failed: ${label}`);
}

const pkg = readPackageJson();
const manager = detectPackageManager(pkg);

const installCommands = {
  npm: ["npm", ["ci"]],
  pnpm: ["pnpm", ["install", "--frozen-lockfile"]],
  yarn: ["yarn", ["install", "--immutable"]],
};

const auditCommands = {
  npm: ["npm", ["audit", "--audit-level=high"]],
  pnpm: ["pnpm", ["audit", "--audit-level", "high"]],
  yarn: ["yarn", ["npm", "audit", "--recursive", "--severity", "high"]],
};

const scriptCommands = {
  npm: (name) => ["npm", ["run", name]],
  pnpm: (name) => ["pnpm", ["run", name]],
  yarn: (name) => ["yarn", ["run", name]],
};

run(...installCommands[manager]);
run(...auditCommands[manager]);

for (const name of ["typecheck", "test", "build"]) {
  if (pkg.scripts?.[name]) run(...scriptCommands[manager](name));
  else console.log(`\n- skip ${name}: script not found`);
}

console.log(`\nDependency verification passed with ${manager}.`);

In package.json:

{
  "scripts": {
    "deps:verify": "node scripts/verify-deps.mjs"
  }
}

Das Script aktualisiert nichts. Es ist die gemeinsame Pruefstelle fuer Claude Code, Renovate, Dependabot und manuelle Aenderungen.

---

Drei typische Anwendungsfaelle

Erstens: Patch- und Minor-Updates fuer Entwicklungswerkzeuge in einer kleinen App. ESLint, Prettier, Vite-Plugins, Vitest oder TypeScript-Patches koennen gebuendelt werden. Major-Versionen bleiben getrennt.

claude -p "
Prepare a dependency update plan for devDependencies only.
Group patch and minor updates for lint/test/build tools.
Do not update major versions.
Run the dependency verification script after changes.
"

Zweitens: Security-Audits. Starte nicht mit audit fix --force. Lass Claude Code zuerst den JSON-Bericht einordnen: direkte oder transitive Abhaengigkeit, installierte Version, gefixte Version, Lockfile-only moeglich, Major noetig.

npm audit --json
pnpm audit --json
yarn npm audit --recursive --json

Drittens: Workspaces und Monorepos. Abhaengigkeitsverwaltung bedeutet auch interne Grenzen. packages/ui sollte nicht aus apps/web importieren, und interne Pakete sollten workspace:* verwenden.

claude -p "
Inspect this workspace before dependency updates.
Find packages/* importing from apps/*, internal dependencies not using workspace:*,
duplicated versions of react/typescript/eslint, and scripts that should use filters.
Do not edit files.
"

---

Renovate und Dependabot

Renovate passt, wenn du feine Regeln brauchst. Diese Konfiguration erlaubt Automerge fuer risikoarme Dev-Tool-Updates und laesst Major-Updates bei Menschen.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "dependencyDashboard": true,
  "lockFileMaintenance": {
    "enabled": true,
    "schedule": ["before 5am on monday"],
    "automerge": true
  },
  "packageRules": [
    {
      "matchManagers": ["npm"],
      "matchDepTypes": ["devDependencies"],
      "matchUpdateTypes": ["patch", "minor"],
      "automerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "labels": ["dependency", "major-update"],
      "automerge": false
    }
  ]
}

Dependabot ist fuer GitHub-Repositories der einfache Start.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
    groups:
      dev-tooling:
        dependency-type: "development"
        update-types:
          - "minor"
          - "patch"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"

GitHub Actions selbst sollten ebenfalls aktuell bleiben. Alte Actions koennen Dependency-PRs unnoetig schwer debuggen lassen.

---

CI Gate

name: dependency-check

on:
  pull_request:
  push:
    branches: [main]

jobs:
  verify-dependencies:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: corepack enable
      - run: node scripts/verify-deps.mjs

Cache kannst du spaeter ergaenzen. Zuerst sollte der Ablauf ohne versteckten Zustand reproduzierbar sein.

---

Konkrete Fehler

Fehler eins: npm install in CI statt npm ci. Fehler zwei: audit fix --force ohne Analyse. Fehler drei: mehrere Major-Updates in einem PR. Fehler vier: nur package.json pruefen und das Lockfile ignorieren. Fehler fuenf: Dev-Dependencies und Production-Dependencies gleich behandeln. Ein ESLint-Patch ist nicht dasselbe Risiko wie ein Auth-SDK-Update. Fehler sechs betrifft Content-Seiten: MDX-, CSS- oder Build-Updates koennen Codebloecke, Anzeigen oder CTAs veraendern. Dafuer hilft der Verification Receipt Workflow.

---

PR-Review-Prompt

claude -p "
Review this dependency update PR.
Focus on package.json, lockfile, CI config, and test output.
Report updated packages, direct vs transitive changes, major updates,
peer dependency changes, commands that passed or failed, and manual checks.
Do not change files unless there is a blocking issue.
"

Eine gute Review nennt Belege: was sich geaendert hat, was gelaufen ist, was fehlgeschlagen ist und was ein Mensch noch pruefen muss.

---

Referenzen und naechste Schritte

Siehe npm ci, npm audit, pnpm install, pnpm audit, yarn install, yarn npm audit, Claude Code CLI, Dependabot options und Renovate automerge.

Fuer den naechsten Schritt lies Claude Code Security Audit und CLAUDE.md Best Practices. Wenn dein Team Regeln fuer ein echtes Repository braucht, ist Training und Beratung der passende Einstieg.

Ergebnis aus der Praxis

Der groesste Gewinn entstand durch die Trennung von Update-Erzeugung und Verifikation. Claude Code kann planen und reviewen, aber deps:verify und der Lockfile-Diff entscheiden, ob der PR bereit ist. Major-Updates aus dem Automerge herauszunehmen macht Fehlerursachen deutlich leichter nachvollziehbar.