One place for hosting & domains

      Using npm as a Build Tool

      Introduction

      Every developer will love this saying “It is hard to build software without using a build tool.” To get rid of the repetitive tasks, we are using build tools. If you think Gulp has killed Grunt you may want to think about another tool because npm has surpassed both.

      Now Node provides a great way to implement a build process with only npm.

      Imagine a situation where using build tools makes you horrible, I felt the same thing when I use Grunt and Gulp. Now that I have been using npm as a build tool, I feel more comfortable. Here I will share with you how to do the same and make yourself comfortable while using the build tool.

      At the end of this article, we will be making our own boilerplate.

      When using Grunt or Gulp, the packages specific to that build tool are usually just wrappers on the main package. For instance, gulp-sass is really a Gulp-specific wrapper to node-sass. We can go straight to the source and just use node-sass with npm!

      There are drawbacks to using Grunt/Gulp-specific packages.

      1. We need to watch the versions of each sub-module which we are using. If anything gets updated or removed we have to look for another one to achieve the same. But here with npm, no such problem will come.
      2. Adding new tasks into the build tool will increase dependencies. But here we can use command prompt commands like && to combine multiple tasks.
      3. Custom script file (like Gruntfile.js) for tasks. Here only package.json file is enough.
      4. Doesn’t support any commands which we use in the command prompt. Here you can use all commands in your package.json file.
      1. Default scripts
      2. Custom scripts

      Let’s start our build commands!

      1. Create an empty directory and initialize it as npm using npm init. It will ask you to construct your package.json file. If you feel lazy like me to hit enter many times, then go with shorthand script npm init --yes.

      2. Now check your directory, a package.json file gets created like this:

      {
        "name": "your_directory_name",
        "version": "1.0.0",
        "description": "",
        "main": "index.js",
        "scripts": {
          "test": "echo \"Error: no test specified\" && exit 1"
        },
        "keywords": [],
        "author": "",
        "license": "ISC"
      }
      
      1. By default, a test script will get created inside the script object. Inside the script object, we are going to configure our tasks.

      2. Run the default task using npm test shorthand for npm run test:

      terminal

      It states that node_modules missing. We have to add our dependencies.

      1. Let’s install dev dependencies first:
      1. npm i -D jshint lite-server mocha concurrently node-sass uglify-js
      1. Let’s start creating our scripts:
      "scripts": {
        ...
        "dev": "lite-server"
      }
      

      npm run dev – I have used it as a development server. lite-server will take provide browser-sync for live-reloading. We don’t need to configure a watch property for all your files like (HTML, CSS, JS).

      To know more about lite-server refer docs.

        "scripts": {
          ...
          "db": "json-server --watch db.json --port 3005"
        }
      

      npm run db – If you want to know more about JSON-Server refer my article.

        "scripts": {
          ...
          "start": "concurrently -k \"npm run dev\" \"npm run db\""
        }
      

      npm start shorthand for npm run start. Concurrently, using it we can perform two tasks simultaneously. You can also combine both the tasks using && operator. To know more about it refer docs.

        "scripts": {
         ...
         "uglify": "mkdir -p dist/js && uglifyjs src/js/*.js -m -o dist/js/app.js"
        }
      

      npm run uglify – It will minify your JavaScript files and move them into your desired directory. It will create a new folder only if it does not already exist (-p flag).

        "scripts": {
          ...
          "lint": "jshint src/**.js"
        }
      

      npm run lint – It will look for any JavaScript files inside the source folder and helps detect errors and potential problems in your JavaScript code.

      "scripts": {
        ...
        "sass": "node-sass --include-path scss scss/main.scss assets/main.css"
      }
      

      npm run sass – It allows compiling your .scss files to CSS automatically and at a good speed.

      "scripts": {
        ...
        "test": "mocha test"
      }
      

      npm test shorthand for npm run test. Mocha is a JavaScript test framework, which helps you to write test cases.

      "scripts": {
        ...
        "bash": "Location of the Bash/Shell script file"
      }
      

      npm run bash – If you think you’re making a lot of commands inside the scripts object, you can make it as Bash/Shell script and include it in your package.json file as above.

      So far we have seen the basic npm build commands and explanations for them. Let’s start to prepare our own boilerplate. Using this boilerplate will save your time in preparing the build tool. Allowing you to invest more time in building your app.

      "scripts": {
      
        "start": "concurrently -k \"npm run dev\" \"npm run watch-css\"",
      
        "dev": "lite-server",
        "db": "json-server --watch db.json --port 3005",
      
        "build-js": "mkdir -p dist/js && uglifyjs src/js/*.js -m -o dist/js/app.js",
      
        "lint": "lint jshint src/**/**.js",
      
        "build-css": "node-sass --include-path scss scss/main.scss assets/main.css",
        "watch-css": "nodemon -e scss -x \"npm run build-css\"",
      
        "test": "mocha test",
        "pretest": "npm run lint",
        "posttest": "echo the test has been run!",
      
        "bash": "Location of the bash/shell script file"
      }
      

      This boilerplate will take care of all the necessary things which we need during the development phase like:

      1. npm run dev– Bootstraps our app, opens it in the browser, reloads the browser whenever we make changes in the source.

      2. build-js– Minifies all our JavaScript files, which will be needed during production.

      3. watch-css– Nodemon is a utility that will monitor for any changes in your source and automatically restart your server. Here I have used it to monitor for any changes in the .scss file, if there are changes, it will restart the server and build our CSS.

      "scripts": {
        "test": "echo I am test",
        "pretest": "echo I run before test",
        "posttest": "echo I run after test"
      }
      
      1. npm test– It wraps the above three commands “pretest test posttest” and executes them in the order I have listed. Initially when you hit npm test it will look for pretest command. If it is there, it gets executed first, followed by test and then posttest. During the lookup, if it doesn’t find the pretest command it will directly execute the test command.

      The remaining commands I have explained in the previous section. You can also customize this boilerplate based on your needs.

      I hope this article has saved your time while preparing a build tool. Now we have prepared our own boilerplate for npm as a build tool. I hope now you will accept npm has killed both Grunt and Gulp. Feel free to use my boilerplate and contributions are welcome. Further, you can refer to the official npm scripts.

      If you have any queries, please let me know in the comments.

      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:

      Output

      This 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:

      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:

      Output

      node_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:

      Output

      hexo-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:

      Output

      Package 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


      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 :

      Output

      This 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 :

      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 :

      Output

      node_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 à :

      Output

      hexo-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 :

      Output

      Package 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