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?
node_modules
melduj się w aplikacjach Heroku.Odpowiedzi:
Druga aktualizacja
FAQ nie jest już dostępne.
Z dokumentacji
shrinkwrap
: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_modules
folderu.Oryginalny post
Dla odniesienia, npm FAQ wyraźnie odpowiada na twoje pytanie:
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
źródło
.gitignore
? W ten sposób źródło jest w git, a żadne skompilowane komponenty nie są, podobnie jakdist
luboutput
foldery są gitignorowane w projektach typu chrząknięcie i przełknięcie.Moim największym problemem ze nie sprawdzając
node_modules
w 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.
źródło
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
:npm install
użyje tych bibliotek lib i odbuduje wszelkie zależności binarnenpm rebuild
.npm install
bę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
npm
inode
. Dobrym pomysłem jest zawsze jawne ustawianieengines
sekcjipackages.json
zgodnie z tym przewodnikiem, aby uniknąć tego rodzaju sytuacji:Zapewni to parytet tworzenia / produkcji i zmniejszy prawdopodobieństwo takich sytuacji w przyszłości.
źródło
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:
Sprawdź to, najpierw sprawdzając wszystko, a następnie poproś innego programistę o wykonanie następujących czynności:
Upewnij się, że żadne pliki nie uległy zmianie.
źródło
Uważam, że
npm install
nie 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_modules
nie 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 install
powinny 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.źródło
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 [[email protected]: 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 install
i przekaże wyniki do zdalnego repozytorium.źródło
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.
źródło
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.
źródło
Korzystam z tego rozwiązania:
node_modules
. Jeśli masz natywne moduły, które powinny być budowane dla konkretnej platformy, utwórz osobne repozytorium dla każdej platformy.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
node_modules
dla platformynode_modules
i dodajnode_modules
do.gitignore
.npm install
.Możesz więc łatwo przełączać się między
node_modules
różnymi platformami (na przykład, jeśli tworzysz system OS X i wdrażasz system Linux).źródło
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.
Moja ulubiona część:
źródło
http://nodejs.org/api/modules.html
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.
źródło
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:
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:
Używasz metody
function1(x)
tego pakietu.Teraz twórcy pakietu studpid zmieniają nazwę metody
function1(x)
nafunction2(x)
i popełniają błąd ... Zmieniają wersję swojego pakietu z1.0.1
na1.1.0
. Jest to problem, ponieważ przynpm install
następnym wywołaniu zaakceptujesz wersję,1.1.0
ponieważ 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
.gitignore
plik i dodaj linięnode_modules
.źródło