Solltest du den Ordner node_modules an Git übergeben?

Das JavaScript Full-Stack Bootcamp 2021 ist JETZT FÜR ANMELDUNGEN OFFEN!

Solltest du den Ordner node_modules an Git übergeben?

Ich erwähne Git, aber das Gleiche gilt für jedes Versionskontrollsystem, das du zufällig benutzt

Das ist eine gute Frage. Es gibt Vor- und Nachteile.

Ich schlage vor, den Ordner node_modules nicht zu committen und ihn stattdessen zu deiner .gitignore Datei hinzuzufügen.

Du könntest spezielle Bedürfnisse haben, die diese Entscheidung rückgängig machen.

Ich diskutiere das Thema, damit du dir deine eigene Meinung bilden kannst.

Hier sind einige Argumente, die dafür sprechen, node_modules nicht zu committen

Du hältst deine Git Geschichte sauber. Wenn du ein neues Paket hinzufügst, speicherst du die package.json– und package-lock.json-Datei-Änderungen. Wenn du dich entscheidest, die Paketversion zu aktualisieren, speicherst du nur die package-lock.json-Datei-Änderung.

package-lock.jsonist eine relativ neue Funktion von npm, die den früher verwendeten Shrinkwrap-Befehl überflüssig macht

Du vermeidest es, möglicherweise Hunderte von MB an Abhängigkeiten in dein Repository zu legen, und das bedeutet, dass es mit der Zeit schneller zu arbeiten ist. Das Wechseln von Zweigen und das Auschecken des Codes sind zwei Vorgänge, die von der Größe des Repositorys stark beeinflusst werden.

Bei der Arbeit mit Zweigen kann es zu Merge-Konflikten kommen, die über den eigenen Code hinausgehen und stattdessen den Code der Abhängigkeiten betreffen. Das ist unangenehm und kann zu einem großen Zeitverlust führen. Vermeiden

Ein Pull Request oder Merge, der die Abhängigkeiten ändert, wird viel mehr Dateien in den Prozess einbeziehen. Tools werden langsamer oder entscheiden sich sogar dafür, den vollständigen Diff nicht anzuzeigen (z.B. GitHub)

Native Node-Module müssen neu kompiliert werden, wenn Sie auf einer anderen Plattform als Ihrem Entwicklungsrechner deployen (häufiger Anwendungsfall: Sie entwickeln auf Mac, deployen auf Linux). Sie müssen npm rebuild aufrufen, was den Server aus der Synchronisation nimmt.

Das Nichtbegehen von node_modules impliziert, dass Sie alle Ihre Module in package.json (und package-lock.json) als obligatorischen Schritt auflisten müssen. Das ist großartig, weil du vielleicht nicht die Sorgfalt hast, dies zu tun, und einige der npm-Operationen könnten kaputt gehen, wenn du es nicht tust.

Tipp: Es besteht keine Notwendigkeit, die spezifische Version in deiner package.json-Datei zu verwenden, nicht mehr seit der Einführung der package-lock.json-Datei.

Wenn du getrennte dependencies und devDependencies Sets verwendest, wenn du den node_modules Ordner committest, committest du im Grunde genommen die devDependencies und es gibt keinen (einfachen) Weg für den Produktions-Build, sie loszuwerden.

Gründe, die dich dazu bringen könnten, node_modules zu committen und wie man sie entschärft

Ein npm Paket könnte von seinem Autor aus der npm-Registry entfernt werden. Dies geschah mit dem berühmten left-pad Vorfall im Jahr 2016 (lesen Sie mehr). Bei beliebten Paketen kommt dies nur sehr selten vor. Wenn dies passiert, haben Sie möglicherweise keinen Zugriff mehr auf diese spezielle Funktionalität.

Sie könnten auch argumentieren, dass npm nicht garantiert ist, auf unbestimmte Zeit zu bleiben, es könnte verschwinden, so dass ein einfacher Weg, um zu garantieren, den vollständigen Code Ihrer Anwendung in der Zukunft zu haben, ist, es zusammen mit Ihrer Anwendung zu übertragen.

Jedes Mal, wenn Sie ein Paket verwenden, erstellen Sie einen Fork auf GitHub. Halten Sie es hin und wieder mit dem Ursprung auf dem neuesten Stand (kann automatisiert werden).

Dies ist nicht immer praktisch, da Pakete Dutzende von eigenen Abhängigkeiten haben können.

Sie können einen privaten Repository-Server für Ihr Projekt verwenden und diesen nutzen, um alle Ihre Abhängigkeiten zu hosten.

Optionen sind

  • sinopia
  • npm_lazy
  • npm-lazy-mirror
  • artifactory
  • npm Enterprise, von der Firma npm

Ein weiterer Grund, die Abhängigkeiten zu committen, ist die Möglichkeit, den Code schnell zu bearbeiten, wenn man einen Fehler findet oder etwas zu einer Bibliothek hinzufügen möchte.

Das ist ein zweischneidiges Schwert: Wenn Sie das tun, verlieren Sie die Möglichkeit, das Paket zu aktualisieren, wenn neue Versionen gemacht werden, und es ist nur gut für schnelle, temporäre Korrekturen.

Die optimale Lösung besteht darin, entweder einen PR für das ursprüngliche Projekt einzureichen, der das tut, was Sie wollen, oder es zu faken und Ihren Fork als Abhängigkeit zu verwenden.

Laden Sie mein kostenloses Node.js-Handbuch herunter

Das JavaScript Full-Stack Bootcamp 2021 IST JETZT OFFEN FÜR ANMELDUNGEN BIS NÄCHSTEN DIENSTAG! Verpassen Sie diese Gelegenheit nicht, melden Sie sich HEUTE an!

Weitere Node-Tutorials:

  • Wie man Versprechen und await mit Node.js Callback-basierten Funktionen verwendet
  • Die Node Core Module
  • Parsing JSON with Node.js
  • Arbeiten mit Dateideskriptoren in Node
  • Node.js Streams
  • Abfrage des letzten Aktualisierungsdatums einer Datei mit Node.js
  • Der Pug Guide
  • Abfrage des aktuellen Ordners in Node
  • Verwendung der Node.js REPL

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.