packagejson Archives - XpresServers

So verwenden Sie Node.js-Module mit npm und package.json

Die Autorin wählte den Open Internet/Free Speech Fund, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

Einführung

Aufgrund von solchen Eigenschaften wie ihrer schnellen Performance bezüglich des Input/Output (I/O) und ihrer bekannten JavaScript-Syntax ist Node.js schnell zu einer beliebten Laufzeitumgebung für die Backend-Webentwicklung geworden. Doch mit wachsendem Interesse werden immer größere Anwendungen erstellt und die Verwaltung der Komplexität der Codebasis und ihrer Abhängigkeiten wird immer schwieriger. Node.js organisiert diese Komplexität mithilfe von Modulen. Das sind beliebige einzelne JavaScript-Dateien mit Funktionen oder Objekten, die von anderen Programmen oder Modulen verwendet werden können. Eine Sammlung von einem oder mehreren Modulen wird allgemein als Paket bezeichnet. Die Pakete selbst werden von Paketmanagern organisiert.

Der Node.js-Paketmanager (npm) ist der standardmäßige und beliebteste Paketmanager im Node.js.-Ökosystem und wird in erster Linie zur Installation und Verwaltung externer Module in einem Node.js-Projekt verwendet. Er wird auch häufig genutzt, um eine breite Palette von CLI-Tools zu installieren und Projektskripte auszuführen. npm verfolgt die in einem Projekt installierten Module mit der Datei package.json, die sich im Verzeichnis eines Projekts befindet und Folgendes enthält:

Alle für ein Projekt benötigten Module und ihre installierten Versionen
Alle Metadaten zu einem Projekt, wie z. B. Autor, Lizenz usw.
Skripts, die ausgeführt werden können, um Aufgaben im Projekt zu automatisieren

Wenn Sie komplexere Node.js-Projekte erstellen, bietet Ihnen das Verwalten Ihrer Metadaten und Abhängigkeiten mit der package.json-Datei besser vorhersehbare Builds, da alle externen Abhängigkeiten gleich gehalten werden. Die Datei verfolgt diese Informationen automatisch; während Sie die Datei direkt ändern können, um die Metadaten Ihres Projekts zu aktualisieren, müssen Sie selten direkt mit ihr interagieren, um Module zu verwalten.

In diesem Tutorial verwalten Sie Pakete mit npm. Der erste Schritt besteht darin, die package.json-Datei zu erstellen und zu verstehen. Diese verwenden Sie dann, um alle Module zu verfolgen, die Sie in Ihrem Projekt installieren. Zum Schluss listen Sie Ihre Paketabhängigkeiten auf, aktualisieren Ihre Pakete, deinstallieren Ihre Pakete und führen eine Prüfung zum Auffinden von Sicherheitsmängeln in Ihren Paketen durch.

Voraussetzungen

Um diesem Tutorial zu folgen, benötigen Sie:

Schritt 1 – Erstellen einer `package.json`-Datei

Beginnen wir dieses Tutorial, indem wir das Beispielprojekt einrichten – ein fiktives Node.js-locator-Modul, das die IP-Adresse des Benutzers ermittelt und das Herkunftsland ausgibt. In diesem Tutorial codieren Sie das Modul nicht. Die von Ihnen verwalteten Pakete wären jedoch relevant, wenn Sie es entwickeln würden.

Zuerst erstellen Sie eine package.json-Datei, um nützliche Metadaten über das Projekt zu speichern und um Ihnen die Verwaltung der abhängigen Node.js-Module des Projekts zu erleichtern. Wie die Endung bereits andeutet, handelt es sich um eine JSON-Datei (JavaScript Object Notation). JSON ist ein Standardformat für die gemeinsame Nutzung, das auf JavaScript-Objekten basiert und aus Daten besteht, die als Schlüssel-Wert-Paare gespeichert sind. Wenn Sie mehr über JSON erfahren möchten, lesen Sie unseren Artikel Einführung zu JSON.

Da eine package.json-Datei zahlreiche Eigenschaften enthält, kann ihre manuelle Erstellung umständlich sein, ohne eine Vorlage von einer anderen Stelle zu kopieren und einzufügen. Um das zu erleichtern, bietet npm den Befehl init. Das ist ein interaktiver Befehl, der Ihnen eine Reihe von Fragen stellt und eine package.json-Datei auf der Grundlage Ihrer Antworten erstellt.

Verwenden des Befehls `init`

Erstellen Sie zuerst ein Projekt, mit dem Sie das Verwalten von Modulen praktizieren können. Erstellen Sie in Ihrer Shell einen neuen Ordner namens locator:

Gehen Sie dann in den neuen Ordner:

Initialisieren Sie nun die interaktive Eingabeaufforderung, indem Sie Folgendes eingeben:

Anmerkung: Wenn Ihr Code Git zur Versionskontrolle verwendet, erstellen Sie zuerst das Git-Repository und führen Sie dann npm init aus. Der Befehl versteht automatisch, dass er in einem Git-fähigen Ordner ist. Wenn ein Git-Remote eingestellt ist, füllt es automatisch die Felder repository, bugs und homepage für Ihre package.json-Datei aus. Wenn Sie das Repo nach Erstellung der package.json-Datei initialisiert haben, müssen Sie diese Informationen selbst eingeben. Weitere Informationen zur Git-Versionskontrolle finden Sie in unserer Serie Einführung zu Git: Installation, Verwendung und Zweige.

Sie erhalten die folgende Ausgabe:

OutputThis utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help json` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (locator)

Zuerst werden Sie mit name zur Eingabe des Namens Ihres neuen Projekts aufgefordert. Standardmäßig nimmt der Befehl an, dass dies der Name des Ordners ist, in dem Sie sind. Standardwerte für jede Eigenschaft werden in Klammern () gezeigt. Da der Standardwert für name die Zwecke dieses Tutorials erfüllt, drücken Sie die Eingabetaste, um ihn zu akzeptieren.

Der nächste einzugebende Wert ist version. Neben name ist dieses Feld erforderlich, wenn Ihr Projekt mit anderen im npm-Paket-Repository geteilt wird.

Anmerkung: Es wird erwartet, dass Node.js-Pakete dem Leitfaden Semantic Versioning (semver) folgen, einem Leitfaden für semantische Versionierung. Die erste Ziffer ist daher die MAJOR-Versionsziffer, die sich nur ändert, wenn sich die API ändert. Die zweite Ziffer ist die MINOR-Version, die sich ändert, wenn Eigenschaften hinzugefügt werden. Die letzte Ziffer ist die PATCH-Version, die sich ändert, wenn Fehler behoben werden.

Drücken Sie die Eingabetaste, damit die Standardversion akzeptiert wird.

Das nächste Feld ist description – eine nützliche Zeichenfolge, um zu erklären, was Ihr Node.js-Modul tut. Unser fiktive locator würde die IP-Adresse des Benutzers ermitteln und das Herkunftsland ausgeben. Eine passende description wäre Findet das Ursprungsland der eingehenden Anfrage. Geben Sie etwas in dieser Art ein und drücken Sie die Eingabetaste. Die description ist sehr nützlich, wenn jemand nach Ihrem Modul sucht.

Die nächste Eingabeaufforderung fragt Sie nach dem entry point. Wenn jemand Ihr Modul installiert und mit requires anfordert, wird das, was Sie in entry point festlegen, als erster Teil Ihres Programms geladen. Der Wert muss der relative Speicherort einer JavaScript-Datei sein und wird der main-Eigenschaft des package.json hinzugefügt. Drücken Sie die Eingabetaste, um den Standardwert zu speichern.

Anmerkung: Die meisten Module haben eine index.js-Datei als Haupteingabepunkt. Das ist der Standardwert für die main-Eigenschaft des package.json, die der Eingangspunkt für npm-Module ist. Wenn kein package.json vorhanden ist, wird Node.js standardmäßig versuchen, index.js zu laden.

Als Nächstes werden Sie nach einem test command gefragt, einem ausführbaren Skript oder Befehl zur Ausführung Ihres Projekttests. In vielen beliebten Node.js-Modulen werden Tests mit Mocha, Jest, Jasmine oder anderen Test-Frameworks geschrieben und ausgeführt. Da das Testen über den Umfang dieses Artikels hinausgeht, lassen Sie diese Option jetzt leer und drücken Sie die Eingabetaste, um fortzufahren.

Der Befehl init fragt dann nach dem GitHub-Repository des Projekts. Sie werden es in diesem Beispiel nicht verwenden, also lassen Sie auch das leer.

Nach der Eingabeaufforderung des Repository fragt der Befehl nach keywords. Diese Eigenschaft ist ein Array von Zeichenfolgen mit nützlichen Begriffen, die Personen zum Finden Ihres Repositorys verwenden können. Am besten ist es, wenn Sie eine kleine Anzahl von Wörtern haben, die für Ihr Projekt wirklich relevant sind, damit die Suche gezielter erfolgen kann. Erstellen Sie eine Liste dieser Schlüsselwörter als Zeichenfolge mit Kommas, die die einzelnen Werte trennen. Geben Sie für dieses Beispielprojekt ip,geo,country bei der Eingabeaufforderung ein. Das fertige package.json verfügt nun über drei Elemente im Array für keywords.

Das nächste Feld in der Eingabeaufforderung ist author. Das ist nützlich für die Benutzer Ihres Moduls, die Kontakt mit Ihnen aufnehmen möchten. Wenn zum Beispiel jemand ein Exploit in Ihrem Modul entdeckt, kann er auf diesem Wege das Problem melden, damit Sie es beheben können. Das author-Feld ist eine Zeichenfolge im folgenden Format: "Name <Email> (Website)". Beispielsweise ist „Sammy <sammy@your_domain> (https://your_domain)" ein gültiger Autor. Die Daten zur E-Mail und Website sind optional – ein gültiger Autor kann auch nur ein Name sein. Fügen Sie Ihre Kontaktdaten als Autor hinzu und bestätigen Sie mit der Eingabetaste.

Schließlich werden Sie mit license zur Eingabe der Lizenz aufgefordert. Dadurch werden die rechtlichen Berechtigungen und Beschränkungen für Benutzer bei der Verwendung Ihres Moduls festgelegt. Viele Node.js-Module sind Open-Source-Module, sodass npm die Standardeinstellung auf ISC setzt.

Zu diesem Zeitpunkt würden Sie Ihre Lizenzoptionen überprüfen und entscheiden, was für Ihr Projekt am besten geeignet ist. Weitere Informationen zu verschiedenen Arten von Open-Source-Lizenzen finden Sie in dieser Lizenzliste aus der Open Source Initiative. Wenn Sie keine Lizenz für ein privates Repository bereitstellen möchten, können Sie bei der Eingabeaufforderung UNLICENSED eingeben. Verwenden Sie für dieses Beispiel die standardmäßige ISC-Lizenz und drücken Sie die Eingabetaste, um den Prozess abzuschließen.

Der Befehl init zeigt nun die package.json-Datei, die erstellt wird. Das wird ähnlich aussehen wie folgt:

Output
About to write to /home/sammy/locator/package.json:

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy <sammy@your_domain> (https://your_domain)",
  "license": "ISC"
}


Is this OK? (yes)

Sobald die Informationen mit dem übereinstimmen, was Sie hier sehen, drücken Sie die Eingabetaste, um den Prozess abzuschließen und die Datei package.json zu erstellen. Mit dieser Datei können Sie ein Verzeichnis der Module führen, die Sie für Ihr Projekt installieren.

Nachdem Ihre package.json-Datei nun vorhanden ist, können Sie im nächsten Schritt die Installation von Modulen testen.

`Schritt 2 – Installieren von Modulen`

In der Softwareentwicklung ist es üblich, externe Bibliotheken zu nutzen, um untergeordnete Aufgaben in Projekten auszuführen. Dadurch kann sich der Entwickler auf die Geschäftslogik konzentrieren und die Anwendung schneller und effizienter gestalten.

Wenn beispielsweise unser locater-Beispielmodul eine externe API-Anfrage stellen muss, um geografische Daten zu erhalten, könnten wir eine HTTP-Bibliothek verwenden, um diese Aufgabe zu erleichtern. Da unser Hauptziel darin besteht, sachbezogene geografische Daten an den Benutzer auszugeben, könnten wir ein Paket installieren, das uns HTTP-Anfragen erleichtert – anstatt diesen Code für uns selbst neu zu schreiben, was eine Aufgabe wäre, die den Rahmen unseres Projekts sprengt.

Wir führen dieses Beispiel nun durch. In Ihrer locator-Anwendung nutzen Sie die axios-Bibliothek, die Ihnen bei der Erstellung von HTTP-Anfragen hilft. Installieren Sie sie, indem Sie Folgendes in Ihre Shell eingeben:

Sie beginnen diesen Befehl mit npm install, wodurch das Paket installiert wird (der Einfachheit halber können Sie npm i verwenden). Anschließend listen Sie die Pakete, die installiert werden sollen, durch ein Leerzeichen getrennt auf. In diesem Fall ist das axios. Schließlich beenden Sie den Befehl mit dem optionalen Parameter --save, der angibt, dass axios als Projektabhängigkeit gespeichert wird.

Wenn die Bibliothek installiert ist, sehen Sie eine Ausgabe, die der folgenden ähnelt:

Output...
+ [email protected]
added 5 packages from 8 contributors and audited 5 packages in 0.764s
found 0 vulnerabilities

Öffnen Sie nun die Datei package.json mit einem Texteditor Ihrer Wahl. Dieses Tutorial verwendet nano:

Sie sehen eine neue Eigenschaft, wie im Folgenden hervorgehoben:

locator/package.json

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy sammy@your_domain (https://your_domain)",
  "license": "ISC",
  "dependencies": {
    "axios": "^0.19.0"
  }
}

Die Option --save hat npm angewiesen, die Datei package.json mit dem Modul und der Version zu aktualisieren, die gerade installiert wurden. Das ist sehr gut, da andere Entwickler, die an Ihren Projekten arbeiten, leicht erkennen können, welche externen Abhängigkeiten benötigt werden.

Anmerkung: Vielleicht ist Ihnen das ^ vor der Versionsnummer für die axios-Abhängigkeit aufgefallen. Erinnern Sie sich daran, dass die semantische Versionierung aus drei Ziffern besteht: MAJOR, MINOR und PATCH. Das Symbol ^ bedeutet, dass jede höhere MINOR- oder PATCH-Version diese Versionseinschränkung erfüllen würde. Wenn Sie zu Beginn einer Versionsnummer ~ sehen, erfüllen nur höhere PATCH-Versionen die Einschränkung.

Wenn Sie mit der Prüfung von package.json fertig sind, beenden Sie die Datei.

`Entwicklungsabhängigkeiten`

Pakete, die für die Entwicklung eines Projekts verwendet werden, nicht aber für die Zusammenstellung oder die Ausführung in der Produktion, werden als Entwicklungsabhängigkeiten bezeichnet. Sie sind nicht notwendig, damit Ihr Modul oder Ihre Anwendung in der Produktion funktioniert, können aber beim Schreiben des Codes hilfreich sein.

Beispielsweise ist es üblich, dass Entwickler Code-Linter verwenden, um sicherzustellen, dass ihr Code bewährte Praktiken verfolgt und um den Stil konsistent zu halten. Das ist für die Entwicklung nützlich, erhöht aber die Menge des Verteilbaren, ohne beim Einsatz in der Produktion einen spürbaren Nutzen zu bieten.

Installieren Sie einen Linter als Entwicklungsabhängigkeit für Ihr Projekt. Probieren Sie Folgendes in Ihrer Shell aus:

npm i [email protected] --save-dev

In diesem Befehl haben Sie das Flag --save-dev verwendet. Dadurch wird eslint als Abhängigkeit gespeichert, die nur für die Entwicklung benötigt wird. Beachten Sie auch, dass Sie Ihrem Abhängigkeitsnamen @6.0.0 hinzugefügt haben. Wenn Module aktualisiert werden, werden sie mit einer Version getaggt. Das @ weist npm an, nach einem bestimmten Tag des Moduls, das Sie installieren, zu suchen. Ohne ein bestimmtes Tag installiert npm die letzte getaggte Version. Öffnen Sie package.json erneut:

Dadurch wird Folgendes angezeigt:

locator/package.json

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy sammy@your_domain (https://your_domain)",
  "license": "ISC",
  "dependencies": {
    "axios": "^0.19.0"
  },
  "devDependencies": {
    "eslint": "^6.0.0"
  }
}

eslint wurde als eine devDependencies gespeichert, zusammen mit der zuvor von Ihnen angegebenen Versionsnummer. Beenden Sie package.json.

`Automatisch generierte Dateien: node_modules und package-lock.json`

Wenn Sie zum ersten Mal ein Paket in einem Node.js-Projekt installieren, erstellt npm automatisch den Ordner node_modules, um die für Ihr Projekt erforderlichen Module zu speichern, und die Datei package-lock.json, die Sie zuvor geprüft haben.

Bestätigen Sie, dass sich diese in Ihrem Arbeitsverzeichnis befinden. Geben Sie in Ihrer Shell ls ein und drücken Sie die Eingabetaste. Sie sehen folgende Ausgabe:

Outputnode_modules    package.json    package-lock.json

Der Ordner node_modules enthält jede installierte Abhängigkeit für Ihr Projekt. In den meisten Fällen sollten Sie diesen Ordner nicht in Ihr versionskontrolliertes Repository übertragen. Wenn Sie weitere Abhängigkeiten installieren, wird die Größe dieses Ordners schnell anwachsen. Darüber hinaus werden in der Datei package-lock.json die genauen installierten Versionen in einer knapperen Form aufgezeichnet, sodass das Einfügen von node_modules nicht notwendig ist.

Während die Datei package.json Abhängigkeiten auflistet, die uns die geeigneten Versionen zeigen, die für das Projekt installiert werden sollten, verfolgt die Datei package-lock.json alle Änderungen in package.json oder node_modules und zeigt uns die genaue Version des installierten Pakets. Normalerweise übergeben Sie diese an Ihr versionskontrolliertes Repository statt an node_modules, da dies eine sauberere Darstellung all Ihrer Abhängigkeiten bietet.

`Installieren aus package.json`

Mit Ihren Dateien package.json und package-lock.json können Sie schnell die gleichen Projektabhängigkeiten einrichten, bevor Sie die Entwicklung eines neuen Projekts starten. Um dies zu demonstrieren, gehen Sie in Ihrem Verzeichnisbaum eine Ebene höher und erstellen Sie einen neuen Ordner namens cloned_locator auf derselben Verzeichnisebene wie locator:

cd ..
mkdir cloned_locator

Gehen Sie in Ihr neues Verzeichnis:

Kopieren Sie nun die Dateien package.json und package-lock.json von locator zu cloned_locator:

cp ../locator/package.json ../locator/package-lock.json .

Um die erforderlichen Module für dieses Projekt zu installieren, geben Sie Folgendes ein:

npm wird nach einer package-lock.json-Datei suchen, um die Module zu installieren. Wenn keine Lock-Datei verfügbar ist, würde npm aus der Datei package.json lesen, um die Installationen zu bestimmen. Normalerweise ist es schneller, aus package-lock.json zu installieren, da die Lock-Datei die genaue Version von Modulen und deren Abhängigkeiten enthält. So muss npm nicht lange nach einer geeigneten Version für die Installation suchen.

Beim Einsatz in der Produktion können Sie die Entwicklungsabhängigkeiten überspringen. Erinnern Sie sich daran, dass Entwicklungsabhängigkeiten im Abschnitt devDependencies von package.json gespeichert werden und keinen Einfluss auf die Ausführung Ihrer Anwendung haben. Wenn Sie Module als Teil des CI/CD-Prozesses zur Bereitstellung Ihrer Anwendung installieren, lassen Sie die dev-Abhängigkeiten weg, indem Sie Folgendes ausführen:

Das Flag --production ignoriert den Abschnitt devDependencies während der Installation. Bleiben Sie vorerst bei Ihrem Entwicklungs-Build.

Bevor Sie zum nächsten Abschnitt übergehen, kehren Sie zum Ordner locator zurück:

`Globale Installationen`

Bisher haben Sie npm-Module für das locator-Projekt installiert. npm bietet Ihnen auch die Möglichkeit, Pakete global zu installieren. Das bedeutet, dass das Paket wie jeder andere Shell-Befehl für Ihren Benutzer im weiteren System verfügbar ist. Diese Fähigkeit ist für die vielen Node.js-Module nützlich, die CLI-Tools sind.

Vielleicht möchten Sie zum Beispiel über das locator-Projekt bloggen, an dem Sie gerade arbeiten. Dazu können Sie eine Bibliothek wie Hexo verwenden, um Ihren statischen Website-Blog zu erstellen und zu verwalten. Installieren Sie die Hexo-CLI wie folgt:

Um ein Paket global zu installieren, hängen Sie das Flag -g an den Befehl an.

Anmerkung: Wenn Sie beim Versuch, dieses Paket global zu installieren, eine Fehlermeldung bezüglich der Berechtigung erhalten, benötigt Ihr System möglicherweise Superuser-Rechte, um den Befehl auszuführen. Versuchen Sie es erneut mit sudo npm i hexo-cli -g.

Testen Sie, ob das Paket erfolgreich installiert wurde, indem Sie Folgendes eingeben:

Sie werden eine Ausgabe sehen, die der folgenden ähnelt:

Outputhexo-cli: 2.0.0
os: Linux 4.15.0-64-generic linux x64
http_parser: 2.7.1
node: 10.14.0
v8: 7.6.303.29-node.16
uv: 1.31.0
zlib: 1.2.11
ares: 1.15.0
modules: 72
nghttp2: 1.39.2
openssl: 1.1.1c
brotli: 1.0.7
napi: 4
llhttp: 1.1.4
icu: 64.2
unicode: 12.1
cldr: 35.1
tz: 2019a

Bisher haben Sie gelernt, wie Sie Module mit npm installieren. Sie können Pakete lokal in ein Projekt installieren, entweder als Produktions- oder Entwicklungsabhängigkeit. Sie können auch Pakete installieren, die auf bereits existierenden package.json– oder package-lock.json-Dateien basieren. So können Sie mit den gleichen Abhängigkeiten entwickeln wie Ihre Peers. Außerdem können Sie das Flag -g verwenden, um Pakete global zu installieren und auf diese zuzugreifen – unabhängig davon, ob Sie sich in einem Node.js-Projekt befinden oder nicht.

Nachdem Sie nun Module installieren können, werden Sie im nächsten Abschnitt Techniken zur Verwaltung Ihrer Abhängigkeiten anwenden.

`Schritt 3 — Verwalten von Modulen`

Ein vollständiger Paketmanager kann viel mehr als nur Module installieren. npm verfügt über mehr als 20 Befehle bezüglich der Verwaltung von Abhängigkeiten. In diesem Schritt werden Sie folgende Aufgaben erledigen:

Module auflisten, die Sie installiert haben.
Module auf eine neuere Version aktualisieren.
Module deinstallieren, die Sie nicht mehr benötigen.
Eine Sicherheitsprüfung in Ihren Modulen ausführen, um Sicherheitsmängel zu finden und zu beheben.

Obwohl diese Beispiele in Ihrem locator-Ordner angewendet werden, können alle diese Befehle auch global ausgeführt werden, indem Sie das Flag -g am Ende anhängen – genau wie bei der globalen Installation.

`Module auflisten`

Wenn Sie wissen möchten, welche Module in einem Projekt installiert sind, ist es einfacher, den list– oder ls-Befehl zu verwenden, anstatt das package.json direkt zu lesen. Dazu geben Sie Folgendes ein:

Sie werden eine Ausgabe wie diese sehen:

Output
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └─┬ [email protected]
│ │   └── [email protected]
│ └── [email protected]
└─┬ [email protected]
  ├─┬ @babel/[email protected]
  │ └─┬ @babel/[email protected]
  │   ├── [email protected] deduped
  │   ├── [email protected] deduped
  │   └── [email protected]
  ├─┬ [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ └─┬ [email protected]
...

Standardmäßig zeigt ls den gesamten Abhängigkeitenbaum – die Module, auf die Ihr Projekt angewiesen ist, und die Module, auf die Ihre Abhängigkeiten angewiesen sind. Das kann etwas unhandlich sein, wenn Sie einen Überblick auf hoher Ebene über die installierten Systeme haben wollen.

Um nur die von Ihnen installierten Module ohne deren Abhängigkeiten zu zeigen, geben Sie in Ihrer Shell Folgendes ein:

Sie erhalten folgende Ausgabe:

Output
├── [email protected]
└── [email protected]

Mit der Option --depth können Sie angeben, welche Ebene des Abhängigkeitenbaums Sie sehen möchten. Wenn diese 0, ist, sehen Sie nur Ihre Abhängigkeiten auf höchster Ebene.

`Module aktualisieren`

Das ist eine gute Praxis, Ihre npm-Module auf dem neuesten Stand zu halten. Es erhöht die Wahrscheinlichkeit, die neuesten Sicherheitskorrekturen für ein Modul zu erhalten. Verwenden Sie den Befehl outdated, um zu prüfen, ob Module aktualisiert werden können:

Sie erhalten eine ähnliche Ausgabe:

OutputPackage  Current  Wanted  Latest  Location
eslint     6.0.0   6.7.1   6.7.1  locator

Der Befehl listet zuerst unter Package das installierte Paket und unter Current die aktuelle Version auf. Die Spalte Wanted zeigt, welche Version Ihre Versionsanforderung in package.json erfüllt. Die Spalte Latest zeigt die neueste veröffentlichte Version des Moduls.

Die Spalte Location gibt an, wo sich das Paket im Abhängigkeitenbaum befindet. Der Befehl outdated hat so wie ls das Flag --depth. Die Standardeinstellung für depth ist 0.

Scheinbar können Sie eslint auf eine neuere Version aktualisieren. Verwenden Sie den update– oder up-Befehl wie folgt:

Die Ausgabe des Befehls enthält die installierte Version:

Output
npm WARN [email protected] No repository field.

+ eslint@6.7.1
added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s
found 0 vulnerabilities

Wenn Sie alle Module auf einmal aktualisieren möchten, geben Sie ein:

`Module deinstallieren`

Der npm-Befehl uninstall kann Module aus Ihren Projekten entfernen. Das bedeutet, dass das Modul nicht länger im Ordner node_modules installiert sein wird. Auch wird es in den Dateien package.json und package-lock.json nicht mehr zu sehen sein.

Die Entfernung von Abhängigkeiten aus einem Projekt ist eine normale Aktivität im Zyklus der Softwareentwicklung. Vielleicht löst eine Abhängigkeit ein Problem nicht so wie zuvor angepriesen oder es bietet keine zufriedenstellenden Entwicklungsergebnisse. In diesen Fällen kann es besser sein, die Abhängigkeit zu deinstallieren und Ihr eigenes Modul zu erstellen.

Stellen Sie sich vor, dass axios nicht das Entwicklungsergebnis bietet, das Sie sich für die Erstellung von HTTP-Anfragen vorgestellt haben. Desinstallieren Sie axios mit dem uninstall– oder un-Befehl, indem Sie Folgendes eingeben:

Ihre Ausgabe wird der folgenden ähneln:

Output
npm WARN [email protected] No repository field.

removed 5 packages and audited 176 packages in 1.488s
found 0 vulnerabilities

Sie gibt nicht ausdrücklich an, dass axios entfernt wurde. Um zu überprüfen, ob es deinstalliert wurde, listen Sie erneut die Abhängigkeiten auf:

Jetzt sehen wir, dass nur eslint installiert ist:

Output
└── eslint@6.7.1

Das zeigt, dass Sie das Paket axios erfolgreich desinstalliert haben.

`Module prüfen`

npm bietet einen audit-Befehl, um auf potenzielle Sicherheitsmängel in Ihren Abhängigkeiten zu verweisen. Um den Prüfbefehl audit in Aktion zu sehen, installieren Sie eine veraltete Version des Moduls request, indem Sie Folgendes ausführen:

Wenn Sie diese veraltete Version von request installieren, erhalten Sie eine Ausgabe, die der folgenden ähnelt:

Output
+ [email protected]
added 54 packages from 49 contributors and audited 243 packages in 7.26s
found 6 moderate severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details

npm teilt Ihnen mit, dass Sie Schwachstellen in Ihren Abhängigkeiten haben. Um weitere Informationen zu erhalten, prüfen Sie Ihr gesamtes Projekt mit:

Der Befehl audit zeigt in der Ausgabe Tabellen, in denen Sicherheitsmängel hervorgehoben werden:

Output                       === npm audit security report ===

# Run  npm install [email protected]  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Memory Exposure                                              │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tunnel-agent                                                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ request > tunnel-agent                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/598                             │
└───────────────┴──────────────────────────────────────────────────────────────┘

# Run  npm update request --depth 1  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Remote Memory Exposure                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/309                             │
└───────────────┴──────────────────────────────────────────────────────────────┘
...

Sie können den Pfad der Schwachstelle sehen und manchmal bietet npm Ihnen Möglichkeiten, sie zu beheben. Sie können wie vorgeschlagen den Befehl zur Aktualisierung oder den Unterbefehl fix des audit ausführen. Geben Sie Folgendes in Ihre Shell ein:

Sie sehen eine ähnliche Ausgabe:

Output
+ [email protected]
added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s
fixed 2 of 6 vulnerabilities in 243 scanned packages
  4 vulnerabilities required manual review and could not be updated

npm konnte zwei der Pakete sicher aktualisieren und Ihre Schwachstellen um die gleiche Anzahl verringern. Sie haben jedoch immer noch vier Schwachstellen in Ihren Abhängigkeiten. Der Befehl audit fix korrigiert nicht immer jedes Problem. Obwohl eine Version eines Moduls eine Sicherheitsschwachstelle aufweisen kann, könnte eine Aktualisierung auf eine Version mit einer anderen API den Code weiter oben im Abhängigkeitenbaum aufbrechen.

Sie können den Parameter --force auf folgende Weise verwenden, um sicherzustellen, dass die Schwachstellen nicht mehr vorhanden sind:

Wie bereits erwähnt, wird dies nicht empfohlen, solange Sie sich nicht sicher sind, dass die Funktionalität hiervon nicht beeinträchtigt wird.

`Zusammenfassung`

In diesem Tutorial haben Sie verschiedene Übungen durchlaufen, die zeigen, wie Node.js-Module in Paketen organisiert sind und wie diese Pakete von npm verwaltet werden. Sie haben in einem Node.js-Projekt npm-Pakete als Abhängigkeiten verwendet, indem Sie eine package.json-Datei erstellt und verwaltet haben. Diese Datei beinhaltet eine Aufzeichnung der Metadaten Ihres Projekts einschließlich der Module, die Sie installiert haben. Neben dem Auflisten Ihres Abhängigkeitenbaums Ihrer Projekte sowie dem Prüfen und Aktualisieren veralteter Module haben Sie das npm-CLI-Tool zum Installieren, Aktualisieren und Entfernen von Modulen verwendet.

In Zukunft können Sie Module verwenden, um vorhandenen Code einzusetzen und dadurch die Entwicklungszeit beschleunigen, da Sie die Funktionalität nicht wiederholen müssen. Sie werden zudem in der Lage sein, eigene npm-Module zu erstellen, die wiederum von anderen über npm-Befehle verwaltet werden. Experimentieren Sie als Nächstes mit dem, was Sie in diesem Tutorial gelernt haben, indem Sie einige der vielen existierenden Pakete installieren und testen. Sehen Sie sich an, was das Ökosystem bietet, um die Problemlösung zu erleichtern. Sie könnten zum Beispiel TypeScript, eine übergeordnete Programmiersprache von JavaScript, ausprobieren oder Ihre Website mit Cordova in mobile Anwendungen verwandeln. Wenn Sie mehr über Node.js lernen möchten, lesen Sie unsere anderen Node.js-Tutorials.

Source link

`Comment utiliser les modules Node.js avec npm et package.json`

hassan latif
blog

L’auteur a choisi le Open Internet/Free Speech Fund pour recevoir un don dans le cadre du programme Write for DOnations.

`Introduction`

Grâce à des caractéristiques telles que ses bonnes performances d’entrée/sortie (E/S) et sa syntaxe JavaScript bien connue, Node.js est rapidement devenu un environnement d’exécution populaire pour le développement Web back-end. Mais à mesure que l’intérêt grandit, de plus grandes applications sont construites, et la gestion de la complexité de la base de code et de ses dépendances devient plus difficile. Node.js organise cette complexité à l’aide de modules, qui sont des fichiers JavaScript individuels contenant des fonctions ou des objets pouvant être utilisés par d’autres programmes ou modules. Un ensemble d’un ou plusieurs modules est communément appelé paquet, et ces paquets sont eux-mêmes organisés par des gestionnaires de paquets.

Node.js Package Manager (npm) est le gestionnaire de paquets par défaut et le plus populaire dans l’écosystème Node.js. Il est principalement utilisé pour installer et gérer des modules externes dans un projet Node.js. Il est également couramment utilisé pour installer une large gamme d’outils CLI et exécuter des scripts de projet. npm suit les modules installés dans un projet avec le fichier package.json, qui réside dans le répertoire d’un projet et contient :

Tous les modules nécessaires à un projet et leurs versions installées
Toutes les métadonnées d’un projet, telles que l’auteur, la licence, etc.
Les scripts pouvant être exécutés pour automatiser des tâches dans le cadre du projet

À mesure que vous créez des projets Node.js plus complexes, la gestion de vos métadonnées et dépendances avec le fichier package.json vous fournira des builds plus prévisibles, puisque toutes les dépendances externes restent les mêmes. Le fichier gardera automatiquement la trace de ces informations ; si vous pouvez modifier le fichier directement pour mettre à jour les métadonnées de votre projet, vous aurez rarement besoin d’interagir directement avec lui pour gérer les modules.

Dans ce tutoriel, vous allez gérer des paquets avec npm. La première étape consistera à créer et comprendre le fichier package.json. Vous l’utiliserez ensuite pour garder une trace de tous les modules que vous installez dans votre projet. Enfin, vous listerez les dépendances de vos paquets, mettrez à jour vos paquets, désinstallerez vos paquets et effectuerez un audit pour trouver des failles de sécurité dans vos paquets.

`Conditions préalables`

Pour suivre ce tutoriel, vous aurez besoin de :

`Étape 1 — Création d’un fichier package.json`

Nous commençons ce tutoriel en configurant le projet exemple : un module Node.js fictif locator qui obtient l’adresse IP de l’utilisateur et renvoie le pays d’origine. Vous ne coderez pas le module dans ce tutoriel. Cependant, les paquets que vous gérez seraient pertinents si vous les développiez.

Tout d’abord, vous allez créer un fichier package.json pour stocker des métadonnées utiles sur le projet et vous aider à gérer les modules Node.js dépendants du projet. Comme le suffixe le suggère, il s’agit d’un fichier JSON (JavaScript Object Notation). JSON est un format standard utilisé pour le partage, basé sur des objets JavaScript et constitué de données stockées sous forme de paires clé-valeur. Si vous souhaitez en savoir plus sur JSON, lisez notre article Introduction à JSON.

Comme un fichier package.json contient de nombreuses propriétés, il peut être lourd à créer manuellement, sans copier et coller un modèle provenant d’un autre endroit. Pour faciliter les choses, npm fournit la commande init. Il s’agit d’une commande interactive qui vous pose une série de questions et crée un fichier package.json en fonction de vos réponses.

`Utilisation de la commande init`

Commencez par configurer un projet afin de vous entraîner à gérer les modules. Dans votre shell, créez un nouveau dossier appelé locator :

Entrez ensuite dans le nouveau dossier :

Maintenant, initialisez l’invite interactive en entrant :

Remarque : si votre code doit utiliser Git pour le contrôle de version, créez d’abord le référentiel Git, puis exécutez npm init. La commande comprend automatiquement qu’elle se trouve dans un dossier compatible avec Git. Si un référentiel distant Git est défini, il remplit automatiquement les champs repository, bugs et homepage de votre fichier package.json. Si vous avez initialisé le référentiel après avoir créé le fichier package.json, vous devrez ajouter ces informations vous-même. Pour en savoir plus sur le contrôle de version de Git, consultez notre Introduction à Git : installation, utilisation et branches.

Vous recevrez le résultat suivant :

OutputThis utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help json` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (locator)

Vous serez d’abord invité à indiquer la valeur name (nom) de votre nouveau projet. Par défaut, la commande suppose qu’il s’agit du nom du dossier dans lequel vous vous trouvez. Les valeurs par défaut de chaque propriété sont indiquées entre parenthèses (). Puisque la valeur par défaut pour name fonctionnera pour ce tutoriel, appuyez sur ENTER (ENTRÉE) pour l’accepter.

La prochaine valeur à saisir est version. Tout comme name, ce champ est obligatoire si votre projet doit être partagé avec d’autres dans le dépôt de paquets npm.

Remarque : les paquets Node.js doivent suivre le guide de Semantic Versioning (semver). Par conséquent, le premier chiffre sera le numéro de version MAJOR qui ne change que lorsque l’API change. Le deuxième chiffre sera la version MINOR qui change lorsque des fonctionnalités sont ajoutées. Le dernier chiffre sera la version PATCH qui change lorsque les bugs sont corrigés.

Appuyez sur ENTER, de sorte que la version par défaut est acceptée.

Le champ suivant est description, une chaîne utile pour expliquer ce que fait votre module Node.js. Notre projet locator fictif permettrait d’obtenir l’adresse IP de l’utilisateur et de renvoyer le pays d’origine. Finds the country of origin of the incoming request (Détermine le pays d’origine de la requête entrante) serait une description appropriée, saisissez donc un texte de ce type et appuyez sur ENTER. La description est très utile lorsque les gens recherchent votre module.

L’invite suivante vous demandera la valeur du point d’entrée entry point. Si quelqu’un installe et requires (exige) votre module, ce que vous définissez dans entry point sera la première partie de votre programme qui sera chargée. La valeur doit être l’emplacement relatif d’un fichier JavaScript, et sera ajoutée à la propriété main du package.json. Appuyez sur ENTER pour conserver la valeur par défaut.

Remarque : la plupart des modules ont un fichier index.js comme point d’entrée principal. C’est la valeur par défaut pour la propriété main d’un package.json, qui est le point d’entrée pour les modules npm. S’il n’y a pas de package.json, Node.js essaiera de charger index.js par défaut.

Ensuite, il vous sera demandé une test command, un script exécutable ou une commande pour exécuter les tests de votre projet. Dans de nombreux modules populaires de Node.js, les tests sont écrits et exécutés avec Mocha, Jest, Jasmine ou d’autres frameworks de test. Puisque cet article ne couvre pas les tests, laissez cette option vide pour l’instant et appuyez sur ENTER pour continuer.

La commande init demandera alors le référentiel GitHub du projet. Vous n’en utiliserez pas dans cet exemple donc laissez-le également vide.

Après l’invite pour le référentiel, la commande demande des keywords (mots clés). Cette propriété est un tableau de chaînes de caractères contenant des termes utiles que les gens peuvent utiliser pour trouver votre référentiel. Il est préférable d’avoir un petit groupe de mots vraiment pertinents pour votre projet, afin que la recherche puisse être plus ciblée. Inscrivez ces mots clés sous forme de chaîne de caractères, en séparant chaque valeur par une virgule. Pour cet exemple de projet, tapez ip,geo,country (ip,géo,pays) à l’invite. Le package.json final comportera trois éléments dans le tableau keywords.

Le champ suivant dans l’invite est author (auteur). Ceci est utile pour les utilisateurs de votre module qui veulent entrer en contact avec vous. Par exemple, si quelqu’un découvre un exploit dans votre module, il peut l’utiliser pour signaler le problème afin que vous puissiez le résoudre. Le champ author est une chaîne de caractères au format suivant : "Name <Email> (Website)". Par exemple, "Sammy <sammy@your_domain> (https://your_domain)" est un auteur valide. L’adresse e-mail et les données du site Web sont facultatives : un auteur valide peut être un simple nom. Ajoutez vos coordonnées en tant qu’auteur et confirmez avec ENTER.

Enfin, la license (licence) vous sera demandée. Elle détermine les autorisations et les limitations légales pour les utilisateurs de votre module. De nombreux modules Node.js sont open source, donc npm fixe la valeur par défaut à ISC.

À ce stade, vous devez examiner vos options de licence et décider ce qui convient le mieux à votre projet. Pour plus d’informations sur les différents types de licences open source, consultez cette liste de licences dOpen Source Initiative. Si vous ne souhaitez pas fournir de licence pour un référentiel privé, vous pouvez taper UNLICENSED à l’invite. Pour cet échantillon, utilisez la licence ISC par défaut, et appuyez sur ENTER pour terminer ce processus.

La commande init affichera maintenant le fichier package.json qu’elle va créer. Il ressemblera à cela :

Output
About to write to /home/sammy/locator/package.json:

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy <sammy@your_domain> (https://your_domain)",
  "license": "ISC"
}


Is this OK? (yes)

Une fois que les informations correspondent à ce que vous voyez ici, appuyez sur ENTER pour terminer ce processus et créer le fichier package.json. Grâce à ce fichier, vous pouvez conserver une trace des modules que vous installez pour votre projet.

Maintenant que vous avez votre fichier package.json, vous pouvez tester l’installation de modules lors de l’étape suivante.

`Étape 2 – Installation de modules`

Il est courant dans le développement de logiciels d’utiliser des bibliothèques externes pour effectuer des tâches auxiliaires dans les projets. Cela permet au développeur de se concentrer sur la logique commerciale et de créer l’application plus rapidement et plus efficacement.

Par exemple, si notre exemple de module locator doit faire une requête API externe pour obtenir des données géographiques, nous pourrions utiliser une bibliothèque HTTP pour faciliter cette tâche. Comme notre objectif principal est de renvoyer des données géographiques pertinentes à l’utilisateur, nous pourrions installer un paquet qui nous facilite les requêtes HTTP au lieu de réécrire ce code nous-mêmes, une tâche qui dépasse le cadre de notre projet.

Examinons cet exemple. Dans votre application locator, vous utiliserez la bibliothèque axios, qui vous aidera à effectuer des requêtes HTTP. Installez-la en entrant ce qui suit dans votre shell :

Vous commencez cette commande avec npm install, qui va installer le paquet (pour être bref, vous pouvez utiliser npm i). Vous listerez ensuite les paquets que vous voulez installer, séparés par une espace. Dans ce cas, il s’agit d’axios. Enfin, vous terminez la commande avec le paramètre optionnel --save, qui spécifie qu’axios sera sauvegardé comme une dépendance du projet.

Lorsque la bibliothèque sera installée, vous verrez une sortie similaire à ce qui suit :

Output...
+ [email protected]
added 5 packages from 8 contributors and audited 5 packages in 0.764s
found 0 vulnerabilities

Maintenant, ouvrez le fichier package.json, en utilisant l’éditeur de texte de votre choix. Ce tutoriel utilisera nano :

Vous verrez une nouvelle propriété, comme surligné ci-dessous :

locator/package.json

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy sammy@your_domain (https://your_domain)",
  "license": "ISC",
  "dependencies": {
    "axios": "^0.19.0"
  }
}

L’option --save a indiqué à npm de mettre à jour le package.json avec le module et la version qui viennent d’être installés. C’est très bien, car les autres développeurs travaillant sur vos projets peuvent facilement voir quelles sont les dépendances externes nécessaires.

Remarque : vous avez peut-être remarqué le ^ avant le numéro de version pour la dépendance axios. Rappelez-vous que la version sémantique est constituée de trois chiffres : MAJOR, MINOR et PATCH. Le symbole ^ signifie que toute version MINOR ou PATCH supérieure satisferait à cette contrainte de version. Si vous voyez ~ au début d’un numéro de version, alors seules les versions PATCH supérieures satisfont à la contrainte.

Lorsque vous avez terminé d’examiner le fichier package.json, quittez-le.

`Dépendances de développement`

Les paquets qui sont utilisés pour le développement d’un projet mais pas pour le construire ou le faire fonctionner en production sont appelés dépendances de développement. Ces dépendances ne sont pas nécessaires pour que votre module ou application fonctionne en production, mais peuvent être utiles lors de l’écriture du code.

Par exemple, il est courant que les développeurs utilisent des linters pour s’assurer que leur code suit les meilleures pratiques et pour garder un style cohérent. Bien que cela soit utile pour le développement, cela ne fait qu’augmenter la taille du module distribué sans apporter d’avantage tangible lorsqu’il est déployé en production.

Installez un linter comme dépendance de développement pour votre projet. Essayez cela dans votre shell :

npm i [email protected] --save-dev

Dans cette commande, vous avez utilisé l’indicateur --save-dev. Cela permettra d’enregistrer eslint comme une dépendance qui n’est nécessaire que pour le développement. Notez également que vous avez ajouté @6.0.0 à votre nom de dépendance. Lorsque les modules sont mis à jour, ils sont marqués avec une version. Le @ indique à npm de rechercher une balise spécifique du module que vous installez. Sans balise spécifique, npm installe la dernière version marquée. Ouvrez à nouveau package.json :

Cela montrera ce qui suit :

locator/package.json

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy sammy@your_domain (https://your_domain)",
  "license": "ISC",
  "dependencies": {
    "axios": "^0.19.0"
  },
  "devDependencies": {
    "eslint": "^6.0.0"
  }
}

eslint a été enregistré en tant que devDependencies, avec le numéro de version que vous avez indiqué précédemment. Quittez package.json.

`Fichiers générés automatiquement : node_modules et package-lock.json`

Lorsque vous installez un paquet dans un projet Node.js pour la première fois, npm crée automatiquement le dossier node_modules pour stocker les modules nécessaires à votre projet et le fichier package-lock.json que vous avez examiné précédemment.

Vérifiez qu’ils se trouvent dans votre répertoire de travail. Dans votre shell, tapez ls et appuyez sur ENTER. Vous verrez la sortie suivante :

Outputnode_modules    package.json    package-lock.json

Le dossier node_modules contient toutes les dépendances installées pour votre projet. Dans la plupart des cas, vous ne devez pas commiter ce référentiel dans votre référentiel à version contrôlée. Au fur et à mesure que vous installez des dépendances, la taille de ce dossier augmentera rapidement. En outre, le fichier package-lock.json conserve une trace des versions exactes installées de manière plus succincte, de sorte qu’il n’est pas nécessaire d’inclure node_modules.

Alors que le fichier package.json liste les dépendances qui nous indiquent les versions appropriées à installer pour le projet, le fichier package-lock.json garde la trace de toutes les modifications dans package.json ou node_modules et nous indique la version exacte du paquet installé. Vous commitez généralement dans votre référentiel à version contrôlée au lieu de node_modules, car c’est une représentation plus propre de toutes vos dépendances.

`Installation depuis package.json`

Avec vos fichiers package.json et package-lock.json, vous pouvez rapidement mettre en place les mêmes dépendances avant de commencer le développement d’un nouveau projet. Pour le démontrer, remontez d’un niveau dans votre arborescence de répertoires et créez un nouveau dossier nommé cloned_locator au même niveau de répertoire que locator :

cd ..
mkdir cloned_locator

Entrez dans votre nouveau répertoire :

Maintenant, copiez les fichiers package.json et package-lock.json depuis locator vers cloned_locator :

cp ../locator/package.json ../locator/package-lock.json .

Pour installer les modules nécessaires à ce projet, entrez :

npm vérifiera la présence d’un fichier package-lock.json pour installer les modules. Si aucun fichier lock n’est disponible, npm lira le fichier package.json pour déterminer les installations. Il est généralement plus rapide d’installer à partir de package-lock.json, puisque le fichier lock contient la version exacte des modules et de leurs dépendances, ce qui signifie que npm n’a pas besoin de passer du temps à trouver une version appropriée à installer.

Lors du déploiement en production, vous voudrez peut-être ignorer les dépendances de développement. Rappelez-vous que les dépendances de développement sont stockées dans la section devDependencies de package.json, et n’ont aucun impact sur le fonctionnement de votre application. Lorsque vous installez des modules dans le cadre du processus CI/CD pour déployer votre application, omettez les dépendances dev en exécutant :

L’indicateur --production omet la section devDependencies pendant l’installation. Pour l’instant, restez fidèle à votre modèle de développement.

Avant de passer à la section suivante, revenez au dossier locator :

`Installations globales`

Jusqu’à présent, vous avez installé des modules npm pour le projet locator. npm vous permet également d’installer des paquets de façon globale. Cela signifie que le paquet est disponible pour votre utilisateur dans l’ensemble du système, comme toute autre commande shell. Cette capacité est utile pour les nombreux modules Node.js qui sont des outils CLI.

Par exemple, vous pouvez vouloir parler sur votre blog du projet locator sur lequel vous travaillez actuellement. Pour ce faire, vous pouvez utiliser une bibliothèque comme Hexo pour créer et gérer le blog de votre site Web statique. Installez la CLI d’Hexo de façon globale comme ceci :

Pour installer un paquet de façon globale, vous ajoutez l’indicateur -g à la commande.

Remarque : si vous obtenez une erreur de permission en essayant d’installer ce paquet globalement, il est possible que votre système exige des privilèges de super utilisateur pour exécuter la commande. Essayez à nouveau avec sudo npm i hexo-cli -g.

Vérifiez que le paquet a été installé avec succès en entrant :

Vous verrez une sortie semblable à :

Outputhexo-cli: 2.0.0
os: Linux 4.15.0-64-generic linux x64
http_parser: 2.7.1
node: 10.14.0
v8: 7.6.303.29-node.16
uv: 1.31.0
zlib: 1.2.11
ares: 1.15.0
modules: 72
nghttp2: 1.39.2
openssl: 1.1.1c
brotli: 1.0.7
napi: 4
llhttp: 1.1.4
icu: 64.2
unicode: 12.1
cldr: 35.1
tz: 2019a

Jusqu’à présent, vous avez appris à installer des modules avec npm. Vous pouvez installer des paquets pour un projet localement, soit comme dépendance de production, soit comme dépendance de développement. Vous pouvez également installer des paquets basés sur des fichiers package.json ou package-lock.json préexistants, ce qui vous permet de développer avec les mêmes dépendances que vos pairs. Enfin, vous pouvez utiliser l’indicateur -g pour installer des paquets de façon globale, de sorte que vous puissiez y accéder que vous soyez dans un projet Node.js ou non.

Maintenant que vous pouvez installer des modules, dans la section suivante vous apprendrez des techniques pour administrer vos dépendances.

`Étape 3 – Gestion de modules`

Un gestionnaire de paquets complet peut faire beaucoup plus qu’installer des modules. npm dispose de plus de 20 commandes relatives à la gestion des dépendances. Au cours de cette étape, vous allez :

Lister les modules que vous avez installés.
Mettre à jour des modules vers une version plus récente.
Désinstaller les modules dont vous n’avez plus besoin.
Effectuer un audit de sécurité sur vos modules pour trouver et corriger les failles de sécurité.

Ces exemples seront réalisés dans votre dossier locator, mais toutes ces commandes peuvent être exécutées globalement en ajoutant l’indicateur -g à la fin de celles-ci, exactement comme vous l’avez fait lors de l’installation globale.

`Lister les modules`

Si vous souhaitez savoir quels modules sont installés dans un projet, il est plus facile d’utiliser la commande list ou ls que de lire directement le fichier package.json. Pour ce faire, entrez :

Vous verrez un résultat comme celui-ci :

Output
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └─┬ [email protected]
│ │   └── [email protected]
│ └── [email protected]
└─┬ [email protected]
  ├─┬ @babel/[email protected]
  │ └─┬ @babel/[email protected]
  │   ├── [email protected] deduped
  │   ├── [email protected] deduped
  │   └── [email protected]
  ├─┬ [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ └─┬ [email protected]
...

Par défaut, ls montre l’arbre des dépendances dans son intégralité – les modules dont dépend votre projet et les modules dont dépendent vos dépendances. Cela peut être un peu compliqué si vous voulez avoir une vue d’ensemble de ce qui est installé.

Pour n’imprimer que les modules que vous avez installés sans leurs dépendances, entrez ce qui suit dans votre shell :

Votre sortie sera :

Output
├── [email protected]
└── [email protected]

L’option --depth (profondeur) vous permet de spécifier le niveau d’arborescence des dépendances que vous souhaitez voir. Quand elle est définie sur 0, vous ne voyez que vos dépendances de haut niveau.

`Mettre à jour les modules`

Tenir vos modules npm à jour est une bonne pratique. Vous avez ainsi plus de chances d’obtenir les dernières corrections de sécurité pour un module. Utilisez la commande outdated pour vérifier si des modules peuvent être mis à jour :

Vous obtiendrez une sortie semblable à la suivante :

OutputPackage  Current  Wanted  Latest  Location
eslint     6.0.0   6.7.1   6.7.1  locator

Cette commande liste d’abord le Package qui est installé et la version Current (actuelle). La colonne Wanted indique quelle version satisfait à votre exigence de version dans package.json. La colonne Latest indique la version la plus récente du module qui a été publiée.

La colonne Location indique où se trouve le paquet dans l’arborescence des dépendances. La commande outdated a l’indicateur--depth comme ls. Par défaut, la profondeur est 0.

Il semble que vous puissiez mettre à jour eslint vers une version plus récente. Utilisez la commande update ou up comme ceci :

La sortie de la commande contiendra la version installée :

Output
npm WARN [email protected] No repository field.

+ eslint@6.7.1
added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s
found 0 vulnerabilities

Si vous voulez mettre à jour tous les modules en une seule fois, vous pouvez entrer :

`Désinstaller les modules`

La commande npm uninstall peut supprimer des modules de vos projets. Cela signifie que le module ne sera plus installé dans le dossier node_modules, ni ne sera vu dans vos fichiers package.json et package-lock.json.

Supprimer les dépendances d’un projet est une activité normale dans le cycle de vie du développement de logiciels. Une dépendance peut ne pas résoudre le problème comme annoncé, ou ne pas fournir une expérience de développement satisfaisante. Dans ce cas, il peut être préférable de désinstaller la dépendance et de construire son propre module.

Imaginez qu’axios ne vous apporte pas l’expérience de développement que vous auriez souhaitée pour faire des requêtes HTTP. Désinstallez axios avec la commande uninstall ou un en entrant :

Votre sortie sera semblable à :

Output
npm WARN [email protected] No repository field.

removed 5 packages and audited 176 packages in 1.488s
found 0 vulnerabilities

Il n’est pas dit explicitement qu’axios a été supprimé. Pour vérifier qu’il a été désinstallé, listez à nouveau les dépendances :

Maintenant, nous voyons seulement qu’eslint est installé :

Output
└── eslint@6.7.1

Cela montre que vous avez réussi à désinstaller le paquet axios.

`Auditer des modules`

npm fournit une commande audit pour mettre en évidence les risques de sécurité potentiels dans vos dépendances. Pour voir l’audit en action, installez une version obsolète du module request en exécutant ce qui suit :

Lorsque vous installerez cette version obsolète de request, vous remarquerez une sortie semblable à ce qui suit :

Output
+ [email protected]
added 54 packages from 49 contributors and audited 243 packages in 7.26s
found 6 moderate severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details

npm vous dit que vos dépendances ont des vulnérabilités. Pour obtenir plus de détails, vérifiez l’ensemble de votre projet avec :

La commande audit affiche des tableaux de sortie mettant en évidence les failles de sécurité :

Output                       === npm audit security report ===

# Run  npm install [email protected]  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Memory Exposure                                              │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tunnel-agent                                                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ request > tunnel-agent                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/598                             │
└───────────────┴──────────────────────────────────────────────────────────────┘

# Run  npm update request --depth 1  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Remote Memory Exposure                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/309                             │
└───────────────┴──────────────────────────────────────────────────────────────┘
...

Vous pouvez voir le chemin de la vulnérabilité, et parfois npm vous offre des moyens de la corriger. Vous pouvez exécuter la commande update comme suggéré, ou vous pouvez exécuter la sous-commande fix de audit. Dans votre shell, entrez :

Vous verrez une sortie semblable à :

Output
+ [email protected]
added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s
fixed 2 of 6 vulnerabilities in 243 scanned packages
  4 vulnerabilities required manual review and could not be updated

npm a été en mesure de mettre à jour deux des paquets en toute sécurité, réduisant ainsi vos vulnérabilités dans les mêmes mesures. Cependant, vos dépendances présentent encore quatre vulnérabilités. La commande audit fix ne résout pas toujours tous les problèmes. Bien qu’une version d’un module puisse présenter une faille de sécurité, si vous la mettez à jour vers une version avec une API différente, elle pourrait casser le code plus haut dans l’arbre des dépendances.

Vous pouvez utiliser le paramètre --force pour vous assurer que les vulnérabilités ont disparu, comme ceci :

Comme nous l’avons déjà mentionné, cela n’est pas recommandé, sauf si vous êtes sûr que cela ne brisera pas la fonctionnalité.

`Conclusion`

Dans ce tutoriel, vous avez réalisé divers exercices pour démontrer comment les modules de Node.js sont organisés en paquets, et comment ces paquets sont gérés par npm. Au sein d’un projet Node.js, vous avez utilisé des paquets npm comme dépendances en créant et en maintenant un fichier package.json – un enregistrement des métadonnées de votre projet, y compris les modules que vous avez installés. Vous avez également utilisé l’outil CLI de npm pour installer, mettre à jour et supprimer des modules, en plus de répertorier l’arborescence des dépendances de vos projets et de vérifier et mettre à jour les modules obsolètes.

À l’avenir, l’exploitation du code existant en utilisant des modules accélérera le temps de développement, car vous n’aurez pas à répéter les fonctionnalités. Vous serez également en mesure de créer vos propres modules npm, et ceux-ci seront à leur tour gérés par d’autres via des commandes npm. Quant aux prochaines étapes, expérimentez ce que vous avez appris dans ce tutoriel en installant et en testant toute la gamme des paquets disponibles. Voyez ce que l’écosystème fournit pour faciliter la résolution des problèmes. Par exemple, vous pouvez essayer TypeScript, un superset de JavaScript, ou transformer votre site Web en applications mobiles avec Cordova. Si vous souhaitez en savoir plus sur Node.js, consultez nos autres tutoriels Node.js.

Source link

`Cómo usar módulos Node.js con npm y package.json`

hassan latif
blog

El autor seleccionó a Open Internet/Free Speech Fund para recibir una donación como parte del programa Write for DOnations.

`Introducción`

Debido a características como su rápido rendimiento de entrada y salida (E/S) y su sintaxis de JavaScript conocida, Node.js se convirtió velozmente en un entorno en tiempo de ejecución popular para desarrollo web de backend. Sin ambargo, a medida que crece el interés, se crean aplicaciones más grandes y se hace más difícil gestionar la complejidad de la base de código y sus dependencias. Node.js organiza esta complejidad usando módulos, que son archivos de JavaScript cualesquiera que contengan funciones u objetos que otros programas o módulos puedan usar. Las colecciones de uno o más módulos suelen citarse como paquetes y los administradores de paquetes los organizan.

El administrador de paquetes de Node.js (npm) es el administrador de paquetes predeterminado y más popular del ecosistema de Node.js, y se utiliza principalmente para instalar y administrar módulos externos de proyectos de Node.js. También se suele utilizar para instalar una amplia variedad de herramientas de CLI y ejecutar secuencias de comandos de proyectos. npm realiza un seguimiento de los módulos instalados en un proyecto con el archivo package.json, que reside en el directorio de un proyecto y contiene lo siguiente:

Todos los módulos necesarios para un proyecto y sus versiones instaladas
Todos los metadatos de un proyecto, como el autor y la licencia, entre otros
Secuencias de comandos que se pueden ejecutar para automatizar tareas del proyecto

Al crear proyectos más complejos de Node.js, administrar sus metadatos y dependencias con el archivo package.json, proporcionará compilaciones más previsibles, ya que todas las dependencias externas se mantienen iguales. El archivo hará un seguimiento de esta información de forma automática; si bien puede cambiar el archivo directamente para actualizar los metadatos de su proyecto, rara vez deberá interactuar con él directamente para administrar módulos.

A través de este tutorial, gestionará paquetes con npm. El primer paso será crear y comprender el archivo package.json. Luego, lo usará para realizar un seguimiento de todos los módulos que instale en su proyecto. Por último, enumerará las dependencias de sus paquetes, los actualizará, los desinstalará y realizará una auditoría para detectar errores de seguridad en ellos.

`Requisitos previos`

Para completar este tutorial, necesitará lo siguiente:

`Paso 1: Crear un archivo package.json`

El primer paso de este tutorial es establecer el proyecto de ejemplo: un módulo locator ficticio de Node.js que obtiene la dirección IP del usuario y muestra el país de origen. En este tutorial, no codificará el módulo. Sin embargo, los paquetes que administre serían pertinentes si lo desarrollara.

Primero, creará un archivo package.json para almacenar los metadatos útiles sobre el proyecto y como ayuda para administrar los módulos de Node.js dependientes del proyecto. Como sugiere el sufijo, este es un archivo JSON (notación de objetos JavaScript). JSON es un formato estándar que se utiliza para compartir, basado en objetos de JavaScript, y consta de datos almacenados como pares clave-valor. Si desea obtener más información sobre JSON, consulte nuestro artículo Introducción a JSON.

Debido a que un archivo package.json contiene numerosas propiedades, puede ser engorroso crearlo manualmente, sin copiar ni pegar una plantilla desde otro sitio. Para facilitar las cosas, npm proporciona el comando init. Se trata de un comando interactivo que le formula una serie de preguntas y crea un archivo package.json basado en sus respuestas.

`Usar el comando init`

Primero, configure un proyecto para poder poner en práctica la administración de módulos. En su shell, cree una nueva carpeta llamada locator:

Luego, posiciónese en la nueva carpeta:

Ahora, inicie el comando interactivo ingresando lo siguiente:

Nota: Si en su código se usará Git para el control de versiones, cree el repositorio de Git primero y luego ejecute npm init. El comando entiende de forma automática que se encuentra en una carpeta habilitada para Git. Si se configura un Git remoto, completa de forma automática el repositorio, los errores y los campos de la página de inicio de su archivo package.json. Si inicializó el repositorio después de crear el archivo package.json, deberá añadir esta información de forma manual. Para obtener más información sobre el control de versiones de Git, consulte nuestra serie Git: Instalación, uso y ramificaciones.

Recibirá el siguiente resultado:

OutputThis utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help json` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (locator)

Primero, se le solicitará el valor de name de su nuevo proyecto. Por defecto, el comando prevé que es el nombre de la carpeta en la que usted se encuentra. Los valores predeterminados de cada propiedad se muestran entre paréntesis (). Debido a que el valor predeterminado de name funciona para este tutorial, presione ENTER para aceptarlo.

El siguiente valor que se debe introducir es version. Junto con name, este campo se requiere si su proyecto se compartirá con otros en el repositorio de paquetes npm.

Nota: Se espera que los paquetes de Node.js sigan la guía de Versionamiento semántico (semver). Por lo tanto, el primer número será el de versión MAJOR, que solo cambia cuando se modifica la API. El segundo número será el de versión MINOR, que cambia cuando se añaden funciones. El último número será el de versión de PATCH, que cambia cuando se solucionan errores.

Pulse INTRO para aceptar la versión predeterminada.

El siguiente campo es description: una cadena útil para explicar lo que hace su módulo de Node.js. Nuestro proyecto ficticio locator obtendría la dirección IP del usuario y mostraría el país de origen. Un campo description adecuado sería Finds the country of origin of the incoming request; por lo tanto, ingrese algo similar y presione INTRO. El campo description es muy útil cuando las personas buscan su módulo.

En la siguiente solicitud se pedirá el entry point. Si alguien instala y usa requires para su módulo, lo que configure en entry point será lo primero que se cargará de su programa. El valor debe ser la ubicación relativa de un archivo de JavaScript, y se añadirá a la propiedad main de package.json. Pulse INTRO para conservar el valor predeterminado.

Nota: La mayoría de los módulos tienen un archivo index.js como punto de entrada principal. Este es el valor predeterminado de la propiedad main de un package.json, que es el punto de entrada para los módulos npm. Si no encuentra package.json, Node.js intentará cargar index.js por defecto.

A continuación, se le solicitará un test command, una secuencia de comandos ejecutable o un comando para ejecutar las pruebas de su proyecto. En muchos módulos populares de Node.js, las pruebas se escriben y ejecutan con Mocha, Jest, Jasmine u otros marcos de pruebas. Dado que las pruebas se encuentran fuera del alcance de este artículo, por ahora deje esta opción vacía y presione INTRO para continuar.

Luego, el comando init solicitará el repositorio GitHub del proyecto. En este ejemplo, no lo usará. Por lo tanto, déjelo vacío también.

Después del repositorio, el comando solicita keywords. Esta propiedad es una serie de cadenas con términos útiles que las personas pueden usar para encontrar su repositorio. Se recomienda tener un pequeño conjunto de palabras claves realmente relevantes para su proyecto, a fin de direccionar más la búsqueda. Enumere estas palabras claves como cadena, separando cada valor con una coma. Para este proyecto de ejemplo, ingrese ip,geo,country cuando se le solicite. El package.json terminado tendrá tres elementos en la matriz de keywords.

El siguiente campo de la solicitud es author. Es útil para los usuarios de su módulo que quieran ponerse en contacto con usted. Por ejemplo, si alguien descubre una vulnerabilidad de seguridad en su módulo, puede usarlo para indicarle el problema, a fin de que pueda solucionarlo. El campo author es una cadena que tiene el siguiente formato: "Name <Email> (Website)". Por ejemplo, “Sammy <sammy@your_domain> (https://your_domain)" es un autor válido. Los datos de correo electrónico y sitio web son optativos: un autor válido puede ser, simplemente, un nombre. Añada sus datos de contacto como autor y confírmelos con INTRO.

Por último, se le solicitará indicar la license. Con esto, se determinan los permisos legales y las limitaciones que los usuarios tendrán al usar su módulo. Muchos módulos de Node.js son de código abierto. Por lo tanto, npm establece ISC como valor predeterminado.

En este punto, revisaría sus opciones de concesión de licencias y decidirá lo mejor para su proyecto. Para obtener más información sobre los diferentes tipos de licencias de código abierto, consulte esta lista de licencias de la Open Source Initiative. Si no desea proporcionar una licencia para un repositorio privado, puede escribir UNLICENSED en la solicitud. Para este ejemplo, utilice la licencia ISC predeterminada y presione INTRO para terminar este proceso.

El comando init ahora mostrará el archivo package.json que creará. Tendrá un aspecto similar a este:

Output
About to write to /home/sammy/locator/package.json:

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy <sammy@your_domain> (https://your_domain)",
  "license": "ISC"
}


Is this OK? (yes)

Una vez que la información coincida con lo que ve aquí, presione INTRO para completar el proceso y crear el archivo package.json. Con este archivo, puede llevar un registro de los módulos que instale para su proyecto.

Ahora que tiene su archivo package.json, puede probar la instalación de módulos en el siguiente paso.

`Paso 2: Instalar módulos`

En el desarrollo de software, es habitual usar bibliotecas externas para realizar tareas auxiliares en los proyectos. Esto permite que el desarrollador se centre en la lógica empresarial y cree la aplicación de forma más rápida y eficiente.

Por ejemplo, si el módulo locator de nuestro ejemplo tuviera que hacer una solicitud de API externa para obtener datos geográficos, podríamos usar una biblioteca HTTP para facilitar esa tarea. Debido a que nuestro objetivo principal es devolver al usuario datos geográficos pertinentes, podríamos instalar un paquete que nos facilite las solicitudes HTTP en lugar de tener que volver a escribir este código nosotros mismos, una tarea que va más allá del alcance de nuestro proyecto.

Veamos este ejemplo. En su aplicación locator, usará la biblioteca axios, que lo ayudará a realizar solicitudes HTTP. Instálela ingresando lo siguiente en su shell:

Este comando se inicia con npm install, que instalará el paquete (para abreviar, puede usar npm i). Luego, enumere los paquetes que desea instalar, separados por un espacio. En este caso, es axios. Por último, finalice el comando con el parámetro opcional --save, que especifica que axios se guardará como dependencia del proyecto.

Cuando se instale la biblioteca, verá un resultado similar al siguiente:

Output...
+ [email protected]
added 5 packages from 8 contributors and audited 5 packages in 0.764s
found 0 vulnerabilities

Ahora, abra el archivo package.json con el editor de texto que prefiera. En este tutorial, se usará nano:

Verá una nueva propiedad, resaltada en lo siguiente:

locator/package.json

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy sammy@your_domain (https://your_domain)",
  "license": "ISC",
  "dependencies": {
    "axios": "^0.19.0"
  }
}

La opción --save indicó a npm que actualizara package.json con el módulo y la versión que se acaba de instalar. Esto es muy positivo, ya que otros desarrolladores que trabajen en sus proyectos podrán ver fácilmente las dependencias externas necesarias.

Nota: Seguramente haya observado el ^ antes del número de versión de la dependencia axios. Recuerde que el control de versiones semántico consta de tres dígitos: MAJOR, MINOR y PATCH. El símbolo ^ indica que cualquier versión MINOR o PATCH superior cumpliría con esta restricción de versión. Si ve ~ al comienzo de un número de versión, solo las versiones PATCH superiores satisfacen la restricción.

Cuando termine de revisar package.json, cierre el archivo.

`Dependencias de desarrollo`

Los paquetes que se utilizan para desarrollar proyectos, pero no para crearlos o ejecutarlos en producción, se conocen como dependencias de desarrollo. No son necesarios para que su módulo o aplicación funcionen en producción, pero pueden ser útiles al escribir el código.

Por ejemplo, es común que los desarrolladores utilicen linters de código para asegurarse de que su código siga las prácticas recomendadas y mantener un estilo uniforme. Si bien esto es útil para el desarrollo, solo aumenta el tamaño del código que puede distribuirse y no proporciona un beneficio tangible cuando se implementa en producción.

Instale un linter como dependencia de desarrollo para su proyecto. Pruebe esto en su shell:

npm i [email protected] --save-dev

En este comando, utilizó el indicador --save-dev. Este indicador guardará eslint como una dependencia que solo se requiere para el desarrollo. Tenga en cuenta, también, que añadió @6.0.0 al nombre de su dependencia. Cuando los módulos se actualizan, se etiquetan con una versión. La @ indica a npm que busque una etiqueta específica del módulo que está instalando. Si no se especifica una etiqueta, npm instala la última versión etiquetada. Vuelva a abrir package.json:

Con esto, se mostrará lo siguiente:

locator/package.json

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy sammy@your_domain (https://your_domain)",
  "license": "ISC",
  "dependencies": {
    "axios": "^0.19.0"
  },
  "devDependencies": {
    "eslint": "^6.0.0"
  }
}

eslint se guardó como devDependencies, junto con el número de versión que especificó anteriormente. Cierre package.json.

`Archivos generados de forma automática: node_modules y package-lock.json`

La primera vez que se instala un paquete en un proyecto de Node.js, npm crea la carpeta node_modules para almacenar los módulos necesarios para su proyecto y el archivo package-lock.json que examinó antes.

Confirme que estén presentes en su directorio de trabajo. En su shell, escriba ls y presione INTRO. Verá el siguiente resultado:

Outputnode_modules    package.json    package-lock.json

La carpeta node_modules contiene todas las dependencias instaladas de su proyecto. En la mayoría de los casos, no debe confirmar esta carpeta en su repositorio de versiones controladas. A medida que instale más dependencias, el tamaño de esta carpeta aumentará rápidamente. Además, el archivo package-lock.json lleva un registro de las versiones exactas instaladas de forma más concisa. Por lo tanto, no es necesario incluir node_modules.

Si bien el archivo package.json enumera dependencias que indican las versiones adecuadas que se deben instalar en el proyecto, el archivo package-lock.json hace un seguimiento de todos los cambios que se realizan en package.json o node_modules y nos indica la versión exacta del paquete instalado. En general, confirma esto en su repositorio de versiones controladas, en lugar de node_modules, dado que es una representación más clara de todas sus dependencias.

`Realizar la instalación desde package.json`

Con sus archivos package.json y package-lock.json, puede configurar rápidamente las mismas dependencias del proyecto antes de comenzar a desarrollar uno nuevo. Para demostrarlo, suba un nivel en su árbol de directorios y cree una nueva carpeta denominada cloned_locator en el mismo nivel de directorio de locator:

cd ..
mkdir cloned_locator

Posiciónese en su nuevo directorio:

Ahora, copie los archivos package.json y package-lock.json de locator a cloned_locator:

cp ../locator/package.json ../locator/package-lock.json .

Para instalar los módulos requeridos para este proyecto, escriba lo siguiente:

npm buscará un archivo package-lock.json para instalar los módulos. Si no hubiera ningún archivo de bloqueo disponible, leería el archivo package.json para determinar las instalaciones. En general, la instalación se puede realizar de manera más rápida desde package-lock.json, ya que el archivo de bloqueo contiene la versión exacta de los módulos y sus dependencias, lo cual significa que npm no tiene que invertir tiempo en determinar una versión adecuada para la instalación.

Al momento de la implementación en producción, tal vez prefiera omitir las dependencias de desarrollo. Recuerde que las dependencias de desarrollo se almacenan en la sección devDependencies de package.json y que no afectan el funcionamiento de su aplicación. Al instalar módulos como parte del proceso de CI y CD para implementar su aplicación, omita las dependencias de desarrollo ejecutando lo siguiente:

El indicador --production ignora la sección devDependencies durante la instalación. Por ahora, siga adelante con su compilación de desarrollo.

Antes de pasar a la siguiente sección, regrese a la carpeta locator:

`Instalaciones globales`

Hasta ahora, instaló módulos npm para el proyecto locator. npm también le permite instalar paquetes de forma global. Esto significa que el paquete está disponible para su usuario en el sistema más amplio, como cualquier otro comando shell. Esta capacidad es útil para muchos módulos de Node.js que son herramientas de CLI.

Por ejemplo, tal vez desee hacer un blog sobre el proyecto locator en el que trabaja actualmente. Para hacerlo, puede usar una biblioteca como Hexo para crear y administrar su blog de sitio web estático. Instale la CLI de Hexo de forma global, como se indica a continuación:

Para instalar un paquete de forma global, anexe el indicador -g al comando.

Nota: Si observa un error de permiso al intentar instalar este paquete de forma global, es posible que su sistema requiera privilegios de superusuario para ejecutar el comando. Vuelva a probar con sudo npm i hexo-cli -g.

Pruebe que el paquete se haya instalado de forma correcta escribiendo lo siguiente:

Verá un resultado similar a este:

Outputhexo-cli: 2.0.0
os: Linux 4.15.0-64-generic linux x64
http_parser: 2.7.1
node: 10.14.0
v8: 7.6.303.29-node.16
uv: 1.31.0
zlib: 1.2.11
ares: 1.15.0
modules: 72
nghttp2: 1.39.2
openssl: 1.1.1c
brotli: 1.0.7
napi: 4
llhttp: 1.1.4
icu: 64.2
unicode: 12.1
cldr: 35.1
tz: 2019a

Hasta ahora, aprendió a instalar módulos con npm. Puede instalar paquetes en un proyecto de forma local, ya sea como dependencia de producción o de desarrollo. También puede instalar paquetes basados en archivos package.json o package-lock.json preexistentes, lo que le permite realizar desarrollos con las mismas dependencias que sus pares. Por último, puede usar el indicador -g para instalar paquetes de forma global, a fin de poder acceder a ellos independientemente de que se encuentre en un proyecto de Node.js o no.

Ahora que puede instalar módulos, en la siguiente sección, practicará técnicas para administrar sus dependencias.

`Paso 3: Administrar módulos`

Un administrador de paquetes completo puede hacer mucho más que instalar módulos. npm tiene más de 20 comandos disponibles relacionados con la administración de dependencias. En este paso, hará lo siguiente:

Enumerará módulos que instaló.
Actualizará módulos a una versión más reciente.
Desinstalará los módulos que ya no necesite.
Ejecutará una auditoría de seguridad en sus módulos para encontrar y solucionar errores de seguridad.

Si bien estos ejemplos se ejecutarán en su carpeta locator, todos estos comandos se pueden ejecutar de forma global añadiéndoles el indicador -g al final, exactamente lo mismo que hizo al realizar la instalación global.

`Enumerar módulos`

Si quisiera saber qué módulos se instalan en un proyecto, sería más fácil usar el comando list o ls en lugar de leer directamente package.json. Para hacerlo, ingrese lo siguiente:

Verá un resultado similar a este:

Output
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └─┬ [email protected]
│ │   └── [email protected]
│ └── [email protected]
└─┬ [email protected]
  ├─┬ @babel/[email protected]
  │ └─┬ @babel/[email protected]
  │   ├── [email protected] deduped
  │   ├── [email protected] deduped
  │   └── [email protected]
  ├─┬ [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ └─┬ [email protected]
...

Por defecto, Is muestra todo el árbol de dependencias: los módulos de los que depende su proyecto y los módulos de los que dependen sus dependencias. Puede ser algo engorroso si desea obtener una descripción general de alto nivel de lo que se instala.

Para imprimir únicamente los módulos que instaló sin sus dependencias, ingrese lo siguiente en su shell:

El resultado será el siguiente:

Output
├── [email protected]
└── [email protected]

La opción --depth le permite especificar el nivel del árbol de dependencias que desea ver. Cuando es 0, solo se ven dependencias de nivel superior.

`Actualizar módulos`

Se le recomienda mantener sus módulos npm actualizados. Al hacerlo, tiene más posibilidades de acceder a las últimas correcciones de seguridad para ellos. Utilice el comando outdated para verificar si hay actualizaciones para alguno de sus módulos:

Obtendrá un resultado similar al siguiente:

OutputPackage  Current  Wanted  Latest  Location
eslint     6.0.0   6.7.1   6.7.1  locator

Con este comando, primero se enumeran el Package (paquete) que está instalado y la versión Current (actual). En la columna Wanted (deseado), se muestra la versión que cumple su requisito de versión en package.json. La columna Latest (última) muestra la versión más reciente del módulo que se publicó.

La columna Location (ubicación) indica dónde se encuentra el paquete en el árbol de dependencias. El comando outdated tiene el indicador --depth como Is. Por defecto, la profundidad es 0.

Parece que puede actualizar eslint a una versión más reciente. Utilice los comandos update o up como se indica a continuación:

El resultado del comando contendrá la versión instalada:

Output
npm WARN [email protected] No repository field.

+ eslint@6.7.1
added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s
found 0 vulnerabilities

Si quisiera actualizar todos los módulos a la vez, debería ingresar lo siguiente:

`Desinstalar módulos`

El comando uninstall de npm se utiliza para eliminar módulos de sus proyectos. Esto significa que el módulo ya no se instalará en la carpeta node_modules ni se verá en sus archivos package.json y package-lock.json.

Eliminar dependencias de un proyecto es una actividad normal del ciclo de vida de desarrollo de software. Es posible que una dependencia no resuelva el problema tal como se anuncia o que no proporcione una experiencia de desarrollo satisfactoria. En estos casos, es mejor que desinstale la dependencia y cree su propio módulo.

Imagine que axios no proporciona la experiencia de desarrollo que hubiera deseado para realizar solicitudes HTTP. Desinstale axios con el comando uninstall o un ingresando lo siguiente:

El resultado será similar a este:

Output
npm WARN [email protected] No repository field.

removed 5 packages and audited 176 packages in 1.488s
found 0 vulnerabilities

No se indica de forma explícita que se eliminó axios. Para verificar que se haya desinstalado, vuelva a enumerar las dependencias una vez más:

Ahora, se ve que solo eslint está instalado:

Output
└── eslint@6.7.1

Esto indica que desinstaló el paquete axios de forma exitosa.

`Auditar módulos`

npm proporciona un comando audit para resaltar posibles riesgos de seguridad de sus dependencias. Para ver la auditoría en acción, instale una versión obsoleta del módulo request ejecutando lo siguiente:

Cuando instale esta versión obsoleta de request, obtendrá un resultado similar al siguiente:

Output
+ [email protected]
added 54 packages from 49 contributors and audited 243 packages in 7.26s
found 6 moderate severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details

npm le indica que hay vulnerabilidades en sus dependencias. Para obtener más información, audite todo el proyecto con lo siguiente:

Con el comando audit se muestran tablas de resultados en las que se resaltan errores de seguridad:

Output                       === npm audit security report ===

# Run  npm install [email protected]  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Memory Exposure                                              │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tunnel-agent                                                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ request > tunnel-agent                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/598                             │
└───────────────┴──────────────────────────────────────────────────────────────┘

# Run  npm update request --depth 1  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Remote Memory Exposure                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/309                             │
└───────────────┴──────────────────────────────────────────────────────────────┘
...

Puede ver la ruta de la vulnerabilidad y, a veces, npm le ofrece formas de corregirla. Puede ejecutar el comando update, como se sugiere, o el subcomando fix de audit. En su shell, ingrese lo siguiente:

Verá un resultado similar a este:

Output
+ [email protected]
added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s
fixed 2 of 6 vulnerabilities in 243 scanned packages
  4 vulnerabilities required manual review and could not be updated

npm pudo actualizar de forma segura dos de los paquetes, lo que redujo sus vulnerabilidades en la misma cantidad. Sin embargo, aún tiene cuatro vulnerabilidades en sus dependencias. El comando audit fix no siempre soluciona todos los problemas. Si bien la versión de un módulo puede tener una vulnerabilidad de seguridad, si lo actualiza a una versión con una API diferente podría desglosar el código en un nivel más alto del árbol de dependencias.

Puede usar el parámetro --force para garantizar que se hayan eliminado las vulnerabilidades, como se indica a continuación:

Como se mencionó anteriormente, esto no se recomienda a menos que esté seguro de que la funcionalidad no se verá afectada.

`Conclusión`

A lo largo de este tutorial, realizó varios ejercicios para demostrar cómo se organizan los módulos de Node.js en paquetes y la forma en que npm los gestiona. En un proyecto de Node.js, utilizó paquetes npm como dependencias creando y manteniendo un archivo package.json: un registro de los metadatos de su proyecto que incluye los módulos que instaló. También utilizó la herramienta CLI de npm para instalar, actualizar y eliminar módulos, así como para enumerar el árbol de dependencias de sus proyectos y verificar y actualizar los módulos obsoletos.

En el futuro, aprovechar el código existente usando módulos acelerará el tiempo de desarrollo, dado que no es necesario que repita funcionalidades. También podrá crear sus propios módulos npm y estos, a su vez, serán gestionados por otros a través de comandos npm. En cuanto a los siguientes pasos, experimente con lo que aprendió en este tutorial instalando y probando los diferentes paquetes disponibles. Vea lo que se ofrece en el ecosistema para facilitar la resolución de problemas. Por ejemplo, puede probar TypeScript, un supraconjunto de JavaScript, o convertir su sitio web en aplicaciones móviles con Cordova. Si desea obtener más información sobre Node.js, consulte nuestros otros tutoriales de Node.js.

Source link

1
2
Next Page »

Shared

Cloud VPS

Dedicated

packagejson

So verwenden Sie Node.js-Module mit npm und package.json

Einführung

Voraussetzungen

Schritt 1 – Erstellen einer package.json-Datei

Verwenden des Befehls init

Schritt 2 – Installieren von Modulen

Entwicklungsabhängigkeiten

Automatisch generierte Dateien: node_modules und package-lock.json

Installieren aus package.json

Globale Installationen

Schritt 3 — Verwalten von Modulen

Module auflisten

Module aktualisieren

Module deinstallieren

Module prüfen

Zusammenfassung

Comment utiliser les modules Node.js avec npm et package.json

Introduction

Conditions préalables

Étape 1 — Création d’un fichier package.json

Utilisation de la commande init

Étape 2 – Installation de modules

Dépendances de développement

Fichiers générés automatiquement : node_modules et package-lock.json

Installation depuis package.json

Installations globales

Étape 3 – Gestion de modules

Lister les modules

Mettre à jour les modules

Désinstaller les modules

Auditer des modules

Conclusion

Cómo usar módulos Node.js con npm y package.json

Introducción

Requisitos previos

Paso 1: Crear un archivo package.json

Usar el comando init

Paso 2: Instalar módulos

Dependencias de desarrollo

Archivos generados de forma automática: node_modules y package-lock.json

Realizar la instalación desde package.json

Instalaciones globales

Paso 3: Administrar módulos

Enumerar módulos

Actualizar módulos

Desinstalar módulos

Auditar módulos

Conclusión

Schritt 1 – Erstellen einer `package.json`-Datei

Verwenden des Befehls `init`

`Schritt 2 – Installieren von Modulen`

`Entwicklungsabhängigkeiten`

`Automatisch generierte Dateien: node_modules und package-lock.json`

`Installieren aus package.json`

`Globale Installationen`

`Schritt 3 — Verwalten von Modulen`

`Module auflisten`

`Module aktualisieren`

`Module deinstallieren`

`Module prüfen`

`Zusammenfassung`

`Comment utiliser les modules Node.js avec npm et package.json`

`Introduction`

`Conditions préalables`

`Étape 1 — Création d’un fichier package.json`

`Utilisation de la commande init`

`Étape 2 – Installation de modules`

`Dépendances de développement`

`Fichiers générés automatiquement : node_modules et package-lock.json`

`Installation depuis package.json`

`Installations globales`

`Étape 3 – Gestion de modules`

`Lister les modules`

`Mettre à jour les modules`

`Désinstaller les modules`

`Auditer des modules`

`Conclusion`

`Cómo usar módulos Node.js con npm y package.json`

`Introducción`

`Requisitos previos`

`Paso 1: Crear un archivo package.json`

`Usar el comando init`

`Paso 2: Instalar módulos`

`Dependencias de desarrollo`

`Archivos generados de forma automática: node_modules y package-lock.json`

`Realizar la instalación desde package.json`

`Instalaciones globales`

`Paso 3: Administrar módulos`

`Enumerar módulos`

`Actualizar módulos`

`Desinstalar módulos`

`Auditar módulos`

`Conclusión`