Hasta hace muy poco (el último año o dos), había una diferencia bastante dramática entre la administración / dependencias de paquetes en Node.js (back-end) y el navegador Javascript. En estos días, la creciente popularidad de los transpiladores y paquetes como Webpack y Browserify significa que esas diferencias se están borrando : los desarrolladores simplemente pueden usar su administrador de dependencia preferido en el front- end además del backend.
Por cierto, si está comenzando un nuevo proyecto front-end y se pregunta qué paquete elegir, use Webpack.
Dependencias de back-end (Node.js)
- ¿Con qué trata un desarrollador web front-end?
- ¿Qué pasos debo seguir para convertirme en desarrollador web de backend?
- ¿Qué factores se deben tener en cuenta al seleccionar un lenguaje de programación de fondo para crear un nuevo sitio web?
- ¿Cuál es el mejor marco de back-end para un desarrollador con un fondo PHP / JS / C #?
- ¿Las fases malas de la vida finalmente terminan como las buenas siempre terminan o pierden la emoción?
npm
La gran mayoría de los proyectos de back-end utilizan el propio administrador de paquetes de Node, npm , para la gestión de dependencias. Hay muchas razones para usarlo (tiene la mayoría de los paquetes, es el más simple / mejor conocido por la mayoría de los desarrolladores).
Con el surgimiento de Webpack y compañía, también se está utilizando cada vez más para la administración de paquetes front-end.
Cenador
Bower comenzó como administrador de paquetes front-end, pero ocasionalmente también se usa en el backend (especialmente en proyectos de pila completa).
Se afirma que su principal ventaja es el hecho de que, a diferencia de npm, que tiene dependencias anidadas, Bower tiene una estructura de dependencia plana . No entraré en detalles particulares aquí, pero esencialmente Bower hace una compensación de un tamaño de dependencias general más pequeño, a cambio de una mayor carga cognitiva en el desarrollador (para resolver las diferencias de versión entre dependencias comunes).
Lo principal a tener en cuenta es que en estos días, npm tiene la capacidad de hacer lo mismo (aplanar el árbol de dependencia anidado) a través de npm dedupe .
Ver también:
- ¿Cuál es la diferencia entre Bower y npm?
- ¿Por qué deberíamos dejar de usar Bower? Y cómo hacerlo
Hilo
En octubre de 2016, Facebook lanzó Yarn, su propio administrador de paquetes. Lo crearon para resolver sus propios problemas de rendimiento a escala de Facebook: se supone que es mucho más rápido, tiene mejoras en términos de vinculación y almacenamiento en caché de paquetes, etc.
También se supone que es compatible con los paquetes npm y Bower. No lo he usado personalmente, realmente no he tenido sus problemas de escala y no necesito invertir el tiempo para aprenderlo.
Dependencias de front-end
Antes de la popularidad de Webpack y Browserify, y hasta cierto punto incluso hoy, por inercia, la mayoría de los desarrolladores usaban uno de los siguientes:
- Cenador
- Sin administrador de dependencias (enlazando directamente a varias bibliotecas de dependencias, a través de etiquetas
individuales). - Cualquiera que sea la tubería de compilación que utilice su pila de back-end (Ruby on Rails, Django, etc.).
