Het 2021 JavaScript Full-Stack Bootcamp is NU OPEN VOOR AANMELDINGEN!

Moet je de node_modules map committen naar Git?

Ik noem Git, maar hetzelfde geldt voor elk versiebeheersysteem dat je toevallig gebruikt

Dat is een goede vraag om te hebben. Er zijn voors en tegens.

Ik stel voor om standaard de node_modules map niet te committen, en in plaats daarvan toe te voegen aan je .gitignore bestand.

Je hebt misschien speciale behoeften die deze beslissing omdraaien.

Ik bespreek het onderwerp zodat je je eigen mening kunt vormen.

Hier zijn wat argumenten ten gunste van het niet committen van node_modules

Je houdt je Git geschiedenis schoon. Wanneer je een nieuw pakket toevoegt, sla je de package.json en package-lock.json bestandswijzigingen op.Wanneer je besluit de pakketversie te updaten, sla je alleen de package-lock.json bestandswijziging op.

package-lock.json is een relatief nieuwe functie van npm, die het in het verleden gebruikte shrinkwrap commando overbodig maakt

Je vermijdt dat je mogelijk honderden MB aan afhankelijkheden in je repository moet stoppen, en dit betekent dat het na verloop van tijd sneller zal zijn om mee te werken. Het wisselen van takken en het controleren van de code zijn 2 operaties die enorm beïnvloed worden door de grootte van het archief.

Wanneer je met takken werkt, kun je samenvoeg conflicten krijgen die verder reiken dan jouw code, en in plaats daarvan, de code van de afhankelijkheden betreffen. Dit is niet leuk om mee om te gaan en kan je veel tijd kosten. Het vermijden van

Een pull verzoek of samenvoeging als het veranderen van de afhankelijkheden, gaat veel meer bestanden betrekken in het proces. Tools worden langzamer of besluiten zelfs om de volledige diff niet te tonen (GitHub, bijvoorbeeld)

Native node modules moeten opnieuw worden gecompileerd als je ze op een ander platform installeert dan je ontwikkelmachine (veel voorkomend geval: je ontwikkelt op Mac, implementeert op Linux). Je moet npm rebuild aanroepen, wat de server uit sync haalt.

Niet committen van node_modules impliceert dat je al je modules in de package.json (en package-lock.json) moet zetten als een verplichte stap. Dit is geweldig omdat je misschien niet de ijver hebt om dit te doen, en sommige van de npm-bewerkingen zouden kunnen breken als je het niet doet.

Tip: het is niet meer nodig om de specifieke versie in je package.json-bestand te gebruiken, niet meer sinds de introductie van het package-lock.json-bestand.

Als u afzonderlijke dependencies– en devDependencies-verzamelingen gebruikt, legt u door de node_modules-map vast te leggen in feite de devDependencies vast en er is geen (eenvoudige) manier voor de productie build om ze kwijt te raken.

Redenen die ertoe kunnen leiden dat u node_modules vastlegt, en hoe u ze kunt beperken

Een npm-pakket kan door de auteur ervan uit het npm-register worden verwijderd. Het gebeurde met het beroemde left-pad incident in 2016 (lees meer). Dit gebeurt zeer zelden voor populaire pakketten. Als dit gebeurt, heb je misschien geen toegang meer tot dat specifieke stuk functionaliteit.

Je zou ook kunnen aanvoeren dat npm niet gegarandeerd voor onbepaalde tijd in de buurt blijft, het zou kunnen verdwijnen, dus een gemakkelijke manier om te garanderen dat je in de toekomst de volledige code van je applicatie hebt, is om het samen met je app te committen.

Elke keer dat je een pakket gebruikt, maak je een fork aan op GitHub. Houd het eens in de zoveel tijd up to date met de origin (kan worden geautomatiseerd).

Dit is niet altijd praktisch, omdat pakketten tientallen van hun eigen afhankelijkheden kunnen hebben.

Je kunt een privé repository server voor je project gebruiken, en dat gebruiken om al je afhankelijkheden te hosten.

Opties zijn onder andere

• sinopia
• npm_lazy
• npm-lazy-mirror
• artifactory
• npm Enterprise, van de npm company

Een andere reden om de dependencies te committen is de mogelijkheid om snel de code aan te passen, als je een bug vindt of als je iets aan een library wilt toevoegen.

Dit is een tweesnijdend zwaard: als je dit doet, verlies je de mogelijkheid om het pakket te upgraden als er nieuwe releases worden gemaakt, en het is alleen goed voor snelle, tijdelijke fixes.

De optimale oplossing is om ofwel een PR in te dienen bij het oorspronkelijke project dat doet wat je wilt, of het project te forken en je fork als een dependency te gebruiken.

Het 2021 JavaScript Full-Stack Bootcamp IS NU OPEN VOOR AANMELDINGEN TOT VOLGENDE TUNEDAAG! Mis deze kans niet, schrijf je TODAY in!

Meer Node tutorials:

• Hoe promises en await te gebruiken met Node.js callback-gebaseerde functies
• De Node Core Modules
• Parsing JSON with Node.js
• Werken met file descriptors in Node
• Node.js Streams
• Hoe de laatst bijgewerkte datum van een bestand op te vragen met Node.js
• De Pug Guide
• De huidige map opvragen in Node
• Hoe de Node.js REPL

te gebruiken.