scripts

Descriere

Proprietatea "scripts" a fișierului package.json acceptă un număr de scripturi încorporate și evenimentele predefinite ale ciclului de viață ale acestora, precum și scripturi arbitrare. Toate acestea pot fi executate prin rularea npm run-script <stage> sau, pe scurt, npm run <stage>. Comenzile pre și post cu nume corespunzătoare vor fi rulate și pentru acestea (de exemplu, premyscript, myscript, postmyscript). Scripturile din dependențe pot fi rulate cu npm explore <pkg> -- npm run <stage>.

Pre & Post Scripturi

Pentru a crea scripturi „pre” sau „post” pentru orice script definit în secțiunea "scripts" din package.json, este suficient să creați un alt script cu un nume corespunzător și să adăugați „pre” sau „post” la începutul lor.

 { 
 "scripturi": { 
 "precompress": "{{ se execută ÎNAINTE de scriptul `compress` }}}", 
 "compress": "{{ execută comanda pentru a comprima fișierele }}}", 
 "postcompress": "{{se execută DUPĂ scriptul `compress` }}" 
 } 
 } 

Scripturi din ciclul de viață

Există unele scripturi speciale din ciclul de viață care se întâmplă numai în anumite situații. Aceste scripturi se întâmplă în plus față de scripturile „pre” și „post”.

• prepare, prepublish, prepublishOnly, prepack, postpack

prepare (de la [email protected])

• Se execută ÎNAINTE ca pachetul să fie împachetat
• Se execută ÎNAINTE ca pachetul să fie publicat
• Se execută pe local npm install fără nici un argument
• Se execută DUPĂ prepublish, dar ÎNAINTE de prepublishOnly
• NOTA: Dacă un pachet care se instalează prin git conține un script prepare, vor fi instalate dependencies și devDependencies ale acestuia, iar scriptul de pregătire va fi rulat, înainte ca pachetul să fie împachetat și instalat.

prepublish (DEPRECATED)

• Identic cu prepare

prepublishOnly

• Se execută ÎNAINTE ca pachetul să fie pregătit și împachetat, NUMAI pe npm publish.

prepack

• Se execută ÎNAINTE ca un tarball să fie împachetat (pe „npm pack„, „npm publish” și când se instalează o dependență git).
• NOTA: „npm run pack” NU este același lucru cu „npm pack„. „npm run pack” este un nume de script arbitrar definit de utilizator, în timp ce, „npm pack” este o comandă definită de CLI.

postpack

• Se execută DUPĂ ce tarball-ul a fost generat și mutat la destinația sa finală.

Pregătiți și prepublicați

Depreciere Notă: prepublish

De la [email protected], npm CLI a rulat scriptul prepublish atât pentru npm publish cât și pentru npm install, deoarece este o modalitate convenabilă de a pregăti un pachet pentru utilizare (unele cazuri de utilizare comune sunt descrise în secțiunea de mai jos). De asemenea, s-a dovedit a fi, în practică, foarte confuz. Începând cu [email protected], a fost introdus un nou eveniment, prepare, care păstrează acest comportament existent. Un nou eveniment, prepublishOnly, a fost adăugat ca strategie de tranziție pentru a permite utilizatorilor să evite comportamentul confuz al versiunilor npm existente și să ruleze doar pe npm publish (de exemplu, rulând testele pentru ultima dată pentru a se asigura că sunt în formă bună).

Vezi https://github.com/npm/npm/issues/10074 pentru o justificare mult mai lungă, cu lecturi suplimentare, pentru această schimbare.

Cazuri de utilizare

Dacă aveți nevoie să efectuați operații asupra pachetului dumneavoastră înainte ca acesta să fie utilizat, într-un mod care nu depinde de sistemul de operare sau de arhitectura sistemului țintă, utilizați un script prepublish. Aceasta include sarcini cum ar fi:

• Compilarea codului sursă CoffeeScript în JavaScript.
• Crearea de versiuni minificate ale codului sursă JavaScript.
• Căutarea resurselor de la distanță pe care pachetul dvs. le va utiliza.

Vantajul de a face aceste lucruri în momentul prepublish este că ele pot fi făcute o singură dată, într-un singur loc, reducând astfel complexitatea și variabilitatea. În plus, acest lucru înseamnă că:

• Puteți depinde de coffee-script ca un devDependency și, astfel, utilizatorii dvs. nu trebuie să îl aibă instalat.
• Nu trebuie să includeți minificatoare în pachetul dvs., reducând dimensiunea pentru utilizatori.
• Nu trebuie să vă bazați pe faptul că utilizatorii dvs. au curl sau wget sau alte instrumente de sistem pe mașinile țintă.

Ordinea de funcționare a ciclului de viață

npm publish

• prepublishOnly
• prepare

.

• prepublish
• publish
• postpublish

npm pack

• prepack
• postpack

npm install

• preinstall
• install
• postinstall

De asemenea, declanșează

• . prepublish (când pe local)
• prepare (când pe local)

npm start

npm run start are o prescurtare npm start.

• prestart
• start
• poststart

Valori implicite

npm va introduce în mod implicit unele valori de script pe baza conținutului pachetului.

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

  Dacă există un fișier server.js în rădăcina pachetului dumneavoastră, atunci npm va prestabili comanda start la node server.js.

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

  Dacă există un fișier binding.gyp în rădăcina pachetului dumneavoastră și nu ați definit propriile scripturi install sau preinstall, npm vacompila implicit comanda install pentru a compila folosind node-gyp.

Utilizator

Dacă npm a fost invocat cu privilegii de root, atunci va schimba uidulîn contul de utilizator sau uid-ul specificat de configurația user, care are ca valoare implicită nobody. Setați stegulețul unsafe-perm pentru a rula scripturile cu privilegii de root.

Environment

Scripțiile de pachete se execută într-un mediu în care sunt puse la dispoziție multe informații cu privire la configurarea npm și la starea curentă a procesului.

path

Dacă depindeți de module care definesc scripturi executabile, cum ar fi testsuites, atunci acele executabile vor fi adăugate la PATH forexecuting the scripts. Deci, dacă package.json-ul dvs. are acest lucru:

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

atunci ați putea rula npm start pentru a executa scriptul bar, care esteexportat în directorul node_modules/.bin pe npm install.

package.json vars

Câmpurile din package.json sunt lipite de prefixul npm_package_. Astfel, de exemplu, dacă ați avea {"name":"foo", "version":"1.2.5"} în fișierulpackage.json, atunci scripturile dvs. de pachet ar avea variabila de mediunpm_package_name setată la „foo”, iar npm_package_version setată la „1.2.5”. Puteți accesa aceste variabileîn codul dumneavoastră cu process.env.npm_package_name șiprocess.env.npm_package_version, și așa mai departe pentru alte câmpuri.

configurare

Parametrii de configurare sunt introduși în mediu cu prefixulnpm_config_. De exemplu, puteți vizualiza rootconfigurarea efectivă verificând variabila de mediu npm_config_root.

Special: package.json „config” object

Celele „config” din package.json sunt suprascrise în mediu dacă există un parametru de configurare de <name>:<key>. De exemplu,dacă package.json are acest lucru:

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

și server.js este acesta:

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

atunci utilizatorul ar putea schimba comportamentul făcând:

 npm config set foo:port 80 

evenimentul actual al ciclului de viață

În cele din urmă, variabila de mediu npm_lifecycle_event este setată la orice etapă a ciclului care se execută. Astfel, ați putea avea un singur script utilizat pentru diferite părți ale procesului, care să comute în funcție de ceea ce se întâmplă în acel moment.

Obiectele sunt aplatizate urmând acest format, deci dacă ați avea{"scripts":{"install":"foo.js"}} în pachetul dvs.json, atunci ați vedea acest lucru în script:

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

Exemple

De exemplu, dacă package.json-ul dvs. conține acest lucru:

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

atunci scripts/install.js va fi apelat pentru etapele de instalareși post-instalare ale ciclului de viață, iar scripts/uninstall.jsva fi apelat atunci când pachetul este dezinstalat. Deoarecescripts/install.js se execută pentru două faze diferite, ar fi înțelept în acest caz să vă uitați la variabila de mediu npm_lifecycle_event.

Dacă doriți să executați o comandă make, o puteți face. Aceasta funcționează foarte bine:

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

Ieșire

Scriptele sunt rulate prin trecerea liniei ca argument de script la sh.

Dacă scriptul iese cu un alt cod decât 0, atunci acest lucru va anula procesul.

Rețineți că aceste fișiere de script nu trebuie să fie programe nodejs sau chiarjavascript. Ele trebuie doar să fie un fel de fișier executabil.

Scripturi cârlig

Dacă doriți să rulați un anumit script la un anumit eveniment al ciclului de viață pentru TOATE pachetele, atunci puteți folosi un script cârlig.

Puneți un fișier executabil la node_modules/.hooks/{eventname}, iar acesta va fi rulat pentru toate pachetele atunci când trec prin acel punctdin ciclul de viață al pachetelor pentru orice pachete instalate în acea rădăcină.

Scripturile hook sunt rulate exact în același mod ca și scripturile package.json.Adică, ele sunt într-un proces copil separat, cu mediul descris mai sus.

Cele mai bune practici

• Nu ieșiți cu un cod de eroare diferit de zero decât dacă sunteți foarte serios.Cu excepția scripturilor de dezinstalare, acest lucru va face ca acțiunea npm să nu reușească și, eventual, să fie anulată. Dacă eșecul este minor sau doar va împiedica unele caracteristici opționale, atunci este mai bine să imprimați doar un avertisment și să ieșiți cu succes.
• Încercați să nu folosiți scripturi pentru a face ceea ce npm poate face pentru dumneavoastră. Citițipackage.json pentru a vedea toate lucrurile pe care le puteți specifica și activa prin simpla descriere corespunzătoare a pachetului dvs. În general, acest lucru va duce la o stare mai robustă și mai consistentă.
• Inspectați environmentul pentru a determina unde să puneți lucrurile. De exemplu, dacăvariabila de mediu npm_config_binroot este setată la /home/user/bin, atuncinu încercați să instalați executabile în /usr/local/bin. Utilizatorulprobabil că a setat-o astfel dintr-un motiv anume.
• Nu prefixați comenzile de script cu „sudo”. Dacă din anumite motive sunt necesare permisiuni de root, atunci va eșua cu această eroare, iar utilizatorul va sudo comanda npm în cauză.
• Nu folosiți install. Folosiți un fișier .gyp pentru compilare, și prepublishpentru orice altceva. Aproape niciodată nu ar trebui să trebuiască să setați explicit apreinstall sau scriptul de instalare. Dacă faceți acest lucru, vă rugăm să luați în considerare dacăexistă o altă opțiune. Singura utilizare validă a scripturilor install sau preinstall este pentru compilare, care trebuie să se facă pe arhitectura țintă.

Vedeți și

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

.