Seria uma boa prática manter apenas o bower.json
arquivo e fazer gitignore o bower_components
diretório inteiro ?
Seria uma boa prática manter apenas o bower.json
arquivo e fazer gitignore o bower_components
diretório inteiro ?
Respostas:
A página oficial do Bower declarou:
Nota: 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 verifique os pacotes instalados no controle de origem .
Certifique-se de verificar o link na citação, que discute alguns prós e contras. O principal aspecto mencionado é que o check-in garante que suas dependências estejam sempre disponíveis, desde que seu repositório esteja disponível. Não importa o que aconteça com o Bower, o GitHub ou o que mais for necessário.
O arquivo .gitignore em um projeto Yeoman AngularJS recém-gerado tem bower_components (e node_modules) listados para serem ignorados (se você não conhece o Yeoman, é uma ferramenta de andaime da web muito respeitável para aplicativos da web modernos, então isso é o suficiente para mim!):
.gitignore
node_modules
dist
.tmp
.sass-cache
bower_components
Há um tempo e um lugar para ambas as abordagens. Para a Yeoman, é apropriado contar com o bower.json, porque é uma ferramenta em uma cadeia de ferramentas e precisa permanecer vivo e respirar com o ecossistema da bower. Para um aplicativo da web implementável, geralmente é uma boa prática confirmar dependências e manter mais controle.
Aqui está um bom artigo que eu gosto que discute isso.
O gerador Yeoman preencheu previamente o arquivo .gitignore com bower_components, mas também preencheu outros diretórios que eu pensaria que seriam necessários para um aplicativo final (como www), então fiz algumas pesquisas.
Descobri que www / index.html é uma versão reduzida do aplicativo / index.html. O diretório do aplicativo e seu conteúdo (incluindo bower_components) contém os arquivos de origem necessários para o diretório de saída (www). Você compromete os diretórios de origem no controle de origem (por exemplo, git), mas não nos arquivos gerados (por exemplo, www). Os gerenciadores de pacotes como bower e npm devem ser usados durante a fase de construção / geração e seus artefatos não devem ser verificados no controle de origem.
Por fim, a fonte que você faz check-in no git é a configuração mínima necessária para construir o restante do projeto para fins de desenvolvimento ou implantação.
É bom ignorar /bower_components
dir, fazer check-in apenas bower.json
e bower-locker.bower.json
arquivar se você criar um arquivo de bloqueio usando o bower-locker escrito por Shawn Lonas .
Antes da criação do bower-locker, havia uma desvantagem causada por um problema de o bower não ter capacidade de retração, mas pode ser atenuado pela biblioteca acima.
Execute os seguintes comandos para alcançá-lo:
npm install bower-locker -g
ou
yarn global add bower-locker
gere o arquivo de bloqueio com base no bower.json
arquivo existente executando:
bower-locker lock
O bower.json
arquivo original será renomeado parabower-locker.bower.json
.gitignore
arquivo"