scripts
Il Dicembre 17, 2021 da adminDescrizione
La proprietà "scripts"
del vostro file package.json
supporta un certo numero di script incorporati e i loro eventi preimpostati del ciclo di vita così come script arbitrari. Tutti questi possono essere eseguiti eseguendo npm run-script <stage>
o npm run <stage>
in breve. Verranno eseguiti anche i comandi pre e post con nomi corrispondenti (ad esempio premyscript
, myscript
, postmyscript
). Gli script dalle dipendenze possono essere eseguiti con npm explore <pkg> -- npm run <stage>
.
Pre & Post Scripts
Per creare script “pre” o “post” per qualsiasi script definito nella sezione "scripts"
del package.json
, basta creare un altro script con un nome corrispondente e aggiungere “pre” o “post” all’inizio di essi.
{"scripts": {"precompressione": "{{ esegue PRIMA dello script `compress` }}","compress": "{{ esegue il comando per comprimere i file }}","postcompressione": "{{ esegue DOPO lo script `compress` }}"}}
Script del ciclo di vita
Ci sono alcuni script speciali del ciclo di vita che avvengono solo in certe situazioni. Questi script avvengono in aggiunta agli script “pre” e “post”.
-
prepare
,prepublish
,prepublishOnly
,prepack
,postpack
prepare (da [email protected]
)
- Esegue PRIMA che il pacchetto sia impacchettato
- Esegue PRIMA che il pacchetto sia pubblicato
- Esegue in locale
npm install
senza argomenti - Esegue DOPO
prepublish
, ma PRIMA diprepublishOnly
- NOTE: Se un pacchetto da installare tramite git contiene uno script
prepare
, i suoidependencies
edevDependencies
saranno installati, e lo script prepare sarà eseguito, prima che il pacchetto sia impacchettato e installato.
prepublish (DEPRECATED)
- Come
prepare
prepublishOnly
- Esegue PRIMA che il pacchetto sia preparato e impacchettato, SOLO su
npm publish
.
prepack
- Esegue PRIMA che un tarball sia impacchettato (su “
npm pack
“, “npm publish
“, e quando si installa una dipendenza git). - NOTA: “
npm run pack
” NON è lo stesso di “npm pack
“. “npm run pack
” è un nome di script arbitrario definito dall’utente, mentre “npm pack
” è un comando definito dalla CLI.
postpack
- Esegue dopo che il tarball è stato generato e spostato nella sua destinazione finale.
Prepare and Prepublish
Nota di eliminazione: prepublish
Da [email protected]
, la CLI di npm ha eseguito lo script prepublish
sia per npm publish
che per npm install
, perché è un modo conveniente per preparare un pacchetto all’uso (alcuni casi d’uso comuni sono descritti nella sezione seguente). Si è anche rivelato, in pratica, molto confuso. A partire da [email protected]
, è stato introdotto un nuovo evento, prepare
, che conserva questo comportamento esistente. Un nuovo evento, prepublishOnly
è stato aggiunto come strategia di transizione per permettere agli utenti di evitare il comportamento confuso delle versioni esistenti di npm e di eseguire solo su npm publish
(per esempio, eseguendo i test un’ultima volta per assicurarsi che siano in buona forma).
Vedi https://github.com/npm/npm/issues/10074 per una giustificazione molto più lunga, con ulteriori letture, per questo cambiamento.
Casi d’uso
Se hai bisogno di eseguire operazioni sul tuo pacchetto prima che venga usato, in un modo che non dipenda dal sistema operativo o dall’architettura del sistema di destinazione, usa uno script prepublish
. Questo include compiti come:
- Compilazione del codice sorgente CoffeeScript in JavaScript.
- Creazione di versioni minificate del codice sorgente JavaScript.
- Ricerca di risorse remote che il tuo pacchetto userà.
Il vantaggio di fare queste cose al tempo di prepublish
è che possono essere fatte una volta sola, in un unico posto, riducendo così la complessità e la variabilità. Inoltre, questo significa che:
- Puoi dipendere da
coffee-script
come undevDependency
, e quindi i tuoi utenti non hanno bisogno di averlo installato. - Non hai bisogno di includere minificatori nel tuo pacchetto, riducendo la dimensione per i tuoi utenti.
- Non hai bisogno di contare sul fatto che i tuoi utenti abbiano
curl
owget
o altri strumenti di sistema sulle macchine di destinazione.
Ordine del ciclo di vita
npm publish
prepublishOnly
prepare
prepublish
publish
postpublish
npm pack
prepack
postpack
npm install
preinstall
install
postinstall
Innesca anche
-
prepublish
(quando in locale) -
prepare
(quando in locale)
npm start
npm run start
ha una stenografia npm start
.
prestart
start
poststart
Valori predefiniti
npm imposterà alcuni valori di script in base al contenuto del pacchetto.
-
"start": "node server.js"
:Se c’è un file
server.js
nella root del tuo pacchetto, allora npmwill imposterà il comandostart
anode server.js
. -
"install": "node-gyp rebuild"
:Se c’è un file
binding.gyp
nella radice del tuo pacchetto e non hai definito i tuoi scriptinstall
opreinstall
, npm imposterà il comandoinstall
per compilare usando node-gyp.
User
Se npm è stato invocato con i privilegi di root, allora cambierà l’uid nell’account utente o nell’uid specificato dalla configurazione user
, che per default è nobody
. Impostare il flag unsafe-perm
per eseguire gli script con i privilegi di root.
Ambiente
Gli script dei pacchetti vengono eseguiti in un ambiente in cui vengono rese disponibili molte informazioni riguardanti la configurazione di npm e lo stato attuale del processo.
percorso
Se si dipende da moduli che definiscono script eseguibili, come testsuites, allora questi eseguibili verranno aggiunti al PATH
per l’esecuzione degli script. Quindi, se il tuo package.json ha questo:
{"name" : "foo","dependencies" : {"bar" : "0.1.x"},"scripts": {"start" : "bar ./test"}}
allora potresti eseguire npm start
per eseguire lo script bar
, che viene esportato nella directory node_modules/.bin
su npm install
.
package.json vars
I campi del package.json sono attaccati al prefisso npm_package_
. Così, per esempio, se tu avessi {"name":"foo", "version":"1.2.5"}
nel tuo filepackage.json, allora i tuoi script di pacchetto avrebbero la variabile d’ambientenpm_package_name
impostata su “pippo”, e lanpm_package_version
impostata su “1.2.5”. Puoi accedere a queste variabili nel tuo codice con process.env.npm_package_name
eprocess.env.npm_package_version
, e così via per altri campi.
configurazione
I parametri di configurazione sono messi nell’ambiente con il prefissonpm_config_
. Per esempio, puoi vedere l’effettiva root
config controllando la variabile d’ambiente npm_config_root
.
Speciale: oggetto package.json “config”
Le chiavi package.json “config” sono sovrascritte nell’ambiente se c’è un parametro config di <name>:<key>
. Per esempio, se il package.json ha questo:
{"name" : "foo","config" : {"port" : "8080"},"scripts" : {"start" : "node server.js"}}
e il server.js è questo:
http.createServer(...).listen(process.env.npm_package_config_port)
allora l’utente potrebbe cambiare il comportamento facendo:
npm config set foo:port 80
evento del ciclo di vita corrente
Infine, la variabile d’ambiente npm_lifecycle_event
è impostata a qualsiasi fase del ciclo venga eseguita. Quindi, si potrebbe avere un unico script usato per diverse parti del processo che cambia in base a ciò che sta accadendo al momento.
Gli oggetti sono appiattiti seguendo questo formato, quindi se avete{"scripts":{"install":"foo.js"}}
nel vostro pacchetto.json, allora vedresti questo nello script:
process.env.npm_package_scripts_install === "foo.js"
Esempi
Per esempio, se il tuo package.json contiene questo:
{"scripts" : {"install" : "scripts/install.js","postinstall" : "scripts/install.js","uninstall" : "scripts/uninstall.js"}}
allora scripts/install.js
sarà chiamato per le fasi di installazione e post-installazione del ciclo di vita, e scripts/uninstall.js
sarà chiamato quando il pacchetto è disinstallato. Poichéscripts/install.js
viene eseguito per due fasi diverse, sarebbe saggio in questo caso guardare la variabile d’ambiente npm_lifecycle_event
.
Se volete eseguire un comando make, potete farlo. Questo funziona benissimo:
{"scripts" : {"preinstall" : "./configure","install" : "make && make install","test" : "make test"}}
Uscita
Gli script vengono eseguiti passando la linea come argomento di script a sh
.
Se lo script esce con un codice diverso da 0, allora questo interromperà il processo.
Nota che questi file di script non devono essere necessariamente programmi nodejs o javascript. Devono solo essere qualche tipo di file eseguibile.
Script Hook
Se vuoi eseguire uno script specifico in un evento specifico del ciclo di vita per TUTTI i pacchetti, allora puoi usare uno script hook.
Posiziona un file eseguibile a node_modules/.hooks/{eventname}
, e verrà eseguito per tutti i pacchetti quando passano attraverso quel punto nel ciclo di vita del pacchetto per qualsiasi pacchetto installato in quella root.
Gli script hook sono eseguiti esattamente allo stesso modo degli script package.json, cioè in un processo figlio separato, con l’env descritto sopra.
Migliori pratiche
- Non uscire con un codice di errore diverso da zero a meno che tu non lo intenda veramente.Tranne che per gli script di disinstallazione, questo causerà il fallimento dell’azione di npm, e potenzialmente il rollback. Se l’errore è minore o impedisce solo alcune funzioni opzionali, allora è meglio stampare un avvertimento e uscire con successo.
- Prova a non usare script per fare ciò che npm può fare per te. Leggete
package.json
per vedere tutte le cose che potete specificare e abilitare semplicemente descrivendo il vostro pacchetto in modo appropriato. In generale, questo porterà ad uno stato più robusto e coerente. - Ispeziona l’env per determinare dove mettere le cose. Per esempio, se la variabile d’ambiente
npm_config_binroot
è impostata su/home/user/bin
, non cercare di installare gli eseguibili in/usr/local/bin
. Probabilmente l’utente l’ha impostata in quel modo per una ragione. - Non fate precedere i vostri comandi di script da “sudo”. Se i permessi di root sono richiesti per qualche motivo, allora fallirà con quell’errore, e l’utente eseguirà il comando npm in questione.
- Non usare
install
. Usate un file.gyp
per la compilazione, eprepublish
per qualsiasi altra cosa. Non dovreste quasi mai dover impostare esplicitamente apreinstall o script di installazione. Se lo stai facendo, considera se c’è un’altra opzione. L’unico uso valido diinstall
opreinstall
script è per la compilazione che deve essere fatta sull’architettura di destinazione.
Vedi anche
- npm run-script
- package.json
- npm developers
- npm install
Lascia un commento