Pregunta ¿Cuál es la diferencia entre Bower y npm?


¿Cuál es la diferencia fundamental entre bower y npm? Solo quiero algo simple y simple. He visto a algunos de mis colegas usar bower y npm indistintamente en sus proyectos.


1611
2017-09-05 16:53


origen


Respuestas:


Todos los administradores de paquetes tienen muchas desventajas. Solo tienes que elegir con qué puedes vivir.

Historia

npm comenzó a gestionar los módulos node.js (es por eso que los paquetes entran en node_modules por defecto), pero también funciona para el front-end cuando se combina con Browserify o WebPack.

Cenador se crea únicamente para el front-end y se optimiza con eso en mente.

Tamaño de repo

npm es mucho, mucho más grande que bower, incluido JavaScript de propósito general (como country-data para información del país o sorts para ordenar funciones que se pueden usar en el frente o en el extremo posterior).

Bower tiene una cantidad mucho menor de paquetes.

Manejo de estilos, etc.

Bower incluye estilos, etc.

npm se enfoca en JavaScript. Los estilos se descargan por separado o se requieren por algo como npm-sass o sass-npm.

Manejo de dependencia

La mayor diferencia es que npm tiene dependencias anidadas (pero es plana por defecto) mientras que Bower requiere un árbol de dependencia plano (pone la carga de la resolución de dependencia en el usuario).

Un árbol de dependencia anidado significa que sus dependencias pueden tener sus propias dependencias que pueden tener las suyas propias, y así sucesivamente. Esto permite que dos módulos requieran diferentes versiones de la misma dependencia y sigan funcionando. Tenga en cuenta que desde npm v3, el árbol de dependencias se mantendrá plano de forma predeterminada (ahorrando espacio) y solo se anidará donde sea necesario, por ejemplo, si dos dependencias necesitan su propia versión de Underscore.

Algunos proyectos usan ambos, usan Bower para paquetes front-end y npm para herramientas de desarrollador como Yeoman, Grunt, Gulp, JSHint, CoffeeScript, etc.


Recursos


1828
2017-09-06 08:09



Esta respuesta es una adición a la respuesta de Sindre Sorhus. La principal diferencia entre npm y Bower es la forma en que tratan las dependencias recursivas. Tenga en cuenta que se pueden usar juntos en un solo proyecto.

Sobre el Preguntas frecuentes sobre npm: (enlace de archive.org del 6 de septiembre de 2015)

Es mucho más difícil evitar conflictos de dependencia sin anidar   dependencias. Esto es fundamental para la forma en que npm funciona, y tiene   demostrado ser un enfoque extremadamente exitoso.

En Cenador página principal:

Bower está optimizado para el front-end. Bower usa una dependencia plana   árbol, que requiere una sola versión para cada paquete, lo que reduce la carga de la página   a un mínimo.

En resumen, npm apunta a la estabilidad. Bower apunta a una carga de recursos mínima. Si dibuja la estructura de dependencia, verá esto:

npm:

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

Como puede ver, instala algunas dependencias recursivamente. ¡Dependencia A tiene tres instancias instaladas!

Cenador:

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

Aquí puede ver que todas las dependencias únicas están en el mismo nivel.

Entonces, ¿por qué molestarse en usar npm?

Tal vez la dependencia B requiere una versión diferente de la dependencia A que la dependencia C. npm instala ambas versiones de esta dependencia, por lo que funcionará de todos modos, pero Bower le dará una conflicto porque no le gusta la duplicación (porque cargar el mismo recurso en una página web es muy ineficiente y costoso, también puede dar algunos errores graves). Deberá elegir manualmente qué versión desea instalar. Esto puede tener el efecto de que una de las dependencias se romperá, pero eso es algo que deberá corregir de todos modos.

Por lo tanto, el uso común es Bower para los paquetes que desea publicar en sus páginas web (p. tiempo de ejecución, donde evita la duplicación) y usa npm para otras cosas, como probar, construir, optimizar, verificar, etc. (p. tiempo de desarrollo, donde la duplicación es menos preocupante).

Actualización para npm 3:

npm 3 todavía hace las cosas de manera diferente en comparación con Bower. Instalará las dependencias globalmente, pero solo para la primera versión que encuentre. Las otras versiones se instalan en el árbol (el módulo principal, luego node_modules).

  • [node_modules]
    • dep A v1.0
    • dep B v1.0
      • dep A v1.0 (usa la versión raíz)
    • dep C v1.0
      • dep A v2.0 (esta versión es diferente de la versión raíz, por lo que será una instalación anidada)

Para más información, sugiero leer el documentos de npm 3


338
2017-11-24 13:10



TL; DR: la mayor diferencia en el uso diario no son las dependencias anidadas ... es la diferencia entre los módulos y los globales.

Creo que los carteles anteriores han cubierto bien algunas de las distinciones básicas. (El uso de npps de dependencias anidadas es de hecho muy útil para administrar aplicaciones grandes y complejas, aunque no creo que sea la distinción más importante).

Me sorprende, sin embargo, que nadie haya explicado explícitamente una de las distinciones más fundamentales entre Bower y npm. Si lee las respuestas anteriores, verá la palabra "módulos" que se usa a menudo en el contexto de npm. Pero se menciona casualmente, como si pudiera ser solo una diferencia de sintaxis.

Pero esta distinción de módulos vs. globales (o módulos vs. 'guiones') es posiblemente la diferencia más importante entre Bower y npm. El enfoque npm de poner todo en módulos requiere que cambies la forma en que escribes Javascript para el navegador, casi con seguridad para mejor.

El enfoque de Bower: Recursos globales, Me gusta <script> Etiquetas

En root, Bower se trata de cargar archivos de script simples. Independientemente de lo que contengan esos archivos de script, Bower los cargará. Lo que básicamente significa que Bower es como incluir todas tus secuencias de comandos en simple-viejo <script>está en el <head> de tu HTML

Entonces, el mismo enfoque básico al que estás acostumbrado, pero obtienes algunas buenas ventajas de automatización:

  • Solía ​​necesitar incluir dependencias JS en el repositorio del proyecto (mientras se desarrolla), o obtenerlas a través de CDN. Ahora puede saltear ese peso de descarga adicional en el repositorio y alguien puede hacer una rápida bower instally al instante tienen lo que necesitan, localmente.
  • Si una dependencia de Bower especifica sus propias dependencias en su bower.json, esos serán descargados para usted también.

Pero más allá de eso, Bower no cambia la forma en que escribimos javascript. Nada de lo que entra dentro de los archivos cargados por Bower necesita cambiar en absoluto. En particular, esto significa que los recursos proporcionados en los scripts cargados por Bower se definirán (generalmente, pero no siempre) como variables globales, disponible desde cualquier lugar en el contexto de ejecución del navegador.

El enfoque npm: módulos JS comunes, inyección de dependencia explícita

Todo el código en Node land (y, por lo tanto, todo el código cargado a través de npm) está estructurado como módulos (específicamente, como una implementación del Formato del módulo CommonJS, o ahora, como un módulo ES6). Entonces, si usa NPM para manejar dependencias del lado del navegador (a través de Browserify u otra cosa que hace el mismo trabajo), estructurará su código de la misma manera que Node.

Las personas más inteligentes que he abordado la cuestión de "¿Por qué los módulos?", Pero aquí hay un resumen de la cápsula:

  • Cualquier cosa dentro de un módulo es efectivamente namespaced, lo que significa que ya no es una variable global, y no puedes referenciarla accidentalmente sin proponértelo.
  • Cualquier cosa dentro de un módulo debe ser intencionalmente inyectada en un contexto particular (generalmente otro módulo) para poder usarlo
  • Esto significa que puede tener múltiples versiones de la misma dependencia externa (lodash, digamos) en varias partes de su aplicación, y no colisionarán / entrarán en conflicto. (Esto sucede sorprendentemente a menudo, porque su propio código quiere usar una versión de una dependencia, pero una de sus dependencias externas especifica otra que entra en conflicto. O tiene dos dependencias externas que desean una versión diferente).
  • Debido a que todas las dependencias se inyectan manualmente en un módulo particular, es muy fácil razonar sobre ellas. Usted sabe a ciencia cierta: "El único código que debo considerar al trabajar en esto es lo que intencionalmente he elegido inyectar aquí".
  • Porque incluso el contenido de los módulos inyectados es encapsulado detrás de la variable que le asigna, y todo el código se ejecuta dentro de un alcance limitado, las sorpresas y las colisiones se vuelven muy improbables. Es mucho, mucho menos probable que algo de una de sus dependencias redefinirá accidentalmente una variable global sin que usted se dé cuenta, o que lo hará. (Eso poder suceder, pero por lo general tienes que salir de tu camino para hacerlo, con algo como window.variable. El único accidente que aún tiende a ocurrir es asignar this.variablesin darse cuenta de eso this es en realidad window en el contexto actual)
  • Cuando desea probar un módulo individual, puede saber muy fácilmente: ¿qué más (dependencias) está afectando al código que se ejecuta dentro del módulo? Y, como está inyectando explícitamente todo, puede burlarse fácilmente de esas dependencias.

Para mí, el uso de módulos para el código del front-end se reduce a: trabajar en un contexto mucho más limitado, más fácil de razonar y probar, y tener mayor certeza sobre lo que está sucediendo.


Solo toma unos 30 segundos aprender a usar la sintaxis del módulo CommonJS / Node. Dentro de un archivo JS determinado, que va a ser un módulo, primero declara las dependencias externas que desea usar, como esta:

var React = require('react');

Dentro del archivo / módulo, haga lo que normalmente haría, y cree algún objeto o función que desee exponer a usuarios externos, llamándolo tal vez myModule.

Al final de un archivo, exporta lo que quieras compartir con el mundo, como este:

module.exports = myModule;

Luego, para usar un flujo de trabajo basado en CommonJS en el navegador, usará herramientas como Browserify para capturar todos esos archivos de módulos individuales, encapsular sus contenidos en tiempo de ejecución e insertarlos entre sí según sea necesario.

Y, dado que los módulos ES6 (que probablemente transpile a ES5 con Babel o similar) están ganando amplia aceptación, y funcionan tanto en el navegador como en el Nodo 4.0, debemos mencionar un buena visión general de esos también

Más sobre los patrones para trabajar con módulos en esta cubierta.


EDITAR (feb 2017): Facebook Hilo es un reemplazo / suplemento potencial muy importante para la npm en estos días: administración de paquetes rápida, determinista y fuera de línea que se basa en lo que la npm le brinda. Vale la pena echarle un vistazo a cualquier proyecto de JS, sobre todo porque es muy fácil intercambiarlo o quitarlo.


256
2017-07-26 03:12



Actualización de 2017 a octubre

Bower finalmente ha sido obsoleto. Fin de la historia.

Respuesta anterior

De Mattias Petter Johansson, desarrollador de JavaScript en Spotify:

En casi todos los casos, es más apropiado usar Browserify y npm en Bower. Es simplemente una mejor solución de empaquetado para aplicaciones frontales que Bower. En Spotify, usamos npm para empaquetar módulos web completos (html, css, js) y funciona muy bien.

Bower se marca a sí mismo como el administrador de paquetes para la web. Sería increíble si esto fuera cierto: un administrador de paquetes que mejorara mi vida como desarrollador front-end sería increíble. El problema es que Bower no ofrece herramientas especializadas para este propósito. No ofrece herramientas que sepa que npm no tiene, y especialmente ninguna que sea específicamente útil para desarrolladores front-end. Simplemente no hay beneficio para un desarrollador front-end para usar Bower sobre npm.

Deberíamos dejar de usar bower y consolidarnos alrededor de npm. Afortunadamente, eso es lo que está sucediendo:

Module counts - bower vs. npm

Con browserify o webpack, se vuelve super fácil concatenar todos sus módulos en grandes archivos minificados, lo que es impresionante para el rendimiento, especialmente para dispositivos móviles. No ocurre lo mismo con Bower, lo que requerirá mucho más trabajo para obtener el mismo efecto.

npm también le ofrece la posibilidad de usar múltiples versiones de módulos simultáneamente. Si no has hecho mucho desarrollo de aplicaciones, inicialmente esto puede parecer algo malo, pero una vez que has pasado por algunos episodios de Dependencia del infierno se dará cuenta de que tener la capacidad de tener múltiples versiones de un módulo es una gran característica. Tenga en cuenta que npm incluye un muy útil herramienta dedupe que automáticamente se asegura de que solo use dos versiones de un módulo si realmente tener a - si dos módulos ambos poder utilizar la misma versión de un módulo, lo harán. Pero si ellos hipocresía, tienes una salida muy práctica.

(Tenga en cuenta que Webpack y enrollar son ampliamente considerados como mejores que Browserify a partir de agosto de 2016.)


117
2017-07-04 10:48



Bower mantiene una única versión de módulos, solo trata de ayudarlo a seleccionar el más adecuado para usted.

Administración de dependencias de Javascript: npm vs bower vs volo?

NPM es mejor para módulos de nodos porque hay un sistema de módulos y usted está trabajando localmente. Bower es bueno para el navegador porque actualmente solo existe el alcance global, y desea ser muy selectivo con la versión con la que trabaja.


43
2017-07-19 20:59



Mi equipo se alejó de Bower y migró a npm porque:

  • El uso programático fue doloroso
  • La interfaz de Bower siguió cambiando
  • Algunas funciones, como la abreviatura de url, están completamente rotas
  • Usar tanto Bower como npm en el mismo proyecto es doloroso
  • Mantener el campo de versión bower.json en sincronización con las etiquetas git es doloroso
  • Control de fuente! = Gestión de paquetes
  • El soporte de CommonJS no es sencillo

Para más detalles, ver "Por qué mi equipo usa npm en lugar de bower".


31
2018-02-16 21:04



Encontré esta útil explicación de http://ng-learn.org/2013/11/Bower-vs-npm/

Por un lado, npm se creó para instalar módulos usados ​​en un entorno node.js, o herramientas de desarrollo creadas usando node.js tales como Karma, lint, minifiers, etc. npm puede instalar módulos localmente en un proyecto (por defecto en node_modules) o globalmente para ser utilizado por múltiples proyectos. En proyectos grandes, la forma de especificar dependencias es creando un archivo llamado package.json que contiene una lista de dependencias. Esa lista es reconocida por npm cuando ejecuta npm install, que luego las descarga e instala por usted.

Por otro lado, se creó bower para administrar sus dependencias de frontend. Bibliotecas como jQuery, AngularJS, guión bajo, etc. Al igual que npm, tiene un archivo en el que puede especificar una lista de dependencias llamada bower.json. En este caso, las dependencias de su interfaz se instalan ejecutando bower install, que las instala de forma predeterminada en una carpeta denominada bower_components.

Como puede ver, aunque realizan una tarea similar, están destinados a un conjunto muy diferente de bibliotecas.


14
2017-10-03 00:08



Para muchas personas que trabajan con node.js, un beneficio importante de bower es la administración de dependencias que no son javascript en absoluto. Si están trabajando con lenguajes que compilan a javascript, npm puede usarse para administrar algunas de sus dependencias. sin embargo, no todas sus dependencias van a ser módulos node.js. Algunos de los que compilan en javascript pueden tener un lenguaje de fuente extraño específico que hace que pasarlos compilados a javascript sea una opción poco elegante cuando los usuarios esperan el código fuente.

No todo en un paquete npm debe ser javascript orientado al usuario, pero para los paquetes de biblioteca npm, al menos parte de esto debe ser.


4
2017-10-11 20:42



Bower y Npm son administradores de paquetes para javascript.

Cenador

Bower se creó únicamente para el desarrollo de front-end. Utiliza un árbol de dependencias planas, que requiere solo una versión para cada paquete, reduciendo la carga de la página. Su objetivo principal es una carga mínima de recursos. Tiene menos contribuyentes y, por lo tanto, el proceso de desarrollo es lento.

Bower tiene un archivo de configuración llamado bower.json. En este archivo podemos mantener la configuración de Bower, como qué dependencias necesitamos y detalles de licencia, descripción, nombre, etc. Bower es adecuado para paquetes front-end como jquery, angular, reaccionar, brasa, knockout, columna vertebral, etc.

Npm

Npm se usa más comúnmente para administrar módulos Node.js, pero también funciona para el front-end. Utiliza un árbol de dependencia anidado así como un árbol de dependencia plano. Es popular y tiene muchos contribuyentes. Por lo tanto, su nueva versión siempre ofrece funciones interesantes.

Npm tiene un archivo de configuración llamado package.json. En este archivo podemos mantener la configuración de Npm, como qué dependencias necesitamos y detalles de la licencia, descripción, nombre, etc. Npm proporciona Dependencias y DevDependencias. Dependencias descargará y mantendrá los archivos de front-end como Jquery, Angular, etc. DevDependencies descargará y mantendrá herramientas de desarrollo como Grunt, Gulp, JSHint, etc.

Obviamente, esto no funciona tan bien en el front-end, porque necesitamos jQuery en nuestros proyectos. Solo necesitamos una copia de jQuery, pero cuando otro paquete requiera jQuery, descargará una copia más de jQuery. Este es uno de los principales inconvenientes de Npm.

Nota clave: La razón por la que muchos proyectos utilizan ambos es porque usan Bower para paquetes de aplicaciones para el usuario y Npm para herramientas de desarrollo. Al multiplicar el administrador de paquetes en su proyecto, su flujo de trabajo se vuelve más difícil. Npm 3 junto con Navegar o paquete web es el camino a seguir ahora.


1
2018-01-07 09:26