Articles

scripts

On Dezembro 17, 2021 by
Tabela de conteúdos

Descrição

A "scripts" propriedade do seu ficheiro package.json suporta uma série de scripts incorporados e os seus eventos de ciclo de vida predefinidos, bem como scripts arbitrários. Todos estes podem ser executados executando npm run-script <stage> ou npm run <stage> para abreviar. Comandos pré e pós com nomes correspondentes também serão executados para aqueles (por exemplo premyscript, myscript, postmyscript). Scripts de dependências podem ser executados com npm explore <pkg> -- npm run <stage>.

Pre & Post Scripts

Para criar scripts “pre” ou “post” para quaisquer scripts definidos na seção "scripts" do package.json, basta criar outro script com um nome correspondente e adicionar “pre” ou “post” ao início deles.

 { 
 "scripts": { 
 "pré-compressão": "{{Executa ANTES do script `comprimir` }}", 
 "comprimir": "{{{executar comando para comprimir ficheiros }}", 
 "pós-compressão": "{{{ executa DEPOIS do script `compress` }}" 
 } 
 } 
>573737>

Scripts de Ciclo de Vida

Existem alguns scripts especiais de ciclo de vida que acontecem apenas em determinadas situações. Estes scripts acontecem em adição ao script “pré” e “post”.

  • prepare, prepublish, prepublishOnly, prepack, postpack

preparar (desde [email protected])

  • Executar ANTES que a embalagem seja embalada
  • Executar ANTES que a embalagem seja publicada
  • Executar no local npm install sem qualquer argumento
  • Executar DEPOIS prepublish, mas ANTES prepublishOnly
  • NOTE: Se um pacote sendo instalado através do git contém um script prepare, seus dependencies e devDependencies serão instalados, e o script prepare será executado, antes que o pacote seja empacotado e instalado.

prepublicar (DEPRECADO)

  • O mesmo que prepare

prepublicarApenas

  • Executar ANTES que o pacote seja preparado e embalado, SOMENTE em npm publish.

prepack

  • Executar ANTES que uma tarball seja embalada (em “npm pack“, “npm publish“, e ao instalar uma dependência git).
  • NOTE: “npm run pack” NÃO é o mesmo que “npm pack“. “npm run pack” é um nome de script arbitrário definido pelo usuário, onde como, “npm pack” é um comando definido pela CLI.

postpack

  • Executar após o tarball ter sido gerado e movido para o seu destino final.

Preparar e Pré-publicar

Depreciação Nota: pré-publicar

Desde [email protected], o npm CLI executou o script prepublish tanto para npm publish como para npm install, porque é uma forma conveniente de preparar um pacote para uso (alguns casos de uso comum são descritos na seção abaixo). Também tem se mostrado, na prática, muito confuso. A partir de [email protected], um novo evento foi introduzido, prepare, que preserva este comportamento existente. Um novo evento, prepublishOnly foi adicionado como uma estratégia de transição para permitir aos usuários evitar o comportamento confuso das versões npm existentes e rodar apenas em npm publish (por exemplo, rodar os testes uma última vez para garantir que eles estão em boa forma).

Veja https://github.com/npm/npm/issues/10074 para uma justificação muito mais longa, com leitura posterior, para esta alteração.

Use Cases

Se você precisar executar operações no seu pacote antes que ele seja usado, de uma forma que não seja dependente do sistema operacional ou da arquitetura do sistema alvo, use um script prepublish. Isto inclui tarefas como:

  • Compilar código fonte CoffeeScript em JavaScript.
  • Criar versões minificadas de código fonte JavaScript.
  • Recuperar recursos remotos que seu pacote irá usar.

A vantagem de fazer estas coisas em prepublish tempo é que elas podem ser feitas uma vez, em um único lugar, reduzindo assim a complexidade e variabilidade. Adicionalmente, isto significa que:

  • Você pode depender de coffee-script como um devDependency, e assim seus usuários não precisam tê-lo instalado.
  • Você não precisa incluir minificadores em seu pacote, reduzindo o tamanho para seus usuários.
  • Você não precisa confiar que seus usuários tenham curl ou wget ou outras ferramentas de sistema nas máquinas alvo.

Ordem de operação do ciclo de vida

npm publish

  • prepublishOnly
  • prepare
  • prepublish
  • publish
  • postpublish

npm pack

  • prepack
  • postpack

npm install

  • preinstall
  • install
  • postinstall

Aciona também

  • prepublish (quando no local)
  • prepare (quando no local)

npm start

npm run start tem um estenógrafo npm start.

  • prestart
  • start
  • poststart

Valores por omissão

npm terá por omissão alguns valores de script baseados no conteúdo do pacote.

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

    Se houver um arquivo server.js na raiz do seu pacote, então npm terá como padrão o comando start para node server.js.

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

    Se existir um ficheiro binding.gyp na raiz do seu pacote e não tiver definido os seus próprios scripts install ou preinstall, o npm irá colocar por defeito o comando install para compilar usando node-gyp.

User

Se npm foi invocado com privilégios de root, então ele irá alterar o uid para a conta do usuário ou uid especificado pelo config user, que por defeito é nobody. Defina o flag unsafe-perm para executar scripts com privilégios de raiz.

Ambiente

Escripts de pacote executados em um ambiente onde muitas informações são disponibilizadas em relação à configuração do npm e o estado atual do processo.

caminho

Se você depender de módulos que definem scripts executáveis, como os testsuites, então esses executáveis serão adicionados ao arquivo PATH forexecuting dos scripts. Então, se o seu pacote.json tem isto:

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

então você poderia executar npm start para executar o script bar, que é exportado para o diretório node_modules/.bin em npm install.

package.json vars

Os campos package.json são colados no prefixo npm_package_. Assim, por exemplo, se você tivesse {"name":"foo", "version":"1.2.5"} em seu arquivo package.json, então seus scripts de pacote teriam a variável de ambientenpm_package_name definida como “foo”, e a variávelnpm_package_version definida como “1.2.5”. Você pode acessar essas variáveis no seu código com process.env.npm_package_name eprocess.env.npm_package_version, e assim por diante para outros campos.

configuração

Parâmetros de configuração são colocados no ambiente com o prefixonpm_config_. Por exemplo, você pode ver o efetivo rootconfig verificando o npm_config_root variável de ambiente.

Especial: package.json “config” object

As chaves package.json “config” são sobrescritas no ambiente se houver um parâmetro de configuração de <name>:<key>. Por exemplo, se o package.json tem isto:

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

e o server.js é este:

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

então o usuário poderia mudar o comportamento fazendo:

 npm config set foo:port 80

evento do ciclo de vida atual

Por último, a variável de ambiente npm_lifecycle_event está configurada em qualquer estágio do ciclo que está sendo executado. Então, você poderia ter um script único usado para diferentes partes do processo que muda baseado no que está acontecendo atualmente.

Objetos são achatados seguindo este formato, então se você tivesse{"scripts":{"install":"foo.js"}} em seu pacote.json, então você verá isto no script:

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

Exemplos

Por exemplo, se o seu pacote.json contém isto:

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

então scripts/install.js será chamado para as fases de instalação e pós-instalação do ciclo de vida, e scripts/uninstall.js será chamado quando o pacote for desinstalado. Como scripts/install.js está rodando para duas fases diferentes, seria sábio neste caso olhar para a variável de ambiente npm_lifecycle_event.

Se você quiser rodar um comando make, você pode fazer isso. Isto funciona justfine:

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

Sair

Os scripts são executados passando a linha como argumento de script para sh.

Se o script sair com um código diferente de 0, então isso abortará o processo.

Note que esses arquivos de script não precisam ser programas nodejs ou evenjavascript. Eles só precisam ser algum tipo de arquivo executável.

Hook Scripts

Se você quiser executar um script específico em um evento específico do ciclo de vida paraALL pacotes, então você pode usar um hook script.

Colocar um arquivo executável em node_modules/.hooks/{eventname}, e ele será executado para todos os pacotes quando eles estiverem passando por aquele ponto do ciclo de vida do pacote para qualquer pacote instalado naquela raiz.

Ciclos de gancho são executados exatamente da mesma forma que package.json scripts.Isto é, eles estão em um processo filho separado, com o env descrito acima.

Melhores Práticas

  • Não saia com um código de erro não-zero, a menos que você realmente queira dizer isso.Exceto para scripts de desinstalação, isso causará a ação npm tofail, e potencialmente será rolado de volta. Se a falha for menor ou apenas evitará alguns recursos opcionais, então é melhor apenas imprimir um aviso e sair com sucesso.
  • Tente não usar scripts para fazer o que o npm pode fazer por você. Leia através depackage.json para ver todas as coisas que você pode especificar e habilitar, simplesmente descrevendo seu pacote apropriadamente. Em geral, isso levará a um estado mais robusto e consistente.
  • Inspeccione a inveja para determinar onde colocar as coisas. Por exemplo, se a variável de ambiente npm_config_binroot estiver definida como /home/user/bin, não tente instalar os executáveis em /usr/local/bin. O usuário provavelmente a configurará dessa forma por uma razão.
  • Não prefira seus comandos de script com “sudo”. Se as permissões de root forem necessárias por alguma razão, então falhará com esse erro, e o usuário irá sudo o comando npm em questão.
  • Não use install. Use um arquivo .gyp para compilação, e prepublish para qualquer outra coisa. Você quase nunca deve ter que definir explicitamente o comando apreinstall ou instalar o script. Se você estiver fazendo isso, por favor considere se há outra opção. O único uso válido de install ou preinstallscripts é para compilação que deve ser feita na arquitetura de destino.

Veja Também

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

Deixe uma resposta

O seu endereço de email não será publicado.