javascript - how - Requirejs vs browserify vs webpack para js orden de carga: ¿estoy cambiando la situación de un lado a otro?

javascript create a module

Question

Ok, es 2016. Webpack parece ser un ganador frente a requirejs y browserify . He estado leyendo sobre esas 3 tecnologías, para resolver un problema muy específico. Quiero evitar esto en mi archivo HTML (parte de una aplicación AngularJS)

<script src="some-file.js"></script>
<script src="some-file2.js"></script>
<script src="some-file3.js"></script>
<!-- Dozens of similar lines here... -->

Por supuesto, el orden de esas líneas en mi archivo HTML es importante . Bootstrap te pedirá jQuery, etc.

Lo primero que encontré: requirejs. Solo especificas algo como esto:

<script src="my-bundled-file.js"></script>

Y luego, resuelves el problema de dependencia con JS. Yendo más allá, encontré 2 enfoques aquí:

• CommonJS (browserify)
• AMD (require.js)

Webpack funciona con ambos enfoques, lo que suena bien.

Al final, las 3 herramientas se pueden usar para lo mismo: agrupar varios archivos en uno solo . Pero lo que me preocupa es el orden en que se agrupan esos archivos .

No quiero preocuparme por esto, y parece que estoy usando esas soluciones (o incluso gulp + gulp-concat, como se sugiere here ), solo estoy cambiando el problema: ahora, especifico los módulos que mi aplicación usa con Código JS, pero todavía necesito colocar los módulos en el orden correcto , incluso con WebPack (un ejemplo here : las llamadas require deben estar en el orden correcto)

Entonces, mis preguntas:

• ¿Estoy entendiendo mal estas herramientas? Solo quiero resolver el problema del orden de carga y parece que no lo estoy haciendo
• ¿Resuelven estas herramientas un problema diferente (falta de módulos nativos en ES5, qué impulsa a contaminar el alcance global)?

Answer 1

¿Estoy entendiendo mal estas herramientas? Solo quiero resolver el problema del orden de carga y parece que no lo estoy haciendo

Pienso que si. Con CommonJS y las herramientas que lo agrupan, el orden de carga se vuelve en gran medida irrelevante, algo que no necesita administrar. Solo require() lo que necesita donde lo necesita. Hay algunos casos en los que sigue siendo relevante, pero en su mayoría tienen que ver con efectos secundarios globales y dependencias circulares. Usar CommonJS y agruparlo es totalmente diferente de concatenar una serie de scripts.

¿Resuelven estas herramientas un problema diferente (falta de módulos nativos en ES5, qué impulsa a contaminar el alcance global)?

El sistema de módulos CommonJS está diseñado para abordar la falta de módulos nativos en JavaScript y se utiliza una versión en Node. El encabezado en Browserify es "módulos de nodos agrupados para el navegador", aunque en la práctica también se utiliza para crear paquetes que se ejecutan en Nodo y para módulos de paquetes destinados únicamente a ejecutarse en el navegador.

En los módulos de agrupación de nodos no es necesario porque Node envuelve el código que ejecuta y proporciona una implementación para su semántica de módulos. Para ejecutar los módulos que utilizan ese sistema en los navegadores, debe empaquetarlos porque el navegador no ajusta el código para proporcionarle las cosas que conforman la interfaz del módulo, como require() , module , exports . Eso es parte de lo que un bundler hace por usted: envuelve el código para proporcionar esa interfaz.

Otra cosa que hace por usted, que responde a su pregunta sobre el pedido, es descubrir dependencias recursivamente. Así que, como he dicho, require() lo que necesita donde lo necesita y apunta el agrupador a un script de entrada. El agrupador analizará el script para encontrar cualquier require() e incluirá los módulos a los que hace referencia en el paquete. Se repetirá eso para esos módulos, ad infinitum.

Creo que encontrará mucha más tracción para CommonJS sobre AMD, pero diría que hay mucho más que una clara victoria para Webpack sobre Browserify. Ambos son populares. Browserify es ampliamente utilizado, incluso para construir partes de proyectos como Babel y React.

Mi consejo sería comenzar con los módulos CommonJS estilo Node y Browserify (nota: soy un mantenedor de Browserify).

Hasta que no entienda mejor esto, sugeriría que no utilice nada relacionado con Angular como referencia para hacer las cosas en términos de la modularización de CommonJS. Creo que tenían muchos problemas para conseguir que el paquete Angular npm tomara la forma adecuada de CommonJS.