javascript - node - ¿Cuál es la diferencia entre Bower y npm?

node js libraries (9)

Actualización de octubre-octubre

Bower finalmente ha sido deprecated . 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 sobre Bower. Es simplemente una mejor solución de empaquetado para aplicaciones front-end 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 gestor de paquetes para la web. Sería increíble si esto fuera cierto: un administrador de paquetes que mejoró mi vida como desarrollador de aplicaciones sería increíble. El problema es que Bower no ofrece herramientas especializadas para este propósito. No ofrece NINGUNA herramienta que yo sepa que npm no, y especialmente ninguna que sea específicamente útil para desarrolladores front-end. Simplemente, no hay ningún beneficio para un desarrollador de aplicaciones para usuario de usar Bower sobre npm.
Debemos dejar de usar bower y consolidar alrededor de npm. Afortunadamente, eso es lo que está sucediendo :

Con browserify o webpack, se vuelve súper fácil concatenar todos sus módulos en grandes archivos minificados, lo que es increíble para el rendimiento, especialmente para dispositivos móviles. No es así con Bower, 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 ha hecho mucho desarrollo de aplicaciones, esto inicialmente podría parecerle algo malo, pero una vez que haya pasado por algunos episodios de Dependencia, se dará cuenta de que tener la capacidad de tener múltiples versiones de un módulo es bastante difícil gran característica Tenga en cuenta que npm incluye una herramienta de deduplicación muy útil que se asegura automáticamente de que solo use dos versiones de un módulo si realmente tiene que hacerlo; si dos módulos pueden usar la misma versión de un módulo, lo harán. Pero si no pueden , tienes una muy útil.

(Tenga en cuenta que se Webpack que Webpack y el Webpack rollup son mejores que Browserify a partir de agosto de 2016).

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

Bower mantiene una única versión de los módulos, solo intenta ayudarte a seleccionar la correcta / mejor para ti.

Gestión de la dependencia de Javascript: npm vs bower vs volo?

NPM es mejor para módulos de nodo porque hay un sistema de módulos y 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.

Bower y Npm son gestores de paquetes para javascript.

Cenador

Bower se crea únicamente para el desarrollo de front-end. Utiliza un árbol de dependencia plano, que requiere solo una versión para cada paquete, lo que reduce la carga de la página. Apunta principalmente a una carga de recursos mínima. 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 las dependencias que necesitamos y los detalles de la licencia, la descripción, el nombre, etc. Bower es adecuado para paquetes front-end como jquery, angular, reaccion, brasa, knockout, backbone y así sucesivamente.

Npm

Npm es más comúnmente usado para administrar módulos Node.js, pero también funciona para el front-end. Utiliza el árbol de dependencias anidado y el árbol de dependencias plano. Es popular y tiene muchos colaboradores. Así que su nueva versión siempre viene con características interesantes.

Npm tiene un archivo de configuración llamado package.json. En este archivo podemos mantener la configuración de Npm, como las dependencias que necesitamos y los detalles de la licencia, la descripción, el nombre, etc. Npm proporciona Dependencias y Dependencias. Las dependencias descargarán y mantendrán los archivos 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, se 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 usan ambos es que usan Bower para paquetes de aplicaciones y Npm para herramientas de desarrollador. Multiplicar el administrador de paquetes en su proyecto hace que su flujo de trabajo sea más difícil. Npm 3, junto con Browserify o webpack es el camino a seguir ahora.

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

Por un lado, npm se creó para instalar módulos utilizados en un entorno node.js, o herramientas de desarrollo creadas utilizando node.js, como Karma, pelusa, minificadores, 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 contenga una lista de dependencias. Npm reconoce esa lista cuando ejecuta npm install, que luego los descarga y los instala por usted.
Por otro lado, Bower fue creado para administrar sus dependencias frontend. Bibliotecas como jQuery, AngularJS, guiones bajos, etc. Similar a npm, tiene un archivo en el que puede especificar una lista de dependencias llamada bower.json. En este caso, las dependencias de frontend se instalan ejecutando bower install, que de forma predeterminada las instala en una carpeta llamada bower_components.
Como puede ver, aunque realizan una tarea similar, están dirigidos a un conjunto muy diferente de bibliotecas.

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 utilizar juntos en un solo proyecto.

Preguntas frecuentes sobre las NPM : (archive.org enlace desde el 6 de septiembre de 2015)

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

En la página principal de Bower :

Bower está optimizado para el front-end. Bower utiliza un árbol de dependencia plano, que requiere solo una versión para cada paquete, lo que reduce la carga de la página al 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 se puede ver instala algunas dependencias recursivamente. La 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í se ve 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 para que funcione de todos modos, pero Bower le dará un 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). Tendrás que elegir manualmente qué versión quieres 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 (por ejemplo, tiempo de ejecución , donde evita la duplicación), y utiliza npm para otras cosas, como pruebas, construcción, optimización, verificación, etc. (por ejemplo , tiempo de desarrollo). , donde la duplicación es de menor preocupación).

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 de root)
- 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 los documentos de npm 3

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

El uso programático fue doloroso.
La interfaz de Bower siguió cambiando
Algunas características, como la taquigrafía de la URL, están completamente rotas.
Usar Bower y npm en el mismo proyecto es doloroso
Mantener el campo de la versión bower.json sincronizado con las etiquetas git es doloroso
Control de fuente! = Gestión de paquetes
El soporte de CommonJS no es sencillo

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

Para muchas personas que trabajan con node.js, una de las principales ventajas de Bower es la gestión de dependencias que no son javascript en absoluto. Si están trabajando con lenguajes que se compilan a javascript, npm puede usarse para administrar algunas de sus dependencias. sin embargo, no todas sus dependencias serán módulos de node.js. Algunos de los que compilan en javascript pueden tener una extraña manipulación específica del lenguaje de origen que hace que pasarlos de compilado a javascript sea una opción poco elegante cuando los usuarios esperan el código fuente.

No todo en un paquete npm tiene que ser un javascript para el usuario, pero para los paquetes de biblioteca npm, al menos parte debería ser.

Todos los gestores de paquetes tienen muchas desventajas. Sólo tienes que elegir con qué puedes vivir.

Historia

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

Bower 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, incluyendo JavaScript de propósito general (como country-data de país para información de país o sorts para funciones de clasificación que se pueden usar en el extremo frontal o el extremo trasero).

Bower tiene una cantidad mucho menor de paquetes.

Manejo de estilos etc

Bower incluye estilos, etc.

npm se centra en JavaScript. Los estilos son descargados por separado o requeridos por algo como npm-sass o sass-npm .

Manejo de dependencias

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

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

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

Recursos

Dependencias anidadas : información sobre por qué node_modules funciona de la manera en que lo hace

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

Creo que los carteles anteriores han cubierto bien algunas de las distinciones básicas. (El uso de npm 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).

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

Pero esta distinción de módulos frente a globales (o módulos frente a ''scripts'') 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, como etiquetas `<script>`

En la raíz, Bower se trata de cargar archivos de script sin formato. Independientemente de los archivos de script que contengan, Bower los cargará. Lo que básicamente significa que Bower es como incluir todos sus scripts en <script> antiguos en el <head> de su HTML.

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

Solía ser necesario incluir las dependencias de JS en el repositorio de su proyecto (durante el desarrollo), u obtenerlas a través de CDN. Ahora, puede omitir el peso adicional de la descarga en el repositorio, y alguien puede hacer una instalación rápida y tener al instante lo que necesita, localmente.
Si una dependencia de Bower especifica sus propias dependencias en su bower.json , también se descargarán para usted.

Pero más allá de eso, Bower no cambia la forma en que escribimos javascript . Nada de lo que pasa dentro de los archivos cargados por Bower tiene que cambiar en absoluto. En particular, esto significa que los recursos proporcionados en los scripts cargados por Bower (generalmente, pero no siempre) todavía se definirán como variables globales , disponibles 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 el nodo del nodo (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). Por lo tanto, si usa NPM para manejar las dependencias del lado del navegador (a través de Browserify u otra cosa que haga el mismo trabajo), estructurará su código de la misma manera que lo hace Node.

Personas más inteligentes que yo he abordado la pregunta "¿Por qué módulos?", Pero aquí hay un resumen de la cápsula:

Todo lo que esté dentro de un módulo tiene un espacio de nombre efectivo, lo que significa que ya no es una variable global, y no puede hacer referencia accidentalmente sin tener la intención de hacerlo.
Cualquier cosa dentro de un módulo debe ser inyectado intencionalmente en un contexto particular (generalmente otro módulo) para poder usarlo.
Esto significa que puede tener varias versiones de la misma dependencia externa (lodash, digamos) en varias partes de su aplicación, y no entrarán en conflicto / 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 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 en particular, es muy fácil razonar sobre ellas. Usted sabe a ciencia cierta: "El único código que debo tener en cuenta al trabajar en esto es lo que intencionalmente he elegido inyectar aquí" .
Debido a que incluso el contenido de los módulos inyectados se encapsula detrás de la variable a la que lo asigna, y todo el código se ejecuta dentro de un alcance limitado, las sorpresas y las colisiones se vuelven muy improbables. Es mucho menos probable que algo de una de sus dependencias redefinirá accidentalmente una variable global sin que usted se dé cuenta, o que lo haga. ( Puede suceder, pero por lo general tiene que esforzarse para hacerlo, con algo como window.variable . El único accidente que todavía tiende a ocurrir es asignarle esto) this.variable , sin darse cuenta de que this es realmente una window en la corriente. contexto.)
Cuando quiere probar un módulo individual, puede saber muy fácilmente: ¿qué otra cosa (dependencias) está afectando al código que se ejecuta dentro del módulo? Y, como está inyectando todo explícitamente, puede burlarse fácilmente de esas dependencias.

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

Solo toma alrededor de 30 segundos aprender a usar la sintaxis del módulo CommonJS / Node. Dentro de un archivo JS dado, que va a ser un módulo, primero declara cualquier dependencia externa que quiera usar, como esto:

var React = require(''react'');

Dentro del archivo / módulo, usted hace lo que normalmente haría, y crea algún objeto o función que querrá exponer a usuarios externos, llamándolo quizás myModule .

Al final de un archivo, exportas lo que quieras compartir con el mundo, de esta manera:

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 inyectarlos entre sí según sea necesario.

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

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

EDITAR (febrero de 2017): Facebook''s Yarn es un reemplazo / suplemento potencial muy importante para npm en estos días: rápido, determinístico, gestión de paquetes fuera de línea que se basa en lo que npm le ofrece. Vale la pena ver cualquier proyecto de JS, especialmente porque es muy fácil intercambiarlo.