bower - home - ¿Por qué revisar los componentes de la glorieta?
no.bowerrc file in home directory (2)
Esta respuesta no es técnica, pero es una razón práctica para no verificar los componentes de la glorieta.
Prefiero recomendar que se bloqueen los paquetes de bower en bower.json en lugar de registrar estos paquetes. Porque confía en mí, no puedes tener miles de archivos descargando y descomprimiendo en una computadora. Las computadoras de rendimiento lento tienen un problema con rutas de archivos muy grandes y profundas. Y en este mundo de Internet, creo que siempre es fácil descargar los paquetes en lugar de cargarlos.
Es solo una cuestión de preferencia. Todo viene de la experiencia. He comprobado un proyecto con componentes Bower en Github y es peor al cargar y descargar. Lo hice a través de una Mac relativamente nueva.
Bower docs dice
NB: Si no está creando un paquete que está destinado a ser consumido por otros (por ejemplo, está creando una aplicación web), siempre debe verificar los paquetes instalados en el control de código fuente.
¿Alguien tiene una buena respuesta a por qué?
Si estoy creando una aplicación web, no quiero que mi repositorio se llene de actualizaciones en la versión de la biblioteca X.
Solo quiero actualizar las dependencias de bower.json. Pensaría que la mayoría de los proyectos tendrán un paso de compilación o similar, por ejemplo con grunt. El paso de compilación se aseguraría de llamar a bower instalar / actualizar antes de compilar, de modo que esos archivos estén presentes para concat / minificación, etc. O incluso una copia simple a alguna carpeta dist.
¿Me estoy perdiendo de algo?
Se trata de bloquear sus dependencias para evitar que una dependencia defectuosa rompa su aplicación o que el control remoto se detenga, lo que impide la implementación. Esto podría suceder aunque tenga un paso de compilación, ya que probablemente no realice pruebas exhaustivas en cada compilación, y las pruebas automatizadas no detectan todo, especialmente no las regresiones visuales. También varios desarrolladores pueden tener diferentes versiones de una dependencia. Al comprometer las dependencias, se asegura de que todos permanezcan en la misma versión. También encuentro que ver el diff es una buena manera de asegurarse de que no se introdujo ningún malicioso en el árbol de dependencias.
En el mundo de nodos, npm shrinkwrap resuelve esto parcialmente, pero aún no realiza la comparación de suma de comprobación. Bower actualmente tiene un ticket abierto para implementar el mismo.
Puede leer más sobre esto en esta publicación de blog: Verificación de dependencias de front-end