Respostas:
A resposta não é tão fácil quanto Alberto Zaccagni sugere. Se você desenvolver aplicativos (especialmente aplicativos corporativos), incluir node_modules em seu repositório git é uma opção viável e a alternativa que você escolher depende do seu projeto.
Como ele argumentou muito bem contra o node_modules, vou me concentrar nos argumentos para eles.
Imagine que você acabou de finalizar o aplicativo corporativo e precisará apoiá-lo por 3-5 anos. Definitivamente, você não quer depender do módulo npm de alguém, que pode desaparecer amanhã e não poderá mais atualizar seu aplicativo.
Ou você tem seus módulos privados que não são acessíveis na Internet e não é possível criar seu aplicativo na Internet. Ou talvez você não queira depender da sua compilação final no serviço npm por alguns motivos.
Você pode encontrar prós e contras neste artigo de Addy Osmani (embora seja sobre Bower, é quase a mesma situação). E terminarei com uma citação da página inicial do Bower e do artigo de Addy:
"Se você não está criando um pacote que se destina a ser consumido por outras pessoas (por exemplo, está criando um aplicativo da web), sempre deve verificar os pacotes instalados no controle de origem".
git checkout foo. Se node_modules não estão sob VCS - comutação ramos é git checkout foo ; npm installeo que quer que sua versão atual NPM requer ao trabalho;)
Os detalhes dos módulos são armazenados packages.json, isso é suficiente. Não há necessidade de fazer check-in node_modules.
As pessoas costumavam armazenar node_modulesno controle de versão para bloquear dependências de módulos, mas com o npm shrinkwrap isso não é mais necessário.
Outra justificativa para esse ponto, como o @ChrisCM escreveu no comentário:
Também digno de nota, qualquer módulo que envolva extensões nativas não funcionará arquitetura para arquitetura e precisará ser reconstruído. Fornecer justificativa concreta para NÃO incluí-los no repositório.
Eu recomendaria não fazer o check-in do node_modules por causa de pacotes como o PhantomJS e o node-sass, por exemplo, que instalam o binário apropriado para o sistema atual.
Isso significa que se um desenvolvedor executa npm installno Linux e faz o check-in do node_modules - não funcionará para outro desenvolvedor que clona o repositório no Windows.
É melhor verificar os tarballs que o npm instala downloads e apontar npm-shrinkwrap.jsonpara eles. Você pode automatizar esse processo usando o shrinkpack .
npm install --global shrinkpackpróprio não tem a fraqueza adiada, exigindo outros pacotes com os quais instalar os pacotes encolhidos? Isso vai contra o conselho de Addy.
shrinkpacké necessária para instalar de forma confiável as dependências de compilação. Portanto, a instalação da ferramenta de construção se torna a fraqueza do argumento contra o envio de todas as dependências de construção ao controle de versão.
Este tópico é bastante antigo, pelo que entendi. Mas estou perdendo alguma atualização dos argumentos fornecidos aqui devido a uma situação alterada no sistema ecológico da npm.
Eu sempre aconselho a não colocar node_modules sob controle de versão. Quase todos os benefícios de fazê-lo, conforme listado no contexto da resposta aceita, estão bastante desatualizados a partir de agora.
Pacotes publicados não podem mais ser revogados do registro npm com tanta facilidade. Portanto, você não precisa ter medo de perder dependências nas quais seu projeto confiava antes.
Colocar o arquivo package-json.lock no VCS está ajudando com dependências atualizadas com freqüência, provavelmente resultando em configurações diferentes, embora contando com o mesmo arquivo package.json.
Portanto, colocar node_modules no VCS no caso de ter ferramentas de construção offline pode ser considerado o único caso de uso elegível restante. No entanto, node_modules geralmente cresce muito rápido. Qualquer atualização alterará muitos arquivos. E isso está afetando repositórios de maneiras diferentes. Se você realmente considera efeitos a longo prazo, isso também pode ser um impedimento.
O svn centralizado do VCS exige a transferência de arquivos confirmados e verificados pela rede, o que será lento demais para verificar ou atualizar uma pasta node_modules.
Quando se trata de git, esse alto número de arquivos adicionais polui instantaneamente o repositório. Lembre-se de que o git não está rastreando diferenças entre as versões de nenhum arquivo, mas está armazenando cópias de qualquer versão de um arquivo assim que um único caractere é alterado. Toda atualização para qualquer dependência resultará em outro grande conjunto de alterações. Seu repositório git rapidamente se tornará enorme por causa disso, afetando backups e sincronização remota. Se você decidir remover node_modules do repositório git posteriormente, ele ainda fará parte dele por razões históricas. Se você distribuiu seu repositório git para algum servidor remoto (por exemplo, para backup), limpá-lo é outra tarefa dolorosa e propensa a erros nos quais você está executando.
Portanto, se você se importa com processos eficientes e gosta de manter as coisas "pequenas", prefiro usar um repositório de artefatos separado, como o Nexos Repository (ou apenas algum servidor HTTP com arquivos ZIP), fornecendo um conjunto de dependências previamente buscadas para download.
Não rastrear node_modulescom o controle de origem é a escolha certa, porque alguns módulos do NodeJS, como o driver MongoDB NodeJS, usam complementos do NodeJS C ++. Esses complementos são compilados ao executar o npm installcomando. Portanto, ao rastrear o node_modulesdiretório, você pode acidentalmente confirmar um arquivo binário específico do SO.
Concordo com o ivoszz que às vezes é útil verificar a pasta node_modules, mas ...
Cenário 1:
Um cenário: você usa um pacote que é removido do npm. Se você tiver todos os módulos na pasta node_modules, isso não será um problema para você. Se você tiver apenas o nome do pacote no package.json, não poderá mais obtê-lo. Se um pacote tiver menos de 24 horas, você poderá removê-lo facilmente do npm. Se tiver mais de 24 horas, entre em contato com eles. Mas:
Se você entrar em contato com o suporte, eles verificarão se a remoção dessa versão do seu pacote quebraria outras instalações. Nesse caso, não o removeremos.
Portanto, as chances são baixas, mas existe o cenário 2 ...
cenário 2:
Um outro cenário em que este é o caso: Você desenvolve uma versão corporativa do seu software ou um software muito importante e escreve no seu package.json:
"dependencies": {
"studpid-package": "~1.0.1"
}Você usa o método function1(x)desse pacote.
Agora os desenvolvedores do studpid-package renomeiam o método function1(x)para function2(x)e cometem uma falha ... Eles alteram a versão do pacote de 1.0.1para 1.1.0. Isso é um problema, porque quando você ligar npm installda próxima vez, aceitará a versão 1.1.0porque usou o til ( "studpid-package": "~1.0.1").
A chamada function1(x)pode causar erros e problemas agora.
Mas:
Enviar a pasta node_modules inteira (geralmente mais de 100 MB) para o seu repositório irá custar espaço de memória. Alguns kb (apenas package.json) comparados com centenas de MB (package.json & node_modules) ... Pense nisso.
Você poderia fazer / deveria pensar se:
o software é muito importante.
custa dinheiro quando algo falha.
você não confia no registro npm. o npm é centralizado e poderia teoricamente ser desligado.
Você não precisa publicar a pasta node_modules em 99,9% dos casos se:
você desenvolve um software só para você.
você programou algo e só deseja publicar o resultado no GitHub porque outra pessoa pode estar interessada nele.
Se você não deseja que o node_modules esteja em seu repositório, basta criar um .gitignorearquivo e adicionar a linha node_modules.
npm installno Windows e no MacOS pode gerar arquivos diferentes (arquivos dependentes do SO) em alguns pacotes. Mas não tenho certeza disso. Alguém pode verificar se isso é verdade?
package-lock.json. Se houver um problema no futuro com uma atualização do studpid-package, você poderá reverter o arquivo de bloqueio para descobrir a versão exata que funcionou para você.
Eu gostaria de oferecer uma alternativa no meio da estrada.
node_modulesno git.package-lock.jsonarquivo para definir suas versões de dependência.No raro evento em que você não pode acessar o NPM (ou outros registros usados) ou um pacote específico no NPM, você possui uma cópia do node_modules e pode continuar trabalhando até restaurar o acesso.
Mais uma coisa a considerar: o check-in node_modulestorna mais difícil / impossível usar a diferença entre dependenciese devDependencies.
Por outro lado, no entanto, pode-se dizer que é reconfortante levar à produção exatamente o mesmo código que passou pelos testes - inclusive devDependencies.
Não é necessário fazer o check-in do node_modules se as dependências forem mencionadas no package.json. Qualquer outro programador pode simplesmente obtê-lo fazendo a instalação do npm e o npm é inteligente o suficiente para criar os node_modules no diretório de trabalho do projeto.