Die wichtigsten Dependency-Typen in der package.json

In jeder Node.js- oder JavaScript-Anwendung ist die package.json das Herzstück. Doch nicht alle Abhängigkeiten sind gleich – mit den richtigen Dependency-Typen steigerst du nicht nur die Performance deiner App, sondern vermeidest auch unnötige Fehler und Sicherheitslücken. In diesem Artikel klären wir alle Typen auf, wann du sie verwendest und warum du sie nicht verwechseln solltest.

🧩 1. dependencies – Die Grundlage für deine Produktion

Wann? Wenn das Paket während der Laufzeit benötigt wird.
Beispiel: Frameworks wie express oder UI-Bibliotheken wie vue.

"dependencies": {
  "vue": "^3.5.0",
  "axios": "^1.6.0"
}

📦 Installiert bei: npm install
⚙️ Wichtig: Diese Pakete werden immer im Produktions-Deployment mitgeliefert.

💡 Fehlerquelle: Wenn du eslint hier einträgst, wird es im Produktionsbuild mitgeliefert – und das ist nicht gewollt!

🧪 2. devDependencies – Die Entwicklungshilfen

Wann? Für Tools, die nur zur Entwicklung benötigt werden.
Beispiel: vite, eslint, typescript, jest.

"devDependencies": {
  "vite": "^5.0.0",
  "eslint": "^9.0.0",
  "typescript": "^5.0.0"
}

📦 Installiert bei: npm install
🚫 Nicht installiert bei: npm install --production
⚙️ Wichtig: Diese Abhängigkeiten vergrößern nicht dein Produktionsbundle.

💡 Best Practice: Nutze --production bei Deployments, um devDependencies auszuschließen.

🧱 3. peerDependencies – Für Plugins und Bibliotheken

Wann? Wenn dein Paket mit einem anderen Paket zusammenarbeitet, aber die Version nicht selbst steuerst.
Beispiel: Ein Vue-Plugin, das vue als peerDependency erwartet.

"peerDependencies": {
  "vue": "^3.5.0"
}

📦 Installiert von: Dem Nutzer deines Pakets (z. B. beim npm install deiner App)
⚙️ Wichtig: Ohne diese Abhängigkeit bricht die Installation deines Plugins beim Nutzer fehl.

💡 Fehlerquelle: Falsch: dependencies: { "vue": "^3.5.0" } → Doppelt installiert!
Richtig: peerDependencies: { "vue": "^3.5.0" } → Nutzer muss Vue selbst installieren.

🧭 4. optionalDependencies – Für „könnte man auch weglassen“

Wann? Für Abhängigkeiten, die nicht kritisch sind (z. B. Plattform-spezifische Module).
Beispiel: fsevents für macOS (kann auf Linux/Windows weggelassen werden).

"optionalDependencies": {
  "fsevents": "^2.3.2"
}

📦 Installiert bei: npm install (wird nicht als Fehler behandelt, wenn nicht verfügbar)
⚙️ Wichtig: Vermeide diese für kritische Features – der Nutzer könnte ohne sie nicht arbeiten.

🔗 5. bundledDependencies – Selten genutzt, aber möglich

Wann? Wenn du alle Abhängigkeiten in einem ZIP liefern willst (z. B. für Offline-Installationen).
Beispiel: Für eine CLI-Toolbox mit eingebetteten Abhängigkeiten.

"bundledDependencies": ["lodash", "moment"]

📦 Installiert bei: npm install (wird nicht über npm registriert)
⚙️ Wichtig: Nicht empfohlen für öffentliche Pakete – vermeide es, es ist veraltet.

⚙️ 6. overrides – Für npm 8+ (Abhängigkeits-Override)

Wann? Wenn du eine bestimmte Version einer Abhängigkeit erzwingen musst (z. B. wegen Sicherheitslücken).
Beispiel: Erzwingen von lodash@4.17.21 statt der automatisch gewählten Version.

"overrides": {
  "lodash": "4.17.21",
  "react": {
    "scheduler": "0.23.0"
  }
}

📦 Installiert bei: npm install (wird nur von npm 8+ unterstützt)
⚙️ Wichtig: Nutze overrides nur als letztes Mittel – vermeide Abhängigkeitskonflikte durch bessere Paketwahl.

⚗️ 7. resolutions – Für Yarn und PNPM

Wann? Für Yarn oder PNPM – erzwingt eine Version über die Abhängigkeitshierarchie.
Beispiel: Für Yarn (nicht für npm).

"resolutions": {
  "lodash": "4.17.21"
}

📦 Installiert bei: yarn install oder pnpm install
⚙️ Wichtig: resolutions ist nicht für npm geeignet – nutze stattdessen overrides.

📊 Zusammenfassung: Die richtige Wahl treffen

TypWann?Installiert in Produktion?Wichtigste Fehler
dependenciesLaufzeit-Abhängigkeiten (z. B. vue)✅ JaDev-Tools hier eintragen
devDependenciesEntwicklungstools (z. B. vite)❌ Neindependencies statt devDependencies
peerDependenciesPlugins (z. B. vue für ein Plugin)❌ Neindependencies statt peerDependencies
optionalDependenciesNicht-kritische Abhängigkeiten❌ NeinNicht für kritische Features
bundledDependenciesSelten – für ZIP-Installationen✅ JaVeraltet – vermeiden
overridesnpm 8+ – Version erzwingen✅ JaNur bei Abhängigkeitskonflikten
resolutionsYarn/PNPM – Version erzwingen✅ JaNicht für npm

✅ Fazit: So vermeidest du Fehler

  1. dependencies = Alles, was während der Laufzeit benötigt wird.
  2. devDependencies = Alles, was nur zur Entwicklung dient.
  3. peerDependencies = Für Bibliotheken, die auf externe Pakete angewiesen sind.
  4. Vermeide bundledDependencies – es ist veraltet.
  5. Nutze overrides für npm 8+, resolutions für Yarn/PNPM.

Mit diesen Regeln wirst du keine unnötigen Abhängigkeiten im Produktionsbuild haben, deine App wird schneller und sicherer – und dein Team wird dich dafür lieben.

💡 Tipp: Nutze npm ls oder yarn why um Abhängigkeiten zu überprüfen. So findest du sofort, ob du falsch klassifiziert hast.

Previous

Next