Resumo das diferenças importantes de comportamento:
Opções relacionadas não discutidas aqui:
devDependencies
dependenciessão necessários para executar, devDependenciesapenas para desenvolver, por exemplo: testes de unidade, transpilação CoffeeScript para JavaScript, minificação, ...
Se você estiver desenvolvendo um pacote, faça o download (por exemplo, via git clone), vá para a raiz que contém package.jsone execute:
npm install
Como você possui a fonte real, é claro que deseja desenvolvê-la; portanto, por padrão, ambas dependencies(desde que você deve, é claro, executar para desenvolver) e devDependencydependências também são instaladas.
Se, no entanto, você é apenas um usuário final que deseja instalar um pacote para usá-lo, faça isso em qualquer diretório:
npm install "$package"
Nesse caso, você normalmente não querem que as dependências de desenvolvimento, assim você só recebe o que é necessário para utilizar o pacote: dependencies.
Se você realmente deseja instalar pacotes de desenvolvimento nesse caso, pode definir a devopção de configuração para true, possivelmente na linha de comando, como:
npm install "$package" --dev
A opção é falsepor padrão, pois esse é um caso muito menos comum.
peerDependencies
(Testado antes da 3.0)
Fonte: https://nodejs.org/en/blog/npm/peer-dependencies/
Com dependências regulares, você pode ter várias versões da dependência: ela é simplesmente instalada dentro node_modulesda dependência.
Por exemplo, se dependency1e dependency2ambos dependem de dependency3versões diferentes, a árvore do projeto será semelhante a:
root/node_modules/
|
+- dependency1/node_modules/
| |
| +- dependency3 v1.0/
|
|
+- dependency2/node_modules/
|
+- dependency3 v2.0/
Plugins, no entanto, são pacotes que normalmente não exigem o outro pacote, chamado de host neste contexto. Em vez de:
- plugins são requeridos pelo host
- Os plugins oferecem uma interface padrão que o host espera encontrar
- somente o host será chamado diretamente pelo usuário; portanto, deve haver uma única versão dele.
Por exemplo, se dependency1e dependency2ponto dependem dependency3, a árvore do projeto será semelhante a:
root/node_modules/
|
+- dependency1/
|
+- dependency2/
|
+- dependency3 v1.0/
Isso acontece mesmo que você nunca mencione dependency3no seu package.jsonarquivo.
Eu acho que essa é uma instância do padrão de design Inversion of Control .
Um exemplo prototípico de dependências entre pares é o Grunt, o host e seus plugins.
Por exemplo, em um plug-in Grunt como https://github.com/gruntjs/grunt-contrib-uglify , você verá que:
grunt é um peer-dependency- o único
require('grunt')está abaixo tests/: não é realmente usado pelo programa.
Então, quando o usuário usar um plug-in, ele implicitamente exigirá o plug-in Gruntfileadicionando uma grunt.loadNpmTasks('grunt-contrib-uglify')linha, mas é gruntque o usuário chamará diretamente.
Isso não funcionaria se cada plug-in exigisse uma versão diferente do Grunt.
Manual
Acho que a documentação responde muito bem à pergunta, talvez você não esteja familiarizado o suficiente com os gerenciadores de nós / outros pacotes. Eu provavelmente só entendo porque sei um pouco sobre o empacotador Ruby.
A linha principal é:
Essas coisas serão instaladas durante a instalação do link npm ou npm a partir da raiz de um pacote e podem ser gerenciadas como qualquer outro parâmetro de configuração do npm. Veja npm-config (7) para mais informações sobre o tópico.
E então, em npm-config (7), localize dev:
Default: false
Type: Boolean
Install dev-dependencies along with packages.
optionalDependenciesagora.