skrypty

Opis

Właściwość "scripts" twojego pliku package.json obsługuje szereg wbudowanych skryptów i ich wstępnie ustawionych zdarzeń cyklu życia, a także skrypty dowolne. Wszystkie one mogą być wykonywane przez uruchomienie npm run-script <stage> lub npm run <stage> w skrócie. Polecenia przed i po o pasujących nazwach będą również uruchamiane dla tych skryptów (np. premyscript, myscript, postmyscript). Skrypty z zależności można uruchamiać za pomocą npm explore <pkg> -- npm run <stage>.

Skrypty Pre & Skrypty Post

Aby utworzyć skrypty „pre” lub „post” dla dowolnych skryptów zdefiniowanych w sekcji "scripts" w package.json, wystarczy utworzyć kolejny skrypt o pasującej nazwie i dodać „pre” lub „post” na ich początku.

 { 
 "scripts": { 
 "precompress": "{{ wykonuje się PRZED skryptem `compress` }}", 
 "compress": "{{ uruchamia komendę do kompresji plików }}", 
 "postcompress": "{{ wykonuje się PO skrypcie `compress` }}". 
 } 
 } 

Skrypty cyklu życia

Istnieją pewne specjalne skrypty cyklu życia, które występują tylko w pewnych sytuacjach. Te skrypty mają miejsce w dodatku do skryptu „pre” i „post”.

• prepare, prepublish, prepublishOnly, prepack, postpack

prepare (od [email protected])

• Uruchamia się PRZED spakowaniem pakietu
• Uruchamia się PRZED opublikowaniem pakietu
• Uruchamia się na lokalnym npm install bez żadnych argumentów
• Uruchamia się PO prepublish, ale PRZED prepublishOnly
• UWAGA: Jeśli pakiet instalowany przez git zawiera skrypt prepare, jego dependencies i devDependencies zostaną zainstalowane, a skrypt prepare zostanie uruchomiony, zanim pakiet zostanie spakowany i zainstalowany.

prepublish (DEPRECATED)

• Tak samo jak prepare

prepublishOnly

• Uruchamia się PRZED przygotowaniem i spakowaniem pakietu, TYLKO na npm publish.

prepack

• Uruchamia się PRZED spakowaniem tarballa (na „npm pack„, „npm publish„, i podczas instalacji zależności git).
• UWAGA: „npm run pack” NIE jest tym samym co „npm pack„. „npm run pack” jest arbitralną nazwą skryptu zdefiniowaną przez użytkownika, podczas gdy „npm pack” jest poleceniem zdefiniowanym przez CLI.

postpack

• Uruchamia się PO wygenerowaniu i przeniesieniu do ostatecznego miejsca docelowego pliku tarball.

Prepare and Prepublish

Deprecjacja Uwaga: prepublish

Od [email protected], npm CLI uruchamia skrypt prepublish zarówno dla npm publish, jak i npm install, ponieważ jest to wygodny sposób na przygotowanie pakietu do użycia (niektóre typowe przypadki użycia są opisane w sekcji poniżej). Okazało się również, że w praktyce jest to bardzo mylące. Począwszy od [email protected] wprowadzono nowe zdarzenie, prepare, które zachowuje to istniejące zachowanie. Nowe zdarzenie, prepublishOnly, zostało dodane jako strategia przejściowa, aby umożliwić użytkownikom uniknięcie mylącego zachowania istniejących wersji npm i uruchomienie tylko na npm publish (na przykład uruchomienie testów po raz ostatni, aby upewnić się, że są w dobrej formie).

Zobacz https://github.com/npm/npm/issues/10074 dla znacznie dłuższego uzasadnienia, z dalszą lekturą, dla tej zmiany.

Przypadki użycia

Jeśli potrzebujesz wykonać operacje na swoim pakiecie przed jego użyciem, w sposób, który nie jest zależny od systemu operacyjnego lub architektury systemu docelowego, użyj skryptu prepublish. Obejmuje to zadania takie jak:

• Kompilacja kodu źródłowego CoffeeScript do JavaScript.
• Tworzenie zminifikowanych wersji kodu źródłowego JavaScript.
• Pobieranie zdalnych zasobów, z których pakiet będzie korzystał.

Zaletą robienia tych rzeczy w prepublish czasie jest to, że można je zrobić raz, w jednym miejscu, co zmniejsza złożoność i zmienność. Dodatkowo oznacza to, że:

• Możesz polegać na coffee-script jako devDependency, a zatem Twoi użytkownicy nie muszą mieć go zainstalowanego.
• Nie musisz dołączać minifikatorów do swojego pakietu, zmniejszając rozmiar dla swoich użytkowników.
• Nie musisz polegać na tym, że Twoi użytkownicy mają curl lub wget lub inne narzędzia systemowe na maszynach docelowych.

Cykl życia Operacja Kolejność

npm publish

• prepublishOnly
• prepare

.

• prepublish
• publish
• postpublish

npm pack

• prepack
• postpack

npm install

• preinstall
• install
• postinstall

Wywołuje również

• . prepublish (gdy na lokalnym)
• prepare (gdy na lokalnym)

npm start

npm run start ma skrót npm start.

• prestart
• start
• poststart

Default Values

npm domyślnie ustawi niektóre wartości skryptu na podstawie zawartości pakietu.

• "start": "node server.js":

  Jeśli w korzeniu twojego pakietu znajduje się plik server.js, to npmwill domyślnie ustawi polecenie start na node server.js.

• "install": "node-gyp rebuild":

  Jeśli w korzeniu twojego pakietu znajduje się plik binding.gyp i nie zdefiniowałeś własnych skryptów install lub preinstall, npm domyślnie ustawi polecenie install na kompilację przy użyciu node-gyp.

User

Jeśli npm został wywołany z uprawnieniami roota, to zmieni uid na konto użytkownika lub uid określone przez user config, które domyślnie wynosi nobody. Ustaw flagę unsafe-perm, aby uruchamiać skrypty z uprawnieniami roota.

Środowisko

Skrypty pakietów są uruchamiane w środowisku, w którym udostępnianych jest wiele informacji dotyczących konfiguracji npm i bieżącego stanu procesu.

ścieżka

Jeśli jesteś zależny od modułów, które definiują skrypty wykonywalne, takie jak zestawy testów, to te pliki wykonywalne zostaną dodane do PATH przed wykonaniem skryptów. Tak więc, jeśli twój package.json ma to:

 { 
 "name" : "foo", 
 "dependencies" : { 
 "bar" : "0.1.x" 
 }, 
 "scripts": { 
 "start" : "bar ./test" 
 } 
 } 

także mógłbyś uruchomić npm start, aby wykonać skrypt bar, który jest eksportowany do katalogu node_modules/.bin na npm install.

package.json vars

Pola package.json są przyklejone do prefiksu npm_package_. Tak więc, na przykład, jeśli miałbyś {"name":"foo", "version":"1.2.5"} w swoim plikupackage.json, wtedy twoje skrypty pakietów miałybynpm_package_name zmienną środowiskową ustawioną na „foo”, anpm_package_version ustawioną na „1.2.5”. Możesz uzyskać dostęp do tych zmiennych w swoim kodzie za pomocą process.env.npm_package_name iprocess.env.npm_package_version, i tak dalej dla innych pól.

konfiguracja

Parametry konfiguracyjne są umieszczane w środowisku z prefiksemnpm_config_. Na przykład, można wyświetlić efektywną rootconfig przez sprawdzenie zmiennej środowiskowej npm_config_root.

Special: package.json „config” object

Klucze package.json „config” są nadpisywane w środowisku, jeślithere is a config param of <name>:<key>. Na przykład, jeśli package.json ma następującą postać:

 { 
 "name" : "foo", 
 "config" : { 
 "port" : "8080" 
 }, 
 "scripts" : { 
 "start" : "node server.js" 
 } 
 } 

a server.js jest taki:

 http.createServer(...).listen(process.env.npm_package_config_port) 

także użytkownik mógłby zmienić zachowanie wykonując:

 npm config set foo:port 80 

aktualne zdarzenie cyklu życia

Na koniec, zmienna środowiskowa npm_lifecycle_event jest ustawiona na dowolny etap cyklu. Możesz więc mieć jeden skrypt używany dla różnych części procesu, który przełącza się w oparciu o to, co się aktualnie dzieje.

Obiekty są spłaszczane zgodnie z tym formatem, więc jeśli miałbyś{"scripts":{"install":"foo.js"}} w swoim package.json, wtedy zobaczyłbyś to w skrypcie:

 process.env.npm_package_scripts_install == "foo.js" 

Przykłady

Na przykład, jeśli twój package.json zawiera to:

 { 
 "scripts" : { 
 "install" : "scripts/install.js", 
 "postinstall" : "scripts/install.js", 
 "uninstall" : "scripts/uninstall.js" 
 } 
 } 

to scripts/install.jsbędzie wywoływane dla etapów install i post-install cyklu życia, a scripts/uninstall.jsbędzie wywoływane, gdy pakiet jest odinstalowywany. Ponieważ scripts/install.js jest uruchamiany dla dwóch różnych faz, mądrze byłoby w tym przypadku spojrzeć na zmienną środowiskową npm_lifecycle_event.

Jeśli chcesz uruchomić polecenie make, możesz to zrobić. This works justfine:

 { 
 "scripts" : { 
 "preinstall" : "./configure", 
 "install" : "make && make install", 
 "test" : "make test" 
 } 
 } 

Wyjście

Skrypty są uruchamiane przez przekazanie linii jako argumentu skryptu do sh.

Jeśli skrypt wyjdzie z kodem innym niż 0, to spowoduje to przerwanieprocesu.

Zauważ, że te pliki skryptów nie muszą być programami nodejs lub nawetjavascript. Po prostu muszą być pewnego rodzaju plikami wykonywalnymi.

Skrypty hakowe

Jeśli chcesz uruchomić określony skrypt w określonym zdarzeniu cyklu życia dla WSZYSTKICH pakietów, możesz użyć skryptu hakowego.

Zamieść plik wykonywalny w node_modules/.hooks/{eventname}, a zostanie on uruchomiony dla wszystkich pakietów, gdy przechodzą przez ten punkt w cyklu życia pakietu dla wszystkich pakietów zainstalowanych w tym korzeniu.

Skrypty haków są uruchamiane dokładnie w taki sam sposób jak skrypty package.json.To znaczy, są w oddzielnym procesie potomnym, z env opisanym powyżej.

Najlepsze praktyki

• Nie wychodź z niezerowym kodem błędu, chyba że naprawdę masz to na myśli.Z wyjątkiem skryptów odinstalowujących, spowoduje to, że akcja npm nie powiedzie się i potencjalnie zostanie cofnięta. Jeśli niepowodzenie jest niewielkie lub tylko zapobiegnie niektórym opcjonalnym funkcjom, lepiej jest po prostu wydrukować ostrzeżenie i zakończyć pomyślnie.
• Staraj się nie używać skryptów do robienia tego, co npm może zrobić za ciebie. Przeczytaj przezpackage.json aby zobaczyć wszystkie rzeczy, które możesz określić i włączyć poprzez po prostu odpowiednie opisanie swojego pakietu. Ogólnie rzecz biorąc, doprowadzi to do bardziej solidnego i spójnego stanu.
• Sprawdź env, aby określić, gdzie umieścić rzeczy. Na przykład, jeśli zmienna środowiskowa npm_config_binroot jest ustawiona na /home/user/bin, to nie próbuj instalować plików wykonywalnych w /usr/local/bin. Użytkownik prawdopodobnie ustawił ją w ten sposób z jakiegoś powodu.
• Nie poprzedzaj poleceń skryptu słowem „sudo”. Jeśli z jakiegoś powodu wymagane są uprawnienia roota, to skrypt zakończy się niepowodzeniem z tym błędem, a użytkownik wykona polecenie sudo npm, o którym mowa.
• Nie używaj install. Użyj pliku .gyp do kompilacji, a prepublish do wszystkiego innego. Prawie nigdy nie powinieneś mieć potrzeby jawnego ustawiania skryptu apreinstall lub install. Jeśli to robisz, zastanów się, czy jest inna opcja. Jedyne poprawne użycie install lub preinstallskryptów jest dla kompilacji, która musi być wykonana na docelowej architekturze.

Zobacz także

• npm run-script
• package.json
• npm developers
• npm install