Czy powinienem sprawdzić w modułach węzła do git podczas tworzenia węzła.aplikacja js na Heroku?

Moim największym zmartwieniem z nie sprawdzanie node_modules w git jest to, że 10 lat w dół drogi, kiedy Twoja aplikacja produkcyjna jest nadal w użyciu, npm może nie być w pobliżu. Lub npm może zostać uszkodzony; lub opiekunowie mogą zdecydować się usunąć bibliotekę, na której polegasz z ich repozytorium; lub używana wersja może zostać przycięta.

Można to złagodzić za pomocą menedżerów repo, takich jak maven, ponieważ zawsze możesz użyć własnego lokalnego Nexusa lub Artifactory, aby utrzymać lustro z pakiety, których używasz. O ile rozumiem, taki system nie istnieje dla npm. To samo dotyczy menedżerów bibliotek po stronie klienta, takich jak Bower i Jamjs.

Jeśli przypisałeś pliki do własnego Git repo, możesz je aktualizować, kiedy chcesz, i masz komfort powtarzalnych kompilacji i wiedzę, że Twoja aplikacja nie zepsuje się z powodu jakiejś akcji innej firmy.

Powinieneś nie zawierać node_modules w twoim .gitignore (a raczej powinieneś node_modules w Twoim źródle wysłanym do Heroku).

If node_modules:

• istnieje wtedy npm install użyje tych sprzedanych bibliotek i odbuduje wszystkie binarne zależności za pomocą npm rebuild.
• doesn 't exist then npm install will have to fetch all dependencies himself which doesn' t time to the SLUG compile step.

Zobacz węzeł.js buildpack źródło dla tych dokładnych kroków

Oryginalny błąd wygląda jednak na niezgodność pomiędzy wersjami npm i node. Dobrze jest zawsze wyraźnie ustawić engines sekcję twojego packages.json zgodnie z ten przewodnik , aby uniknąć tego typu sytuacji:

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

Zapewni to parytet dev/prod i zmniejszy prawdopodobieństwo wystąpienia takich sytuacji w przyszłości.

Miałem zamiar zostawić to po tym komentarzu: Czy powinienem sprawdzić node_modules do git podczas tworzenia węzła.aplikacja js na Heroku?

Ale stackoverflow dziwnie formatował. Jeśli nie masz identycznych maszyn i sprawdzasz node_modules, wykonaj .gitignore na natywnych rozszerzeniach. Nasze .gitignore wygląda tak:

# 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

Przetestuj to, najpierw sprawdzając wszystko, a następnie poproś innego dev ' a o wykonanie następujących czynności:

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

Upewnij się, że żadne pliki nie uległy zmianie.

Używam zarówno folderu node_modules jak i shrink-wrapping. Oba rozwiązania mnie nie uszczęśliwiły.

W skrócie: committed node_modules dodaje zbyt dużo szumu do repozytorium.
I shrinkwrap.json nie jest łatwy w zarządzaniu i nie ma gwarancji, że jakiś projekt zostanie zbudowany w ciągu kilku lat.

Odkryłem, że Mozilla używa osobnego repozytorium dla jednego ze swoich projektów https://github.com/mozilla-b2g/gaia-node-modules

Więc to nie zajęło mi dużo czasu, aby zaimplementować ten pomysł w narzędziu CLI węzła https://github.com/bestander/npm-git-lock

Tuż przed każdym zbudowaniem dodaj
npm-git-lock --repo [[email protected]:your/dedicated/node_modules/git/repository.git]

Obliczy hash Twojego pakietu.json i albo sprawdzi zawartość node_modules ze zdalnego repo, albo, jeśli jest to pierwsza kompilacja dla tego pakietu.json, wykona czystą npm install i prześle wyniki do zdalnego repo.

Uważam, że npm install nie powinno działać w środowisku produkcyjnym. Jest kilka rzeczy, które mogą pójść nie tak - npm outage, pobieranie nowszych zależności (shrinkwrap wydaje się to rozwiązać) to dwie z nich.

Z drugiej strony, node_modules nie powinno się angażować w git. Oprócz ich dużego rozmiaru, commity zawierające je mogą być rozpraszające.

Najlepsze rozwiązania byłyby takie: npm install powinny działać w środowisku CI, które jest podobne do środowiska produkcyjnego. Wszystkie testy będą Uruchom i zostanie utworzony spakowany plik release, który będzie zawierał wszystkie zależności.

To, co działało dla mnie, to jawne dodanie wersji npm do pakietu.json ("npm": "1.1.x") i nie Sprawdzanie w node_modules do git. Wdrożenie może być wolniejsze (ponieważ pobiera Pakiety za każdym razem), ale nie mogłem zmusić pakietów do kompilacji, gdy były sprawdzane. Heroku szukał plików, które istniały tylko na moim lokalnym pudełku.

Zamiast sprawdzać node_modules, stwórz pakiet.plik json dla Twojej aplikacji.

Paczka.plik json określa zależności aplikacji. Heroku może wtedy powiedzieć npm, aby zainstalował wszystkie te zależności. Samouczek, z którym się łączyłeś, zawiera sekcję dotyczącą pakietu.pliki json.

Używam tego rozwiązania:

1. Utwórz osobne repozytorium zawierające node_modules. Jeśli masz natywne moduły, które powinny być zbudowane dla konkretnej platformy, Utwórz osobne repozytorium dla każdej platformy.
2. Załącz te repozytoria do repozytorium projektu za pomocą 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

1. Utwórz łącze ze specyficznego dla platformy node_modules do katalogu node_modules i dodaj node_modules do .gitignore.
2. Run npm install.
3. Commit submodule zmiany w repozytorium.
4. zatwierdź zmiany w repozytorium projektu.

Więc możesz łatwo przełączać się między node_modules Na różnych platformach (na przykład, jeśli rozwijasz się na OS X i wdrażasz na Linuksie).

Od https://web.archive.org/web/20150212165006/http://www.futurealoof.com/posts/nodemodules-in-git.html:

Edit: oryginalny link był Ten ale teraz jest martwy. Dzięki @Flavio za wskazanie.

Do podsumowania.

• tylko checkIn node_modules dla aplikacji, które wdrażasz, a nie wielokrotnego użytku pakiety, które utrzymujesz.
• wszelkie skompilowane zależności powinny mieć swoje źródło sprawdzone, a nie cele kompilacji, i powinien $ npm odbudować / align = "left" /

Moja ulubiona część:

Wszyscy, którzy dodali node_modules do gitignore, usuń to cholera, dzisiaj to artefakt z epoki, z której wszyscy jesteśmy zbyt szczęśliwi, by odejść. z tyłu. Era globalnych modułów jest martwa.

Http://nodejs.org/api/modules.html

[...] node rozpoczyna się w katalogu nadrzędnym bieżącego modułu, dodaje /node_modules i próbuje załadować moduł z tej lokalizacji.

Jeśli nie zostanie tam znaleziony, wtedy zostanie przeniesiony do katalogu nadrzędnego i tak dalej , aż do osiągnięcia korzenia drzewa.

Jeśli nagrywasz własne moduły specyficzne dla Twojej aplikacji, możesz je zachować ( i tylko te ) w /node_modules Twojej aplikacji. Oraz Przenieś wszystkie pozostałe zależności do katalogu nadrzędnego.

Ten przypadek użycia całkiem niesamowite, to pozwala zachować Moduły utworzone specjalnie dla aplikacji ładnie z aplikacji, i nie zaśmiecać aplikacji zależności, które mogą być zainstalowane później.