Czy powinienem zameldować się w module node_modules, aby uruchomić git podczas tworzenia aplikacji node.js na Heroku?

Postępowałem zgodnie z podstawowymi instrukcjami dotyczącymi uruchamiania pliku node.js na Heroku tutaj:

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

Te instrukcje nie nakazują tworzenia .gitignore node_modules, a zatem sugerują, że moduły node_modu powinny być zalogowane do git. Po dołączeniu do węzła modułów w git moja aplikacja dla początkujących działała poprawnie.

Kiedy poszedłem za bardziej zaawansowanym przykładem:

https://devcenter.heroku.com/articles/realtime-polyglot-app-node-ruby-mongodb-socketio https://github.com/mongolab/tractorpush-server (źródło)

Polecił mi dodać węzeł_modules do .gitignore. Więc usunąłem node_modules z git, dodałem go do .gitignore, a następnie ponownie wdrożyłem. Tym razem wdrożenie się nie powiodło:

-----> 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: node@0.4 || 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: node@0.4 || 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

Uruchomienie „heroku ps” potwierdza awarię. Ok, nie ma problemu, więc wycofałem zmianę, dodałem node_module z powrotem do repozytorium git i usunąłem go z .gitignore. Jednak nawet po przywróceniu nadal pojawia się ten sam komunikat o błędzie podczas wdrażania, ale teraz aplikacja działa ponownie poprawnie. Uruchomienie „heroku ps” mówi mi, że aplikacja jest uruchomiona.

Więc moje pytanie brzmi: jaki jest właściwy sposób to zrobić? Uwzględnić moduły_węzła czy nie? I dlaczego nadal pojawia się komunikat o błędzie podczas wycofywania? Domyślam się, że repozytorium git jest w złym stanie po stronie Heroku?

Druga aktualizacja

FAQ nie jest już dostępne.

Z dokumentacji shrinkwrap:

Jeśli chcesz zablokować określone bajty zawarte w pakiecie, na przykład aby mieć 100% pewności co do możliwości odtworzenia wdrożenia lub kompilacji, powinieneś sprawdzić swoje zależności w kontroli źródła lub zastosować inny mechanizm, który może zweryfikować treść zamiast wersji.

Shannon i Steven wspomnieli o tym wcześniej, ale myślę, że powinna być częścią przyjętej odpowiedzi.

Aktualizacja

Źródło wymienione dla poniższej rekomendacji zostało zaktualizowane . Nie zalecają już zatwierdzenia node_modulesfolderu.

Zwykle nie. Pozwól npm na rozwiązanie zależności dla twoich pakietów.

W przypadku wdrożonych pakietów, takich jak strony internetowe i aplikacje, należy użyć npm shrinkwrap, aby zablokować pełne drzewo zależności:

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

Oryginalny post

Dla odniesienia, npm FAQ wyraźnie odpowiada na twoje pytanie:

Sprawdź node_modules w git dla rzeczy, które wdrażasz, takich jak strony internetowe i aplikacje. Nie sprawdzaj modułów node_module w git dla bibliotek i modułów przeznaczonych do ponownego użycia. Użyj npm do zarządzania zależnościami w środowisku deweloperskim, ale nie w skryptach wdrażania.

i dla dobrego uzasadnienia, przeczytaj post Mikeala Rogersa na ten temat .

Źródło: https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git

Moim największym problemem ze nie sprawdzając node_modulesw git jest to, że 10 lat w dół drogi, gdy aplikacja produkcja jest nadal w użyciu, może być npm dookoła. Lub npm może ulec uszkodzeniu; lub opiekunowie mogą zdecydować o usunięciu biblioteki, na której polegasz, z ich repozytorium; lub używana wersja może zostać obcięta.

Można to złagodzić za pomocą menedżerów repozytoriów, takich jak maven, ponieważ zawsze możesz użyć własnego lokalnego Nexusa lub Artifactory do utrzymania kopii lustrzanej za pomocą używanych pakietów. 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 pliki zostały przypisane do własnego repozytorium git, możesz je zaktualizować, kiedy chcesz, i masz komfort powtarzalnych kompilacji oraz wiedzę, że Twoja aplikacja nie ulegnie awarii z powodu działań innych firm.

Należy nie zawierają node_modules w swojej .gitignore(lub raczej ty powinien zawierać node_modules w swoim źródle rozmieszczonych Heroku).

Jeżeli node_modules:

• istnieje, a następnie npm installużyje tych bibliotek lib i odbuduje wszelkie zależności binarne npm rebuild.
• nie istnieje, wówczas npm installbędzie musiał pobrać wszystkie zależności, co wydłuży czas kompilacji ślimaka.

Zobacz źródło kompilacji Node.js, aby uzyskać dokładne instrukcje

Jednak pierwotny błąd wygląda na niezgodność między wersjami npmi node. Dobrym pomysłem jest zawsze jawne ustawianie enginessekcji packages.jsonzgodnie z tym przewodnikiem, aby uniknąć tego rodzaju sytuacji:

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

Zapewni to parytet tworzenia / produkcji i zmniejszy prawdopodobieństwo takich sytuacji w przyszłości.

Zamierzałem zostawić to po tym komentarzu: Czy powinienem zameldować się w node_modules, aby git podczas tworzenia aplikacji node.js na Heroku?

Ale przepełnienie stosu formatowało to dziwnie. Jeśli nie masz identycznych maszyn i sprawdzasz w module node_modules, zrób .gitignore na rozszerzeniach natywnych. Nasz .gitignore wygląda następująco:

# 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

Sprawdź to, najpierw sprawdzając wszystko, a następnie poproś innego programistę 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.

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

Z drugiej strony, node_modulesnie należy popełniać na git. Poza dużymi rozmiarami, commits, w tym również, mogą stać się rozpraszające.

Najlepsze rozwiązania byłyby następujące: npm installpowinny działać w środowisku CI podobnym do środowiska produkcyjnego. Wszystkie testy zostaną uruchomione i zostanie utworzony skompresowany plik wydania, który będzie zawierał wszystkie zależności.

Używałem zarówno zatwierdzania folderu node_modules, jak i zawijania. Oba rozwiązania nie sprawiły mi radości.

W skrócie: zatwierdzone moduły node_dodają zbyt dużo szumów do repozytorium.
Plik shrinkwrap.json nie jest łatwy do zarządzania i nie ma gwarancji, że jakiś projekt owinięty w folię zostanie zbudowany za kilka lat.

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

Tak więc nie zajęło mi dużo czasu wdrożenie tego pomysłu w narzędziu CLI węzła https://github.com/bestander/npm-git-lock

Tuż przed każdą kompilacją dodaj
npm-git-lock --repo [git@bitbucket.org: your / dedykowane / node_modules / git / repository.git]

Obliczy skrót pakietu.json i albo sprawdzi zawartość node_modules ze zdalnego repozytorium, albo, jeśli jest to pierwsza kompilacja tego pakietu.json, wykona czyszczenie npm installi przekaże wyniki do zdalnego repozytorium.

To, co zadziałało, to jawne dodanie wersji npm do package.json („npm”: „1.1.x”) i NIE sprawdzanie modułów node_mules do git. Wdrożenie może być wolniejsze (ponieważ pobiera pakiety za każdym razem), ale nie mogłem zmusić pakietów do skompilowania, gdy były zalogowane. Heroku szukał plików, które istniały tylko na moim lokalnym komputerze.

Zamiast sprawdzać w module node_modules, utwórz plik package.json dla swojej aplikacji.

Plik package.json określa zależności aplikacji. Heroku może następnie powiedzieć npm, aby zainstalował wszystkie te zależności. Samouczek, do którego prowadzisz link, zawiera sekcję dotyczącą plików package.json.

Korzystam z tego rozwiązania:

1. Utwórz osobne repozytorium, które będzie przechowywane node_modules. Jeśli masz natywne moduły, które powinny być budowane 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

3. Utwórz link z katalogu specyficznego node_modulesdla platformy node_modulesi dodaj node_modulesdo .gitignore.
4. Uruchom npm install.
5. Zatwierdź zmiany w repozytorium submodułu.
6. Zatwierdź zmiany w repozytorium projektu.

Możesz więc łatwo przełączać się między node_modulesróżnymi platformami (na przykład, jeśli tworzysz system OS X i wdrażasz system Linux).

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

Edycja: oryginalny link był ten, ale jest już martwy. Dzięki @Flavio za zwrócenie na to uwagi.

Przypomnę.

• Sprawdzaj tylko moduły node_ododu dla aplikacji, które wdrażasz, a nie pakiety wielokrotnego użytku, które utrzymujesz.
• Wszelkie skompilowane zależności powinny mieć zarejestrowane źródło, a nie cele kompilacji i powinny zostać odbudowane npm $ przy wdrażaniu.

Moja ulubiona część:

Wszyscy, którzy dodaliście node_modules do swojego gitignore, usuńcie to gówno, dziś jest to artefakt ery, z której zbyt chętnie zostawiamy. Era globalnych modułów jest martwa.

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

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

Jeśli nie zostanie tam znaleziony, zostanie przeniesiony do katalogu nadrzędnego i tak dalej , dopóki nie zostanie osiągnięty katalog główny drzewa.

Jeśli wdrażasz własne moduły specyficzne dla aplikacji, możesz przechowywać te ( i tylko te ) w swojej aplikacji /node_modules. I przenieś wszystkie pozostałe zależności do katalogu nadrzędnego.

Ten przypadek użycia jest całkiem niesamowity, pozwala zachować moduły stworzone specjalnie dla Twojej aplikacji i nie zaśmieca aplikacji zależnością, którą można zainstalować później.

scenariusz 1:

Jeden scenariusz: używasz pakietu, który jest usuwany z npm. Jeśli masz wszystkie moduły w folderze node_modules, nie będzie to dla ciebie problemem. Jeśli masz tylko nazwę pakietu w pliku package.json, nie możesz go już uzyskać. Jeśli paczka ma mniej niż 24 godziny, możesz ją łatwo usunąć z npm. Jeśli jest starszy niż 24 godziny, musisz się z nim skontaktować. Ale:

Jeśli skontaktujesz się z pomocą techniczną, sprawdzi, czy usunięcie tej wersji pakietu nie spowoduje awarii innych instalacji. Jeśli tak, nie usuniemy go.

Czytaj więcej

Szanse na to są niskie, ale jest scenariusz 2 ...

scenariusz 2:

Inny scenariusz, w którym tak jest: Tworzysz wersję korporacyjną oprogramowania lub bardzo ważne oprogramowanie i piszesz w pakiecie.json:

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

Używasz metody function1(x)tego pakietu.

Teraz twórcy pakietu studpid zmieniają nazwę metody function1(x)na function2(x)i popełniają błąd ... Zmieniają wersję swojego pakietu z 1.0.1na 1.1.0. Jest to problem, ponieważ przy npm installnastępnym wywołaniu zaakceptujesz wersję, 1.1.0ponieważ użyłeś tyldy ( "studpid-package": "~1.0.1").

Dzwonienie function1(x)może teraz powodować błędy i problemy.

Przeniesienie całego folderu node_modules (często ponad 100 MB) do repozytorium będzie kosztować miejsce w pamięci. Kilka KB (tylko pakiet.json) w porównaniu z setkami MB (pakiet.json i moduły_węzła) ... Pomyśl o tym.

Możesz to zrobić / powinieneś o tym pomyśleć, jeśli:

• oprogramowanie jest bardzo ważne.

• kosztuje Cię pieniądze, gdy coś zawiedzie.

• nie ufasz rejestrowi npm. npm jest scentralizowany i teoretycznie może zostać zamknięty.

Nie musisz publikować folderu node_modules w 99,9% przypadków, jeśli:

• tworzysz oprogramowanie tylko dla siebie.

• coś zaprogramowałeś i po prostu chcesz opublikować wynik na GitHub, ponieważ ktoś inny może być tym zainteresowany.

Jeśli nie chcesz, aby moduły node_module znajdowały się w twoim repozytorium, po prostu utwórz .gitignoreplik i dodaj linię node_modules.