Sollte der Ordner "node_modules" im Git-Repository enthalten sein?


Antworten:


176

Die Antwort ist nicht so einfach, wie Alberto Zaccagni vorschlägt. Wenn Sie Anwendungen (insbesondere Unternehmensanwendungen) entwickeln, ist es eine gute Wahl, node_modules in Ihr Git-Repo aufzunehmen, und welche Alternative Sie wählen, hängt von Ihrem Projekt ab.

Da er sehr gut gegen node_modules argumentiert hat, werde ich mich auf Argumente für sie konzentrieren.

Stellen Sie sich vor, Sie haben gerade die Unternehmens-App fertiggestellt und müssen sie 3-5 Jahre lang unterstützen. Sie möchten definitiv nicht auf das npm-Modul von jemandem angewiesen sein, das morgen verschwinden kann, und Sie können Ihre App nicht mehr aktualisieren.

Oder Sie haben Ihre privaten Module, die nicht über das Internet zugänglich sind, und Sie können Ihre App nicht im Internet erstellen. Oder vielleicht möchten Sie sich aus bestimmten Gründen nicht auf Ihren endgültigen Aufbau des npm-Dienstes verlassen.

In diesem Artikel von Addy Osmani finden Sie Vor- und Nachteile (obwohl es sich um Bower handelt, ist es fast die gleiche Situation). Und ich werde mit einem Zitat von der Bower-Homepage und Addys Artikel enden:

"Wenn Sie kein Paket erstellen, das von anderen verwendet werden soll (z. B. wenn Sie eine Web-App erstellen), sollten Sie installierte Pakete immer in der Quellcodeverwaltung einchecken."


6
Dem stimme ich voll und ganz zu. Ich will nicht , unser Unternehmen Build - System erfordern eine Internetverbindung einen erfolgreichen Build zu machen , weil es Abhängigkeiten herunterladen muss, die hoffentlich noch herum sind. Vielen Dank.
tödlicher Hund

9
@ Alberto Zaccagni Ich glaube, Sie hatten beim ersten Mal Recht. Wenn Sie wirklich eine Unternehmens-App erstellen, sollten Sie Unternehmenstools verwenden. Artifactory und npm-artifactory sollten zum Schutz vor Projekten verwendet werden, die aus dem Internet verschwinden. Selbst bei kleinen Projekten ist dies sauberer, als wenn mehrere Kopien derselben Sache in die Quellcodeverwaltung eingecheckt werden.
Ted Bigham

10
Nach dem Problem mit dem linken Pad denke ich, dass es definitiv keine schlechte Idee ist, node_modules zu verfolgen.
Léo Lam

6
Wichtiger Aspekt, den niemand erwähnt hat. Wenn sich Ihre node_modules unter VCS befinden, ist das Wechseln der Zweige gerecht git checkout foo. Wenn sich node_modules nicht unter VCS befinden - Zweig wechseln ist git checkout foo ; npm installund was auch immer Ihre aktuelle NPM-Version benötigt, um zu funktionieren;)
Ivan Kleshnin

7
Die sauberste Unternehmenslösung besteht darin, ein internes npm-Repository mit Zugriff auf das Intranet zu hosten, das alle von Ihnen verwendeten Modulversionen enthält, und node_modules nicht mit dem Quellcode einzuchecken. Ihr Build-System würde auf Ihr internes Knoten-Repository verweisen.
user2867288

103

Moduldetails werden gespeichert packages.json, das reicht. Sie müssen nicht einchecken node_modules.

Früher wurde node_modulesin der Versionskontrolle gespeichert , um Abhängigkeiten von Modulen zu sperren, aber mit npm Shrinkwrap wird dies nicht mehr benötigt.

Eine weitere Rechtfertigung für diesen Punkt, wie @ChrisCM im Kommentar schrieb:

Erwähnenswert ist auch, dass Module mit nativen Erweiterungen nicht von Architektur zu Architektur funktionieren und neu erstellt werden müssen. Bereitstellung einer konkreten Begründung für die NICHTaufnahme in das Repo.


10
Einfach und auf den Punkt +1. Erwähnenswert ist auch, dass Module mit nativen Erweiterungen nicht von Architektur zu Architektur funktionieren und neu erstellt werden müssen. Bereitstellung einer konkreten Begründung für die NICHTaufnahme in das Repo.
ChrisCM

3
Nicht wirklich, dies ist eine Rechtfertigung für die Verwendung einer reproduzierbaren Entwicklungsumgebung mit z. B. Vagrant. Es sollte nur an einer Architektur arbeiten müssen.
Robin Smith

20

Ich würde empfehlen, node_modules nicht einzuchecken, da beispielsweise Pakete wie PhantomJS und node-sass die entsprechende Binärdatei für das aktuelle System installieren.

Dies bedeutet, dass wenn ein npm installEntwickler unter Linux läuft und node_modules eincheckt, dies nicht für einen anderen Entwickler funktioniert, der das Repo unter Windows klont.

Es ist besser, die Tarballs einzuchecken, auf denen npm Downloads installiert, und npm-shrinkwrap.jsonauf sie zu zeigen. Sie können diesen Prozess mit shrinkpack automatisieren .


Aber hat npm install --global shrinkpackselbst nicht die verzögerte Schwäche, andere Pakete zu benötigen, mit denen die geschrumpften Pakete installiert werden sollen? Dies widerspricht Addys Rat.
Danjah

Könnten Sie die Frage bitte umformulieren @danjah? Ich verstehe dich nicht ganz, sorry.
Jamie Mason

shrinkpackNach Ihren Angaben ist eine Abhängigkeit von erforderlich, um Build-Abhängigkeiten zuverlässig zu installieren. Daher wird die Installation des Build-Tools selbst zur Schwachstelle des Arguments, alle Build-Abhängigkeiten der Versionskontrolle zu unterwerfen.
Danjah

1
Ich denke, dass das Einchecken der Sperrdateien ausreicht (package-lock.json; yarn.lock), zumindest laut TFM: docs.npmjs.com/files/package-lock.json
aimass

1
Sie würden ein vorhersehbares Abhängigkeitsdiagramm erhalten, wenn Sie eine Sperrdatei verwenden, und wären nicht anfällig für die Probleme, die in Bezug auf PhantomJS und Node-Sass usw. auf verschiedenen Plattformen diskutiert werden. Sie benötigen eine Internetverbindung und die Registrierung ist natürlich aktiv.
Jamie Mason

7

Ich verstehe, dieses Thema ist ziemlich alt. Aufgrund der veränderten Situation im Ökosystem von npm fehlt mir jedoch eine Aktualisierung der hier angegebenen Argumente.

Ich würde immer raten, node_modules nicht unter Versionskontrolle zu stellen. Fast alle Vorteile, die im Zusammenhang mit der akzeptierten Antwort aufgeführt sind, sind derzeit ziemlich veraltet.

  1. Veröffentlichte Pakete können nicht mehr so ​​einfach aus der npm-Registrierung widerrufen werden. Sie müssen also nicht befürchten, Abhängigkeiten zu verlieren, auf die sich Ihr Projekt zuvor verlassen hat.

  2. Das Einfügen der Datei package-json.lock in VCS hilft bei häufig aktualisierten Abhängigkeiten, die wahrscheinlich zu unterschiedlichen Setups führen, obwohl dieselbe Datei package.json verwendet wird.

Das Einfügen von node_modules in VCS im Falle von Offline-Build-Tools kann daher als der einzige verbleibende Anwendungsfall angesehen werden. Node_modules wächst jedoch normalerweise ziemlich schnell. Jedes Update ändert viele Dateien. Dies wirkt sich auf Repositories auf unterschiedliche Weise aus. Wenn Sie wirklich langfristige Auswirkungen in Betracht ziehen, kann dies ebenfalls ein Hindernis sein.

Zentralisierte VCS wie svn erfordern das Übertragen festgeschriebener und ausgecheckter Dateien über das Netzwerk, was beim Auschecken oder Aktualisieren eines Ordners node_modules höllisch langsam sein wird.

Wenn es um Git geht, verschmutzt diese hohe Anzahl zusätzlicher Dateien sofort das Repository. Beachten Sie, dass git keine Unterschiede zwischen den Versionen einer Datei verfolgt, sondern Kopien beider Versionen einer Datei speichert, sobald sich ein einzelnes Zeichen geändert hat. Jedes Update einer Abhängigkeit führt zu einem weiteren großen Änderungssatz. Ihr Git-Repository wird schnell riesig, da dies Auswirkungen auf Backups und Remote-Synchronisation hat. Wenn Sie sich entscheiden, node_modules später aus dem Git-Repository zu entfernen, ist es aus historischen Gründen immer noch Teil davon. Wenn Sie Ihr Git-Repository auf einen Remote-Server verteilt haben (z. B. zur Sicherung), ist die Bereinigung eine weitere schmerzhafte und fehleranfällige Aufgabe, auf die Sie stoßen würden.

Wenn Sie also auf effiziente Prozesse Wert legen und die Dinge "klein" halten möchten, verwende ich lieber ein separates Artefakt-Repository wie das Nexos-Repository (oder nur einen HTTP-Server mit ZIP-Archiven), das einige zuvor abgerufene Abhängigkeiten zum Herunterladen bereitstellt.


6

Nicht node_modulesmit der Quellcodeverwaltung zu verfolgen ist die richtige Wahl, da einige NodeJS-Module, wie der MongoDB NodeJS-Treiber, NodeJS C ++ - Add-Ons verwenden. Diese Add-Ons werden beim Ausführen des npm installBefehls kompiliert . Wenn Sie also das node_modulesVerzeichnis verfolgen , können Sie versehentlich eine betriebssystemspezifische Binärdatei festschreiben.


3

Ich stimme ivoszz zu, dass es manchmal nützlich ist , den Ordner node_modules zu überprüfen, aber ...


Szenario 1:

Ein Szenario: Sie verwenden ein Paket, das aus npm entfernt wird. Wenn Sie alle Module im Ordner node_modules haben, ist dies für Sie kein Problem. Wenn Sie nur den Paketnamen in der Datei package.json haben, können Sie ihn nicht mehr erhalten. Wenn ein Paket weniger als 24 Stunden alt ist, können Sie es problemlos aus npm entfernen. Wenn es älter als 24 Stunden ist, müssen Sie sie kontaktieren. Aber:

Wenn Sie sich an den Support wenden, wird geprüft, ob durch das Entfernen dieser Version Ihres Pakets andere Installationen beschädigt werden. Wenn ja, werden wir es nicht entfernen.

Weiterlesen

Die Chancen dafür sind also gering, aber es gibt Szenario 2 ...


Szenario 2:

Ein anderes Szenario, in dem dies der Fall ist: Sie entwickeln eine Unternehmensversion Ihrer Software oder eine sehr wichtige Software und schreiben in Ihr package.json:

"dependencies": {
    "studpid-package": "~1.0.1"
}

Sie verwenden die Methode function1(x)dieses Pakets.

Jetzt benennen die Entwickler von studpid-package die Methode function1(x)in um function2(x)und machen einen Fehler ... Sie ändern die Version ihres Pakets von 1.0.1auf 1.1.0. Das ist ein Problem, denn wenn Sie npm installdas nächste Mal aufrufen , akzeptieren Sie die Version, 1.1.0weil Sie die Tilde verwendet haben ("studpid-package": "~1.0.1" ) verwendet haben.

Das Anrufen function1(x)kann jetzt Fehler und Probleme verursachen.


Aber:

Das Verschieben des gesamten Ordners node_modules (häufig mehr als 100 MB) in Ihr Repository kostet Speicherplatz. Ein paar KB (nur package.json) im Vergleich zu Hunderten von MB (package.json & node_modules) ... Denken Sie darüber nach.

Sie könnten es tun / sollten darüber nachdenken, wenn:

  • Die Software ist sehr wichtig.

  • Es kostet Sie Geld, wenn etwas ausfällt.

  • Sie vertrauen der npm-Registrierung nicht. npm ist zentralisiert und könnte theoretisch heruntergefahren werden.

Sie brauchen nicht , wenn die node_modules Ordner in 99,9% der Fälle zu veröffentlichen:

  • Sie entwickeln eine Software nur für sich.

  • Sie haben etwas programmiert und möchten das Ergebnis nur auf GitHub veröffentlichen, weil sich möglicherweise jemand anderes dafür interessiert.


Wenn Sie nicht möchten, dass sich die node_modules in Ihrem Repository befinden, erstellen Sie einfach eine .gitignoreDatei und fügen Sie die Zeile hinzu node_modules.


1
Ein weiterer Nachteil beim "Veröffentlichen des Ordners node_modules" könnte sein: Wenn Sie npm installWindows und MacOS aufrufen, können in einigen Paketen unterschiedliche Dateien ( betriebssystemabhängige Dateien) generiert werden. Aber da bin ich mir nicht sicher. Kann jemand überprüfen, ob dies wahr ist?
NDSVW

2
"Szenario 2": Deshalb verpflichten Sie sich package-lock.json. Wenn es in Zukunft ein Problem mit einem Update des studpid-Pakets gibt, können Sie die Sperrdatei zurücksetzen, um die genaue Version herauszufinden, die für Sie funktioniert hat.
ToolmakerSteve

2

Ich möchte eine Alternative mitten auf der Straße anbieten.

  1. Nicht hinzufügen node_modules in git .
  2. Benutze einen package-lock.json Datei, um Ihre Abhängigkeitsversionen festzulegen.
  3. Wenn Sie in Ihrem CI- oder Freigabeprozess eine Version freigeben, erstellen Sie eine Kopie des Ordners node_modules und sichern Sie ihn (z. B. im Cloud-Speicher).

In dem seltenen Fall, dass Sie nicht auf NPM (oder andere von Ihnen verwendete Register) oder ein bestimmtes Paket in NPM zugreifen können, verfügen Sie über eine Kopie von node_modules und können weiterarbeiten, bis Sie den Zugriff wiederherstellen.


0

Noch etwas zu beachten: Das Einchecken node_modulesmacht es schwieriger / unmöglich, den Unterschied zwischen dependenciesund zu nutzen devDependencies.

Auf der anderen Seite könnte man sagen, dass es beruhigend ist, genau den gleichen Code in die Produktion zu bringen, der die Tests durchlaufen hat - also auch devDependencies.


"Um genau den Code zu produzieren, der getestet wurde": Dafür haben Sie Docker. Oder ein OS-Paketmanager wie RPM. Sie erstellen den Code zwischen test und prod nicht neu, oder? devDependencies half beim Erstellen des endgültigen Codes, hat jedoch keinen Platz in einer Bereitstellung, weder im Test noch im Produkt.
Per Wiklander

Wäre es hilfreich, wenn die devDependencies in ihrem eigenen package.json ein Verzeichnis höher wären als das "src" -Verzeichnis? Da nach Knotenmodulen gesucht wird, die im aktuellen Verzeichnis beginnen und dann nach oben verschoben werden sollen, sollten Sie weiterhin Ihre Entwicklungsabhängigkeiten verwenden und die dev / src-Module trennen.
Alex

0

node_modules muss nicht eingecheckt werden, wenn Abhängigkeiten in package.json erwähnt werden. Jeder andere Programmierer kann es einfach durch die Installation von npm erhalten, und die npm ist intelligent genug, um die node_modules in Ihrem Arbeitsverzeichnis für das Projekt zu erstellen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.