Salta al contenuto

Archivi

  • Gennaio 2022
  • Dicembre 2021
  • Novembre 2021
  • Ottobre 2021
  • Settembre 2021

Categorie

  • Nessuna categoria
Trend RepositoryArticles and guides
Articles

scripts

Il Dicembre 17, 2021 da admin
Tabella dei contenuti
  • Descrizione
  • Pre & Post Scripts
  • Script del ciclo di vita
  • Prepare and Prepublish
  • Ordine del ciclo di vita
  • npm publish
  • npm pack
  • npm install
  • npm start
  • Valori predefiniti
  • User
  • Ambiente
  • percorso
  • package.json vars
  • configurazione
  • Speciale: oggetto package.json “config”
  • evento del ciclo di vita corrente
  • Esempi
  • Uscita
  • Script Hook
  • Migliori pratiche
  • Vedi anche

Descrizione

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 di prepublishOnly
  • NOTE: Se un pacchetto da installare tramite git contiene uno script prepare, i suoi dependencies e devDependencies 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 un devDependency, 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 o wget 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 comando start a node server.js.

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

    Se c’è un file binding.gyp nella radice del tuo pacchetto e non hai definito i tuoi script install o preinstall, npm imposterà il comando install 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 rootconfig 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. Leggetepackage.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, e prepublish 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 di install o preinstallscript è 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 Annulla risposta

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Archivi

  • Gennaio 2022
  • Dicembre 2021
  • Novembre 2021
  • Ottobre 2021
  • Settembre 2021

Meta

  • Accedi
  • Feed dei contenuti
  • Feed dei commenti
  • WordPress.org
  • DeutschDeutsch
  • NederlandsNederlands
  • SvenskaSvenska
  • DanskDansk
  • EspañolEspañol
  • FrançaisFrançais
  • PortuguêsPortuguês
  • ItalianoItaliano
  • RomânăRomână
  • PolskiPolski
  • ČeštinaČeština
  • MagyarMagyar
  • SuomiSuomi
  • 日本語日本語

Copyright Trend Repository 2022 | Tema da ThemeinProgress | Offerto orgogliosamente da WordPress