¿Sería una buena práctica mantener solo el bower.jsonarchivo y ignorar todo el bower_componentsdirectorio?
¿Sería una buena práctica mantener solo el bower.jsonarchivo y ignorar todo el bower_componentsdirectorio?
Respuestas:
La página oficial de Bower declaró:
Nota: si no está creando un paquete destinado a ser consumido por otros (por ejemplo, si está creando una aplicación web), siempre debe verificar los paquetes instalados en el control de código fuente .
Asegúrese de revisar el enlace en la cita, se discuten algunos pros y contras. La principal ventaja que menciona es que registrarlos garantiza que sus dependencias estén siempre disponibles, siempre que su repositorio esté disponible. No importa lo que le pase a Bower, GitHub o cualquier otra cosa que se necesite de otra manera.
El archivo .gitignore en un proyecto Yeoman AngularJS recientemente generado tiene bower_components (y node_modules) listados para ser ignorados (si no conoce a Yeoman, es una herramienta de andamiaje web de buena reputación para aplicaciones web modernas, ¡eso es lo suficientemente bueno para mí!):
.gitignore
node_modules
dist
.tmp
.sass-cache
bower_components
Hay un momento y un lugar para ambos enfoques. Para Yeoman, es apropiado confiar en bower.json porque es una herramienta en una cadena de herramientas y necesita mantenerse vivo y respirar con el ecosistema de Bower. Para una aplicación web desplegable, generalmente es una buena práctica confirmar dependencias y mantener un mayor control.
Aquí hay un buen artículo que me gusta que discute esto.
El generador Yeoman rellenó previamente el archivo .gitignore con bower_components, pero también rellenó previamente otros directorios que creo que serían necesarios para una aplicación final (como www), así que investigué un poco.
Descubrí que www / index.html es una versión reducida de la aplicación / index.html. El directorio de la aplicación y sus contenidos (incluidos bower_components) contienen los archivos fuente necesarios para el directorio de salida (www). Confirma directorios de origen en control de origen (es decir, git) pero no archivos generados (es decir, www). Los administradores de paquetes como bower y npm están destinados a ser utilizados durante la fase de construcción / generación y sus artefactos no están destinados a ser controlados en el control de origen.
En última instancia, la fuente que verifica en git es la configuración mínima necesaria para construir el resto del proyecto con fines de desarrollo o implementación.
Es bueno ignorar /bower_componentsdir y registrarse solo bower.jsony bower-locker.bower.jsonarchivo si crea un archivo de bloqueo usando bower-locker escrito por Shawn Lonas .
Antes de que se creara el bower-locker, había una desventaja causada por un problema de que el bower no tenía la capacidad de envoltura retráctil, pero puede mitigarse con la biblioteca anterior.
Ejecute los siguientes comandos para lograrlo:
npm install bower-locker -g
o
yarn global add bower-locker
luego genere un archivo de bloqueo basado en el bower.jsonarchivo existente ejecutando:
bower-locker lock
El bower.jsonarchivo original será renombrado abower-locker.bower.json
.gitignorearchivo"