Moet ik de map “node_modules” in Git inchecken bij het maken van een Node.js-app op Heroku?

Ik heb hier de basisinstructies aan de slagvoor Node.js op Heroku gevolgd:

https://devcenter.heroku.com/categories/nodejs

Deze instructies vertellen je niet om een ​​.gitignore node_modules aan te maken, en impliceren daarom dat de map node_modulesingecheckt moet worden in Git. Toen ik node_modulesin de Git-repository opnam, werkte mijn aan de slag-toepassing correct.

Toen ik het meer geavanceerde voorbeeld volgde op:

• Een realtime, polyglot bouwen Applicatie met Node.js, Ruby, MongoDB en Socket.IO
• https://github.com/mongolab/tractorpush-server(bron)

Het gaf me de opdracht om de map node_modulestoe te voegen aan het bestand .gitignore. Dus verwijderde ik de map node_modulesvan Git, voegde het toe aan het bestand .gitignoreen implementeerde het opnieuw. Deze keer mislukte de implementatie als volgt:

-----> Heroku receiving push
-----> Node.js app detected
-----> Resolving engine versions
       Using Node.js version: 0.8.2
       Using npm version: 1.0.106
-----> Fetching Node.js binaries
-----> Vendoring node into slug
-----> Installing dependencies with npm
       Error: npm doesn't work with node v0.8.2
       Required: [email protected] || 0.5 || 0.6
           at /tmp/node-npm-5iGk/bin/npm-cli.js:57:23
           at Object.<anonymous> (/tmp/node-npm-5iGk/bin/npm-cli.js:77:3)
           at Module._compile (module.js:449:26)
           at Object.Module._extensions..js (module.js:467:10)
           at Module.load (module.js:356:32)
           at Function.Module._load (module.js:312:12)
           at Module.require (module.js:362:17)
           at require (module.js:378:17)
           at Object.<anonymous> (/tmp/node-npm-5iGk/cli.js:2:1)
           at Module._compile (module.js:449:26)
       Error: npm doesn't work with node v0.8.2
       Required: [email protected] || 0.5 || 0.6
           at /tmp/node-npm-5iGk/bin/npm-cli.js:57:23
           at Object.<anonymous> (/tmp/node-npm-5iGk/bin/npm-cli.js:77:3)
           at Module._compile (module.js:449:26)
           at Object.Module._extensions..js (module.js:467:10)
           at Module.load (module.js:356:32)
           at Function.Module._load (module.js:312:12)
           at Module.require (module.js:362:17)
           at require (module.js:378:17)
           at Object.<anonymous> (/tmp/node-npm-5iGk/cli.js:2:1)
           at Module._compile (module.js:449:26)
       Dependencies installed
-----> Discovering process types
       Procfile declares types -> mongod, redis, web
-----> Compiled slug size is 5.0MB
-----> Launching... done, v9

Het uitvoeren van “heroku ps” bevestigt de crash. OK, geen probleem, dus ik heb de wijziging teruggedraaid, map node_moduletoegevoegd aan de Git-repository en verwijderd uit bestand .gitignore. Zelfs na het terugzetten krijg ik echter nog steeds dezelfde foutmelding bij het implementeren, maar nu werkt de applicatie weer correct. Het uitvoeren van “heroku ps” geeft aan dat de applicatie actief is.

Wat is de juiste manier om dit te doen? Map node_moduleswel of niet opnemen? En waarom zou ik nog steeds de foutmelding krijgen als ik terugdraai? Ik vermoed dat de Git-repository aan de Heroku-kant in een slechte staat verkeert.

Antwoord 1, autoriteit 100%

Tweede update

De veelgestelde vragen zijn niet meer beschikbaar.

Uit de documentatie van shrinkwrap:

Als u de specifieke bytes in een pakket wilt vergrendelen, bijvoorbeeld om 100% vertrouwen te hebben in het kunnen reproduceren van een implementatie of build, dan moet u uw afhankelijkheden controleren in bronbeheer of een ander mechanisme nastreven die inhoud kan verifiëren in plaats van versies.

Shannon en Steven hebben dit al eerder genoemd, maar ik denk dat het deel moet uitmaken van het geaccepteerde antwoord.

Bijwerken

De bron vermeld voor de onderstaande aanbeveling is bijgewerkt. Ze raden niet langer aan om de map node_modulesvast te leggen.

Meestal niet. Laat npm afhankelijkheden voor uw pakketten oplossen.

Voor pakketten die u implementeert, zoals websites en apps, moet u npm . gebruiken
krimpfolie om uw volledige afhankelijkheidsboom te vergrendelen:

https://docs.npmjs.com/cli/shrinkwrap

Originele post

Ter referentie, npm FAQ beantwoordt uw vraag duidelijk:

Controleer node_modules in git voor dingen die je implementeert, zoals websites
en apps. Vink node_modules niet aan in git voor bibliotheken en modules
bedoeld om opnieuw te worden gebruikt. Gebruik npm om afhankelijkheden in uw ontwikkelaar te beheren
omgeving, maar niet in uw implementatiescripts.

en voor een goede reden hiervoor, lees Mikeal Rogers’ bericht hierover.

Bron: https ://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git

Antwoord 2, autoriteit 42%

Mijn grootste zorg met het nietcontroleren van de map node_modulesin Git is dat 10 jaar later, wanneer je productietoepassing nog in gebruik is, npm er misschien niet meer is. Of npm kan beschadigd raken; of de beheerders kunnen besluiten om de bibliotheek waarop u vertrouwt uit hun repository te verwijderen; of de versie die u gebruikt kan worden weggesneden.

Dit kan worden verholpen met repositorybeheerders zoals Maven, omdat u altijd uw eigen lokale Nexus(Sonatype) of Artifactoryom een ​​mirror te onderhouden met de pakketten die u gebruikt. Voor zover ik begrijp, bestaat zo’n systeem niet voor npm. Hetzelfde geldt voor client-side bibliotheekmanagers zoals Boweren Jam.js.

Als je de bestanden hebt vastgelegd in je eigen Git-repository, kun je ze bijwerken wanneer je wilt, en je hebt het comfort van herhaalbare builds en de wetenschap dat je applicatie niet kapot gaat vanwege een actie van derden .

Antwoord 3, autoriteit 17%

U moet geenmap node_modulesopnemen in uw .gitignorebestand (of liever je moetmap node_modulesopnemen in je brongeïmplementeerd in Heroku).

Als map node_modules:

• bestaat, dan zal npm installdie bibliotheken van de leverancier gebruiken en alle binaire afhankelijkheden opnieuw opbouwen met npm rebuild.
• bestaat niet, dan zal npm installalle afhankelijkheden zelf moeten ophalen, wat tijd toevoegt aan de slug-compileerstap.

Bekijk de Node.js buildpack-bron voor deze exacte stappen.

De oorspronkelijke fout lijkt echter een incompatibiliteit te zijn tussen de versies van npmen Node.js. Het is een goed idee om de sectie enginesvan uw packages.json-bestand altijd expliciet in te stellen volgens deze handleidingom dit soort situaties te vermijden:

{
  "name": "myapp",
  "version": "0.0.1",
  "engines": {
    "node": "0.8.x",
    "npm":  "1.1.x"
  }
}

Dit zorgt voor ontwikkelings-/productiepariteiten vermindert de kans op dergelijke situaties in de toekomst.

Antwoord 4, autoriteit 6%

Ik wilde dit achterlaten na deze opmerking: Moet ik de map “node_modules” in Git inchecken bij het maken van een Node.js-app op Heroku?

Maar Stack Overflow was het vreemd aan het formatteren.

Als je geen identieke machines hebt en node_modules incheckt, voer dan een .gitignore uit op de native extensies. Onze .gitignore ziet eruit als:

# Ignore native extensions in the node_modules folder (things changed by npm rebuild)
node_modules/**/*.node
node_modules/**/*.o
node_modules/**/*.a
node_modules/**/*.mk
node_modules/**/*.gypi
node_modules/**/*.target
node_modules/**/.deps/
node_modules/**/build/Makefile
node_modules/**/**/build/Makefile

Test dit door eerst alles in te checken en vervolgens een andere ontwikkelaar het volgende te laten doen:

rm -rf node_modules
git checkout -- node_modules
npm rebuild
git status

Zorg ervoor dat er geen bestanden zijn gewijzigd.

Antwoord 5, autoriteit 3%

Ik ben van mening dat npm installniet in een productieomgeving mag worden uitgevoerd. Er zijn verschillende dingen die fout kunnen gaan – npm-storing, downloaden van nieuwere afhankelijkheden (Shrinkwraplijkt dit te hebben opgelost) zijn er twee van.

Aan de andere kant moet de map node_modulesniet worden vastgelegd in Git. Afgezien van hun grote omvang, kunnen commits met hen afleiden.

De beste oplossing zou dit zijn: npm installzou moeten draaien in een CI omgeving die vergelijkbaar is met de productieomgeving. Alle tests worden uitgevoerd en er wordt een gecomprimeerd releasebestand gemaakt dat alle afhankelijkheden bevat.

Antwoord 6, autoriteit 2%

Ik heb zowel het committen van de node_modulesmap als het inkrimpen gebruikt. Van beide oplossingen werd ik niet blij.

Kortom: een toegewijde map node_modulesvoegt te veel ruis toe aan de repository. En shrinkwrap.jsonis niet gemakkelijk te beheren en er is geen enkele garantie dat sommige in krimpfolie verpakt project zal over een paar jaar worden gebouwd.

Ik ontdekte dat Mozilla een aparte repository gebruikte voor een van hun projecten: https: //github.com/mozilla-b2g/gaia-node-modules

Het kostte me dus niet veel tijd om dit idee te implementeren in een Node.js CLI-tool: https://github.com/bestander/npm-git-lock

Net voor elke build, voeg toe:

npm-git-lock --repo [[email protected]:your/dedicated/node_modules/git/repository.git]

Het berekent de hash van uw package.json-bestand en checkt de inhoud van de map node_modulesuit een externe repository, of, als het een eerste build is voor dit package.json-bestand, zal een schone npm installuitvoeren en de resultaten naar de externe repository pushen.

Antwoord 7

expliciet toevoegen van een NPM versie bestand package.json ( “NPM”: “1.1.x”) en niet het controleren in de map node_modules om Git gewerkt voor mij.

Het kan langzamer zijn in te zetten (omdat het de pakketten elke keer gedownload), maar ik kon niet de pakketten te compileren toen ze werden gecontroleerd. Heroku was op zoek naar bestanden die alleen bestond op mijn lokale box.

Antwoord 8

In plaats van het controleren in de map node_modules , maak een package.json file voor uw toepassing.

package.json bestand de afhankelijkheden van uw aanvraag. Heroku kunnen dan vertellen NPM om al die afhankelijkheden te installeren. De tutorial je gekoppeld aan bevat een deel over package.json bestanden.

Antwoord 9

Van ” node_modules” in Git

Om te recapituleren.

• Alleen checkin node_modules voor toepassingen die u implementeren, niet herbruikbaar
  pakketten die u te handhaven.
• Elke samengesteld afhankelijkheden moeten hun hebben
  bron ingecheckt, niet de compilatie streefcijfers en moeten ze $ NPM herbouwen
  op implementeren.

Mijn favoriete onderdeel:

Alles wat je mensen die node_modules uw gitignore toegevoegd, verwijderen dat
shit, vandaag , het is een artefact van een tijdperk zijn we maar al te blij om te vertrekken
achter. Het tijdperk van globale modules is dood.

_{(De originele link was deze , maar het is nu dood. Thanks @Flavio voor het wijzen het uit.) *}

Antwoord 10

Ik gebruik deze oplossing:

1. Maak een aparte repository die map bevat node_modules . Als u inheemse modules die gebouwd moet worden voor specifieke platform maak vervolgens een aparte opslagplaats voor elk platform.

2. Bevestig deze repositories om uw project repository met git submodule

   git submodule add .../your_project_node_modules_windows.git node_modules_windows

   git submodule add .../your_project_node_modules_linux_x86_64 node_modules_linux_x86_64

3. Een koppeling van platform-specifieke node_modulesnaar node_modulesdirectory en voeg node_modulesnaar .gitignore.

4. Uitvoeren npm install.

5. Commit submodule repository wijzigingen.

6. Wentel uw project repository wijzigingen.

Dus u gemakkelijk kunt schakelen tussen node_modulesop verschillende platformen (bijvoorbeeld als je de ontwikkeling van op OS X en het inzetten op Linux).

Antwoord 11

Scenario 1:

Een scenario:

U gebruikt een pakket dat van NPM wordt verwijderd. Als u alle modules in de map node_modules, dan zal het niet een probleem voor u zijn. Als u alleen de naam van het pakket hebben in de package.json, kun je het niet meer te krijgen.

Als een pakket is minder dan 24 uur oud, kunt u eenvoudig verwijderen uit NPM.
Als het ouder is dan 24 uur oud, dan moet je om hen te contacteren.

Maar:

Als u contact opnemen met ondersteuning, zullen ze controleren om te zien of het verwijderen van die versie van het pakket een andere installaties zou breken. Als dat zo is, zullen we niet meer verwijderen.

lees meer

Dus de kansen voor deze laag zijn, maar er is scenario 2 …

Scenario 2:

Een ander scenario waar dit het geval is:

U ontwikkelt een enterprise versie van uw software of een zeer belangrijke software en schrijven in uw package.json:

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

U gebruikt de methode function1(x)van het pakket.

Nu de ontwikkelaars van studpid-pakket de naam van de methode function1(x)naar function2(x)en ze maken een fout …
Ze wijzigen de versie van hun pakket van 1.0.1in 1.1.0.
Dat is een probleem, want als je de volgende keer npm installaanroept, accepteer je versie 1.1.0omdat je de tilde hebt gebruikt ("studpid-package": "~1.0.1").

Het aanroepen van function1(x)kan nu fouten en problemen veroorzaken.

Het pushen van de hele map node_modules (vaak meer dan 100 MB) naar je repository kost je geheugenruimte.
Een paar kb (alleen package.json) vergeleken met honderden MB (package.json & node_modules)… Denk er eens over na.

Je zou het kunnen doen / erover nadenkenals:

• de software is erg belangrijk.

• het kost je geld als iets niet lukt.

• u vertrouwt het npm-register niet. npm is gecentraliseerd en zou theoretisch kunnen worden afgesloten.

U hoeft nietde map node_modules in 99,9% van de gevallen te publiceren als:

• je ontwikkelt software voor jezelf.

• je hebt iets geprogrammeerd en wil het resultaat gewoon op GitHub publiceren omdat iemand anders er misschien in geïnteresseerd zou kunnen zijn.

Als u niet wilt dat de node_modules in uw repository staan, maakt u gewoon een .gitignore-bestand en voegt u de regel node_modulestoe.

Antwoord 12

Als u uw eigen modules gebruikt die specifiek zijn voor uw toepassing, kunt u:

• Bewaar deze (en alleen die) in de map /node_modulesvan uw toepassing en verplaats alle andere afhankelijkheden naar bovenliggende ../node_modulesmap. Dit zal werken vanwege de manier waarop het NodeJS CommonJS-modulesysteem werkt door naar de bovenliggende map te gaan, enzovoort, totdat de hoofdmap van de boom is bereikt. Zie: https://nodejs.org/api/modules.html

• Of negeer alle /node_modules/*behalveje /node_modules/your-modules. Zie: Laat .gitignore alles negeren behalve een paar bestanden

Deze use-case is behoorlijk geweldig. Hiermee kunt u modules die u speciaal voor uw toepassing hebt gemaakt, er netjes bij bewaren en niet vol met afhankelijkheden die later kunnen worden geïnstalleerd.