Skip to main content

In this article

Die 10 wichtigsten npm-Befehle für JavaScript-Entwickler

Artikel von
Headshot of Liran Tal

Liran Tal

0 Min. Lesezeit

Power-User-Befehle vereinfachen komplexe Aufgaben und liefern tiefere Einblicke in die Abhängigkeiten und Konfigurationen Ihres Projekts. Von der Suche nach Schwachstellen bis zur Erstellung einer Software-Stückliste (SBOM): Mit diesen Befehlen arbeiten Sie effizienter und sicherheitsbewusster.

Der Paketmanager npm ist ein unverzichtbares Werkzeug im JavaScript- und Node.js-Ökosystem. Er bildet die Grundlage für die Verwaltung von Abhängigkeiten, Skripten und Konfigurationen, die Entwicklungs-Workflows vereinfachen. Ganz gleich, ob Sie ein kleines Projekt oder eine umfangreiche Anwendung entwickeln: Wenn Sie npm-Befehle beherrschen, können Sie Ihre Produktivität und Codequalität deutlich steigern.

Snyk für sichere JavaScript-Projekte

Sicherheit ist ein entscheidender Aspekt der modernen Softwareentwicklung. Snyk fügt sich nahtlos in Ihren JavaScript-Entwicklungs-Workflow ein und scannt Ihren Quellcode, Open-Source-Pakete, Container-Images und Cloud-Konfigurationen auf Schwachstellen.

Wenn Sie sich diese npm power-user-Befehle für Power-User ansehen, sollten Sie auch erwägen, Ihre Sicherheitslage zu verbessern, indem Sie sich für ein kostenloses Snyk-Konto registrieren.

1. Mit -- Kommandozeilen-Flags an ein npm run-Skript weitergeben

Bei komplexen Projekten müssen Sie häufig zusätzliche Kommandozeilen-Flags an Skripte übergeben, die über npm run ausgeführt werden. Das ist besonders hilfreich, wenn Sie das Verhalten eines Skripts anpassen möchten, ohne das Skript selbst zu ändern. Sie können zum Beispiel die Umgebung dynamisch ändern, Debugging aktivieren oder Konfigurationsoptionen übergeben.

Anwendungsbeispiel für ein npm run-Skript

Um Kommandozeilen-Flags an das von einem npm run-Skript ausgeführte Programm weiterzugeben, verwenden Sie die Syntax mit zwei Bindestrichen --. Alles nach -- wird direkt an das Skript übergeben.

Ein einfaches Beispiel:

{
  "scripts": {
    "start": "node app.js"
  }
}

Sie können das Skript start ausführen und dem Programm app.js zusätzliche Flags wie folgt übergeben:

npm run start -- --port=3000 --env=production

In diesem Fall werden --port=3000 und --env=production als Positionsargumente an das Skript app.js weitergegeben.

Sicherheitsaspekte

Das dynamische Übergeben von Flags kann leistungsstark sein, birgt aber auch potenzielle Sicherheitsrisiken. Stellen Sie sicher, dass die Skripte und übergebenen Flags sicher sind, keine vertraulichen Informationen preisgeben und kein unbeabsichtigtes Verhalten ermöglichen. Validieren und bereinigen Sie Eingaben immer, wenn Sie mit dynamischen Flags arbeiten.

2. Abhängigkeitsbäume mit npm ls untersuchen

Als JavaScript-Entwickler müssen Sie den Abhängigkeitsbaum Ihres Projekts verstehen, um festzustellen, welche Pakete von Schwachstellen betroffen sind. Der Befehl npm ls ist einer dieser Power-User-Befehle, mit denen Sie den Abhängigkeitsbaum Ihres Projekts untersuchen können. Er zeigt eine ASCII-Baumansicht aller Pakete an, von denen Ihr Projekt abhängt, einschließlich ihrer Versionen und hierarchischen Beziehungen.

Syntax und Filteroptionen des Befehls npm ls

Die grundlegende Syntax für den Befehl npm ls lautet:

npm ls [<package-name>]

Mit diesem Befehl können Sie alle Abhängigkeiten auflisten oder einen bestimmten Paketnamen angeben, um sich auf ein Paket zu konzentrieren. Außerdem können Sie die Ausgabe mit den Flags --production oder --development so filtern, dass nur Produktions- beziehungsweise Entwicklungsabhängigkeiten angezeigt werden.

Beispiel: Abhängigkeiten finden, die von einer bestimmten Schwachstelle betroffen sind

Angenommen, Sie haben eine Denial-of-Service-Schwachstelle im ms npm-Paket entdeckt. Mit dem Befehl npm ls können Sie herausfinden, welche Abhängigkeiten Ihres Projekts von dieser anfälligen Version betroffen sind:

Der Befehl gibt den Abhängigkeitsbaum aus und hebt hervor, wo ms verwendet wird. Ein Beispiel für die Ausgabe:

> npm ls ms

goof@1.0.1 /Users/lirantal/projects/repos/nodejs-goof
├─┬ express-session@1.17.2
│ └─┬ debug@2.6.9
│   └── ms@2.0.0
├─┬ express@4.12.4
│ ├─┬ debug@2.2.0
│ │ └── ms@0.7.1
│ ├─┬ finalhandler@0.3.6
│ │ └─┬ debug@2.2.0
│ │   └── ms@0.7.1
│ └─┬ send@0.12.3
│   ├─┬ debug@2.2.0
│   │ └── ms@0.7.1 deduped
│   └── ms@0.7.1
├─┬ humanize-ms@1.0.1
│ └── ms@0.6.2
├─┬ method-override@3.0.0
│ └─┬ debug@3.1.0
│   └── ms@2.0.0
├─┬ mongoose@4.2.4
│ ├─┬ mquery@1.6.3
│ │ └─┬ debug@2.2.0
│ │   └── ms@0.7.1
│ └── ms@0.7.1
├─┬ morgan@1.10.0
│ └─┬ debug@2.6.9
│   └── ms@2.0.0

Sie können auch gezielt nach ms@0.7.1 suchen.

3. Transitive Abhängigkeiten mit npm why verstehen

Bei großen JavaScript-Projekten kann die Verwaltung von Abhängigkeiten komplex werden, insbesondere bei transitiven Abhängigkeiten. Diese sind nicht direkt in Ihrer package.json aufgeführt, werden aber von Ihren direkten Abhängigkeiten benötigt.

Für das Debugging und die Absicherung Ihrer Anwendung kann es entscheidend sein, herauszufinden, warum ein bestimmtes Paket in Ihr Projekt aufgenommen wurde. Der Befehl npm why hilft dabei, indem er ausführliche Informationen dazu liefert, warum ein bestimmtes Paket installiert ist.

Der Befehl npm why ist einfach zu verwenden. Die grundlegende Syntax lautet:

> npm why ms@0.7.1

ms@0.7.1
node_modules/send/node_modules/ms
  ms@"0.7.1" from send@0.12.3
  node_modules/send
    send@"0.12.3" from express@4.12.4
    node_modules/express
      express@"4.12.4" from the root project
    send@"0.12.3" from serve-static@1.9.3
    node_modules/serve-static
      serve-static@"~1.9.3" from express@4.12.4
      node_modules/express
        express@"4.12.4" from the root project
  ms@"0.7.1" from debug@2.2.0
  node_modules/send/node_modules/debug
    debug@"~2.2.0" from send@0.12.3
    node_modules/send
      send@"0.12.3" from express@4.12.4
      node_modules/express
        express@"4.12.4" from the root project
      send@"0.12.3" from serve-static@1.9.3
      node_modules/serve-static
        serve-static@"~1.9.3" from express@4.12.4
        node_modules/express
          express@"4.12.4" from the root project

Wie Sie sehen, gibt dieser npm-Befehl eine ausführliche Erklärung aus, warum ms eingebunden ist, und zeigt die Abhängigkeitskette, die zur Installation geführt hat.

Zusätzliche Tipps zum Befehl npm why

  • Version angeben: Wenn Sie die problematische Version kennen, geben Sie sie im Befehl an, um präzisere Ergebnisse zu erhalten:

npm why ms@0.7.1

  • JSON-Ausgabe verwenden: Für eine umfangreichere, detailliertere Ausgabe mit Abhängigkeitstypen und weiteren Metadaten verwenden Sie das Flag --json:

npm why ms@0.7.1 --json

Das ist besonders nützlich für automatisierte Skripte oder tiefergehende Analysen.

Das Verständnis transitiver Abhängigkeiten ist entscheidend für eine sichere und effiziente Codebasis. Tools wie Snyk Open Source unterstützen Sie zusätzlich, indem sie Ihre Abhängigkeiten auf bekannte Schwachstellen scannen und konkrete Handlungsempfehlungen bereitstellen. Registrieren Sie sich hier für ein kostenloses Snyk-Konto und schützen Sie Ihre Projekte noch heute.

Wenn Sie neu im Abhängigkeitsmanagement sind und verstehen möchten, wie Lockfiles funktionieren, finden Sie hilfreiche Informationen im Artikel „Was ist package lock JSON und wie funktioniert eine Lockfile für Yarn- und npm-Pakete?“. Darin werden semantische Versionierung, Shrinkwrap-Lockfiles, sich verändernde Lockfiles und weitere wichtige Konzepte rund um npm-Lockfiles erklärt.

4. Verfügbare Lifecycle-Skripte mit npm run auflisten

Bei der Arbeit an einem JavaScript- oder Node.js-Projekt müssen Sie häufig verschiedene Skripte ausführen, die in Ihrer package.json-Datei definiert sind, richtig? Zum Beispiel npm run test oder npm run build.

Es kann jedoch schwierig sein, sich die genauen Namen aller npm lifecycle-Skripte zu merken – besonders bei größeren Projekten oder wenn Sie regelmäßig an mehreren Projekten arbeiten, etwa im Backend und Frontend.

Hier hilft der Befehl npm run! Er löst dieses Problem, indem er alle verfügbaren Lifecycle-Skripte in Ihrem Projekt auflistet. So sehen Sie ganz einfach, welche Skripte verfügbar sind und wie Sie sie ausführen.

Ein praktisches Beispiel: Alle npm run-Skripte eines Projekts anzeigen:

> npm run

Lifecycle scripts included in goof@1.0.1:
  start
    NODE_OPTIONS=--openssl-legacy-provider node app.js
  test
    snyk test
available via `npm run-script`:
  dev
    NODE_OPTIONS=--openssl-legacy-provider nodemon ./app.js
  build
    browserify -r jquery > public/js/bundle.js
  cleanup
    mongo express-todo --eval 'db.todos.remove({});'

Die Ausgabe listet alle verfügbaren npm run-Skripte im Projekt und die jeweils ausgeführten Befehle auf. So sparen Sie sich den Umweg, die Datei package.json in Ihrer IDE oder im Terminal zu öffnen!

5. Erweiterte Abfragen zu Abhängigkeiten mit npm query

Vermutlich ist diese Funktion des Paketmanagers npm wenig bekannt: Sie können damit Abhängigkeiten anhand ihrer Attribute filtern und auswählen. Das kann nötig sein, um die Auswirkungen einer Drittanbieterabhängigkeit zu verstehen oder gezielte Aktionen auszuführen. Die passende npm-Abhängigkeit zu finden, kann jedoch schwierig sein.

Der mit npm@8 eingeführte Befehl npm query ermöglicht erweiterte Abfragen zu Abhängigkeiten mithilfe einer Abfragesprache. Damit können Sie Abhängigkeiten anhand ihrer Attribute filtern und auswählen und so die Abhängigkeiten Ihres Projekts einfacher verwalten und überprüfen.

So verwenden Sie die npm query-Syntax

Die Syntax des Befehls npm query lautet:

npm query "<query>"

Der knifflige Teil ist die Abfrage. Die Abfragesprache (DSL) unterstützt verschiedene Attribute und Operatoren, mit denen Sie Ihre Suche präzisieren können. So können Sie Abhängigkeiten beispielsweise anhand ihrer Lifecycle-Skripte, Versionen oder anderer Metadaten von Drittanbieterpaketen filtern.

Beispiel: Abhängigkeiten mit einem postinstall-npm-Skript finden

Angenommen, Sie möchten alle Abhängigkeiten in Ihrem Projekt finden, die ein postinstall-Skript enthalten. Das ist hilfreich, um Pakete zu identifizieren, die während der Installation Skripte ausführen und dadurch Sicherheitsrisiken darstellen oder den Build-Prozess beeinflussen könnten. Verwenden Sie dazu die folgende Abfrage:

npm query ":attr(scripts, [postinstall])"

Dieser Befehl gibt eine Liste der Abhängigkeiten aus, in deren package.json -Datei ein postinstall-Skript definiert ist.

Die Ausgabe könnte etwa so aussehen:

[
  {
    "name": "some-package",
    "version": "1.0.0",
    "scripts": {
      "postinstall": "node setup.js"
    }
  }
]

In diesem Beispiel enthält some-package ein postinstall-Skript, das node setup.js ausführt. Diese Informationen helfen Ihnen, Ihre Abhängigkeiten auf potenzielle Sicherheitsrisiken oder unerwünschtes Verhalten zu überprüfen.

Zusätzlicher Tipp: Mit dem Open-Source-Tool npq für Supply-Chain-Sicherheit können Sie vorbeugend prüfen, ob die zu installierenden Abhängigkeiten postinstall- oder preinstall-Skripte enthalten, bevor Sie sie installieren.

6. Versionen mit npm diff vergleichen

Die Änderungen zwischen verschiedenen Versionen eines Pakets zu verstehen, ist entscheidend für eine sichere und stabile Codebasis. Das ist nützlich, wenn Sie herausfinden möchten, was sich zwischen zwei Paketversionen geändert hat.

Mit dem Befehl npm diff können Sie zwei Paketversionen vergleichen. Das ist besonders hilfreich, um potenzielle Sicherheitsprobleme, veraltete Funktionen, geänderte Abhängigkeiten oder wichtige Änderungen zu erkennen, die sich auf Ihre Anwendung auswirken könnten.

Der Befehl npm diff ist einfach zu verwenden und ähnelt dem Befehl git diff:

npm diff --diff=<package@version1> --diff=<package@version2>

Angenommen, Sie möchten die Änderungen zwischen den Versionen 2.1.2 und 2.1.3 des Pakets ms vergleichen. Führen Sie dazu den folgenden Befehl aus:

npm diff --diff=ms@2.1.3 --diff=ms@2.1.2

Die Ausgabe zeigt die Code-Unterschiede ähnlich wie bei einer git-diff-Ausgabe:

diff --git a/index.js b/index.js
index v2.1.3..v2.1.2 100644
--- a/index.js
+++ b/index.js
@@ -23,7 +23,7 @@
  * @api public
  */

-module.exports = function (val, options) {
+module.exports = function(val, options) {
   options = options || {};
   var type = typeof val;
   if (type === 'string' && val.length > 0) {
diff --git a/package.json b/package.json
index v2.1.3..v2.1.2 100644
--- a/package.json
+++ b/package.json
@@ -1,8 +1,8 @@
 {
   "name": "ms",
-  "version": "2.1.3",
+  "version": "2.1.2",
   "description": "Tiny millisecond conversion utility",
-  "repository": "vercel/ms",
+  "repository": "zeit/ms",
   "main": "./index",
   "files": [
     "index.js"
@@ -28,11 +28,10 @@
   },
   "license": "MIT",
   "devDependencies": {
-    "eslint": "4.18.2",
+    "eslint": "4.12.1",
     "expect.js": "0.3.1",
     "husky": "0.14.3",
     "lint-staged": "5.0.0",
-    "mocha": "4.0.1",
-    "prettier": "2.0.5"
+    "mocha": "4.0.1"
   }
 }
diff --git a/license.md b/license.md
index v2.1.3..v2.1.2 100644
--- a/license.md
+++ b/license.md
@@ -1,6 +1,6 @@
 The MIT License (MIT)

-Copyright (c) 2020 Vercel, Inc.
+Copyright (c) 2016 Zeit, Inc.

 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
diff --git a/readme.md b/readme.md
index v2.1.3..v2.1.2 100644
--- a/readme.md
+++ b/readme.md
@@ -1,6 +1,7 @@
 # ms

-![CI](https://github.com/vercel/ms/workflows/CI/badge.svg)
+[![Build Status](https://travis-ci.org/zeit/ms.svg?branch=master)](https://travis-ci.org/zeit/ms)
+[![Join the community on Spectrum](https://withspectrum.github.io/badge/badge.svg)](https://spectrum.chat/zeit)

 Use this package to easily convert various time formats to milliseconds.

Sie können die Änderungen nun überprüfen und sicherstellen, dass sie weder Sicherheitslücken noch inkompatible Änderungen verursachen.

7. SBOMs mit npm sbom erstellen und scannen

SBOM steht für Software Bill of Materials und bezeichnet eine detaillierte Liste aller Komponenten und Abhängigkeiten Ihrer Software – vergleichbar mit einem Rezept, das sämtliche Zutaten aufführt.

Diese Transparenz hilft dabei, potenzielle Schwachstellen zu erkennen und die Einhaltung verschiedener Sicherheitsstandards sicherzustellen. SBOMs sind besonders wichtig für die Supply-Chain-Sicherheit: Um Risiken zu verwalten und Vertrauen zu schaffen, müssen Sie die Komponenten Ihrer Software kennen.

Sicherheitsteams verwenden SBOMs häufig, um die Einhaltung von Branchenstandards und Vorschriften wie der Executive Order zur Cybersicherheit sicherzustellen.

So verwenden Sie npm sbom und integrieren es mit Snyk

Der Befehl npm sbom erstellt eine SBOM für Ihr Projekt oder Ihren Workspace.

Besonders nützlich ist er in Kombination mit Snyk, einem Tool für Entwicklersicherheit, das Quellcode, Open-Source-Pakete, Container-Images und Cloud-Konfigurationen auf Schwachstellen scannt.

Sie können mit npm als Paketmanager eine SBOM für alle Projektabhängigkeiten erstellen und anschließend das Ergebnis mit dem vollständigen Abhängigkeitsbaum an Snyk senden, um es auf Schwachstellen zu scannen. Das alles lässt sich direkt über die CLI erledigen.

Die grundlegende Syntax, um mit npm sbom eine SBOM im CycloneDX-Format zu erstellen, lautet:

npm sbom --sbom-format cyclonedx > sbom.cdx.json

Anschließend können Sie diese SBOM mit Snyk auf Schwachstellen scannen:

snyk sbom test --experimental --file=sbom.cdx.json

Dabei wird eine Ausgabe der in der SBOM gefundenen Schwachstellen einschließlich ihrer Schweregrade erstellt:

× [HIGH] Regular Expression Denial of Service (ReDoS)
  Introduced through: pkg:npm/negotiator@0.2.8
  URL: https://security.snyk.io/vuln/npm:negotiator:20160616

× [HIGH] Uninitialized Memory Exposure
  Introduced through: pkg:npm/npmconf@0.0.24
  URL: https://security.snyk.io/vuln/npm:npmconf:20180512

× [HIGH] Prototype Override Protection Bypass
  Introduced through: pkg:npm/qs@2.2.4
  URL: https://security.snyk.io/vuln/npm:qs:20170213

× [CRITICAL] Incomplete List of Disallowed Inputs
  Introduced through: pkg:npm/babel-traverse@6.26.0
  URL: https://security.snyk.io/vuln/SNYK-JS-BABELTRAVERSE-5962463

× [CRITICAL] Prototype Pollution
  Introduced through: pkg:npm/handlebars@4.0.11
  URL: https://security.snyk.io/vuln/SNYK-JS-HANDLEBARS-534988

× [CRITICAL] Server-side Request Forgery (SSRF)
  Introduced through: pkg:npm/parse-url@5.0.1
  URL: https://security.snyk.io/vuln/SNYK-JS-PARSEURL-2936249

× [CRITICAL] Arbitrary File Write via Archive Extraction (Zip Slip)
  Introduced through: pkg:npm/adm-zip@0.4.7
  URL: https://security.snyk.io/vuln/npm:adm-zip:20180415

╭──────────────────────────────────────────────────────────────────────╮
│  Test summary                                                        │
│    Organization:    a30b7399-4e0c-4f6e-ba84-b27e131db54c             │
│    Test type:       Software Bill of Materials                       │
│    Path:            sbom.cdx.json                                    │
│                                                                      │
│    Open issues:     148 [ 4 CRITICAL  64 HIGH  72 MEDIUM  8 LOW ]    │
╰──────────────────────────────────────────────────────────────────────╯

8. Abhängigkeiten mit Overrides in package.json festlegen

Wie Sie vielleicht bereits festgestellt haben, kann Abhängigkeitsmanagement ein zweischneidiges Schwert sein. Mit npm lassen sich Abhängigkeiten zwar ganz einfach einbinden und verwalten, doch dadurch kann Ihr Projekt auch Sicherheitsproblemen durch transitive Abhängigkeiten ausgesetzt sein.

Ein wesentliches Problem für Entwickler sind Schwachstellen oder inkompatible Änderungen, die in transitiven Abhängigkeiten auftreten. So kann beispielsweise ein weit verbreitetes Paket plötzlich eine Schwachstelle oder eine inkompatible Änderung einführen, die Ihr gesamtes Projekt betrifft.

Mit overrides in der Datei package.json bietet npm eine leistungsstarke Funktion, um Risiken zu minimieren. Damit können Sie bestimmte Versionen direkter und transitiver Abhängigkeiten festlegen und sicherstellen, dass Ihr Projekt nur Versionen verwendet, denen Sie vertrauen.

Ein konkreter Fall, in dem overrides von unschätzbarem Wert waren, war der Sicherheitsvorfall mit Protestware in den Paketen peacenotwar und node-ipc im März 2022. Sie trugen dazu bei, Beeinträchtigungen für Nutzer der Pakete einzudämmen.

So verwenden Sie die overrides-Konfiguration in package.json

Um die Funktion overrides zu nutzen, fügen Sie Ihrer Datei package.json einen Abschnitt overrides hinzu. In diesem Abschnitt legen Sie fest, welche Versionen von Abhängigkeiten verwendet werden sollen – unabhängig davon, was in den jeweiligen Dateien package.json der Abhängigkeiten angegeben ist.

Hier sehen Sie ein einfaches Beispiel für die Verwendung von overrides:

{
  "name": "your-project",
  "version": "1.0.0",
  "dependencies": {
    "some-package": "^2.0.0"
  },
  "overrides": {
    "node-ipc@>9.2.1 <10": "9.2.1",
    "node-ipc@>10.1.0": "10.1.0"
  }
}

In diesem Beispiel:

  • Das Paket node-ipc wird für Versionen größer als 9.2.1 und kleiner als 10 auf Version 9.2.1 festgelegt.

  • Das Paket node-ipc wird für Versionen ab 10.1.0 auf Version 10.1.0 festgelegt.

Sicherheit verbessern mit Snyk

Das Festlegen von Abhängigkeitsversionen kann einige Risiken mindern, ist aber kein Allheilmittel. Es ist entscheidend, Ihr Projekt regelmäßig auf Schwachstellen zu prüfen. Ein entwicklerorientiertes Sicherheitstool wie Snyk erkennt Malware, Protestware und allgemeine Sicherheitslücken in Ihren Abhängigkeiten so schnell wie möglich und unterstützt Sie bei deren Behebung.

Erstellen Sie hier ein kostenloses Konto, um mit Snyk loszulegen.

9. Lokale Paketentwicklung mit npm install

Wenn Sie npm-Pakete lokal entwickeln, müssen Sie sie häufig in einem anderen Projekt testen. Wenn Ihnen die integrierte Funktion von npm nicht bekannt ist, müssen Sie das Paket in der npm-Registry veröffentlichen. Das kann umständlich und zeitaufwendig sein, insbesondere wenn Sie häufig Änderungen vornehmen müssen.

Mit dem Befehl npm install <path-to-package-in-disk-directory> können Sie dieses Problem lösen: Installieren und verknüpfen Sie lokale Pakete direkt aus Ihrem Entwicklungsverzeichnis. Dabei wird ein symbolischer Link zum Verzeichnis auf der Festplatte erstellt, in dem Sie das Paket entwickeln. So lassen sich Änderungen nahtlos übernehmen und Tests durchführen, ohne das Paket wiederholt veröffentlichen zu müssen (dank des Symlinks müssen Sie es auch nicht erst deinstallieren und anschließend lokal neu installieren).

Wechseln Sie zur Verwendung dieses Befehls in das Stammverzeichnis des Projekts, in dem Sie das lokale Paket installieren möchten. Führen Sie dann den folgenden Befehl aus:

npm install /path/to/local/package

Ersetzen Sie /path/to/local/package durch den tatsächlichen Pfad zu Ihrem lokalen Paketverzeichnis. Dieser Befehl erstellt einen symbolischen Link vom Verzeichnis node_module's Ihres Projekts zum lokalen Paketverzeichnis.

Praktische Vorteile der lokalen Paketinstallation mit npm

  • Sofortige Updates: Änderungen am lokalen Paket werden unmittelbar im Projekt übernommen. Eine erneute Veröffentlichung ist nicht nötig.

  • Einfacheres Debugging: Sie können Ihr Paket in Echtzeit im Kontext des übergeordneten Projekts debuggen und testen.

  • Effizienter Workflow: Der Entwicklungsprozess wird optimiert, da der Aufwand für Paketversionierung und -veröffentlichung sinkt.

10. Sicherheit und Kompatibilität mit einer .npmrc-Konfiguration

Die Datei .npmrc ist eine Konfigurationsdatei für npm, mit der Sie das Verhalten von npm-Befehlen anpassen können. Sie spielt eine wichtige Rolle dabei, sowohl die Sicherheit als auch die Kompatibilität Ihrer Node.js-Projekte zu verbessern. Durch die Konfiguration bestimmter Einstellungen in der Datei .npmrc schützen Sie Ihre Projekte vor schädlichen Paketen und stellen sicher, dass Ihre Abhängigkeiten mit bestimmten Node.js-Runtime-Versionen kompatibel sind.

Skripte für mehr Sicherheit ignorieren

Eine der wirksamsten Methoden, Ihr Projekt vor schädlichen Paketen zu schützen, besteht darin, die Ausführung von Lifecycle-Skripten zu deaktivieren. Diese Skripte können während der Installation beliebige Befehle ausführen und stellen daher ein Sicherheitsrisiko dar.

Wenn Sie in Ihrer Datei .npmrc ignore-scripts=true festlegen, verhindern Sie die Ausführung dieser Skripte:

# .npmrc
ignore-scripts=true

Mit dieser Konfiguration führt npm keine preinstall-, postinstall- oder anderen Lifecycle-Skripte aus. Dadurch sinkt das Risiko, dass schädlicher Code ausgeführt wird.

Kompatibilität mit Node.js-Runtime-Versionen

Ein weiterer wichtiger Aspekt für ein sicheres und stabiles Projekt ist die Kompatibilität mit bestimmten Node.js-Runtime-Versionen. Das ist besonders nützlich, wenn Ihr Projekt auf ältere oder nicht mehr unterstützte Node.js-Versionen angewiesen ist. Wenn Sie in Ihrer Datei .npmrc node-version festlegen, weisen Sie npm an, nur Abhängigkeiten zu aktualisieren, die mit der angegebenen Node.js-Version kompatibel sind:

# .npmrc
node-version=14.0.0

Mit dieser Konfiguration berücksichtigt npm nur Abhängigkeiten, deren Einstellungen im Manifest für engines zum angegebenen Node.js-Versionsbereich passen.

Nächste Schritte

Power-user npm sind nicht nur bei der Verwaltung von Abhängigkeiten hilfreich, sondern verbessern auch Sicherheit und Effizienz in Ihrem Entwicklungsworkflow.

Vielleicht interessieren Sie sich auch für weitere Artikel rund um Node.js:

Kostenloses Tool zur Codeprüfung

Sichern Sie Ihren Code, bevor Sie Ihren nächsten Commit erstellen.

Code prüfen