¿Es un paquete acumulativo para la biblioteca? !

Escribir al frente


Rollup was designed with libraries rather than apps in mind, and it is a perfect fit for React’s use case.

Vi esto en Behind the Scenes: Improving the Repository Infrastructure - React Blog. Me sorprendió un poco. ¿Por qué es algo tan bueno solo para las bibliotecas de clases? ¿Qué lo hace inadecuado para crear aplicaciones?

Zero.webpack
¿Es un paquete acumulativo para la biblioteca?  !

webpack apuesta por la construcción modular de SPA complejas, lo que resulta muy atractivo son varios cargadores:


Essentially, webpack loaders transform all types of files into modules that can be included in your application’s dependency graph.

Maneje varias dependencias de recursos de manera coherente, protegiendo las diferencias de tipo de recurso a través del cargador (js es módulo, css es módulo, img también es módulo ...), las ventajas son las siguientes:


No more carefully placing your files in the right folders and hacked-together scripts for adding hashes to file URLs — webpack can take care of it for you.

Otras características muy poderosas incluyen:

División de código: carga bajo demanda / carga paralela en el entorno de producción

Tree Shaking: Elimina el código inútil (exportar) al construir

HMR: Reemplazo en caliente de módulos en desarrollo

Commons Chunk: extrae dependencias comunes durante la construcción

Gráfico de dependencia: una vez que se completa la compilación, el gráfico de dependencia del módulo de salida hace que el paquete sea legible

1. El
resumen de intenciones original es para el módulo ES6 desde el principio:


Next-generation ES6 module bundler.

En ese momento, la disputa de formato entre AMD, CMD y UMD todavía estaba muy caliente, y el módulo ES6 aún no se había implementado en un navegador. rollup acaba de salir


Rollup was created for a different reason: to build flat distributables of JavaScript libraries as efficiently as possible, taking advantage of the ingenious design of ES2015 modules.

(Citado de Webpack y Rollup: el mismo pero diferente, escrito por el autor del rollup)

Espero hacer un uso completo del mecanismo del módulo ES6 para construir un paquete de biblioteca de clases con estructura plana y rendimiento sobresaliente, que está diseñado para biblioteca

2. Principales ventajas


It solves one problem well: how to combine multiple modules into a flat file with minimal junk code in between.

Lo sorprendente del rollup es la limpieza de su paquete, especialmente el formato iife, el contenido es muy limpio, no hay código adicional, es realmente solo que los módulos están empalmados en orden de dependencia.

Esto está relacionado con la idea de procesamiento del módulo de acumulación:


To achieve this, instead of turning modules into functions like many other bundlers, it puts all the code in the same scope, and renames variables so that they don’t conflict. This produces code that is easier for the JavaScript engine to parse, for a human to read, and for a minifier to optimize.

Todos los módulos se colocan planos en el alcance más externo del archivo del paquete. No hay aislamiento de alcance entre los módulos, y el cambio de nombre se usa para resolver el problema de los conflictos de nombres en el mismo alcance. Varios beneficios obvios:

Rendimiento en tiempo de ejecución (estructura de código plano para un análisis sencillo)

Legibilidad del código fuente del paquete (estructura de orden natural, sin definición / salto de módulo)

La compresión se puede optimizar (sin definiciones de módulo y otro código repetitivo sin comprimir)

Las desventajas de esto también son obvias:

El sistema de módulos es demasiado estático y las funciones como HMR son difíciles de lograr

Solo para los módulos ES6, no puede manejar de manera confiable las dependencias de cjs y umd (encontrará problemas cada vez que use rollup-plugin-commonjs)

Si es solo para lib, no importa si el primer punto no es compatible, pero el segundo punto es realmente un dolor de cabeza. La dependencia secundaria es incontrolable. Siempre es inevitable que encuentre algunos problemas de que los módulos cjs no se puedan convertir automáticamente a módulos ES6. P.ej:


‘foo’ is not exported by bar.js (imported by baz.js)

Algunos escenarios pueden resolverse infelizmente mediante Troubleshooting a través de namedExports, otras veces a través de externos o globales, e incluso hay soluciones que necesitan ajustar el orden de las aplicaciones de plugins ... Pero no hay forma de resolver por completo este tipo de problemas:


Webpack gets around the need for namedExports by keeping everything as CommonJS modules and implementing Node’s require system in the browser, which is why the resulting bundles are larger and take longer to start up. Both options are valid, but that’s the tradeoff to be aware of — more config (Rollup, when using modules like React), or larger bundles (webpack).

(引 自 ¿Es una característica o un error de "exportaciones con nombre"?)

Aunque cjs eventualmente se convertirá en historia, todavía hay bastantes módulos cjs en npm en la actualidad y ahora. Ya sea SPA o biblioteca, todavía enfrentan el problema de lidiar con las dependencias del módulo cjs.

3. Principio de selección
Utilice webpack para aplicaciones y Rollup para bibliotecas

Para la creación de aplicaciones, el paquete web es más adecuado, si es una biblioteca de clases, por supuesto, el paquete acumulativo es mejor

Las ventajas de webpack to build App se reflejan en los siguientes aspectos:

Potente ecología de complementos, los marcos frontales principales tienen el cargador correspondiente

El soporte de funciones orientadas a la aplicación, como el HMR antes mencionado, la división de código, el fragmento común, etc., son características necesarias para el desarrollo de aplicaciones.

Simplifique todos los aspectos del desarrollo web, incluyendo base64 automático para imágenes, almacenamiento en caché de recursos (chunkId), división de código por ruta, carga diferida, etc. No es difícil de lograr

Manejo confiable de módulos dependientes, a diferencia del rollup que enfrenta los problemas de cjs, __webpack_require__ no tiene estos problemas

El resumen no tiene estas ventajas y encontrará algunos problemas que no son fáciles de resolver al dividir el código. Si no tiene suficiente tiempo y comprensión, no intente usar el resumen como una herramienta de creación de aplicaciones.

La ventaja del rollup radica en el paquete de alta eficiencia, que es exactamente lo que persigue la biblioteca. Incluso si tiene un pequeño contratiempo (como lo hace React 16), vale la pena por el rendimiento

Tenga en cuenta que este principio solo dice que use la herramienta correcta para hacer lo correcto. Es adecuado para la mayoría de los escenarios generales. También es muy común usar rollup para crear aplicaciones y paquetes web para crear bibliotecas de clases:


That’s not a hard and fast rule — lots of sites and apps are built with Rollup, and lots of libraries are built with webpack. But it’s a good rule of thumb.

Por lo general, si la empresa en sí no depende de demasiados módulos de terceros y la convención de estilo sigue al módulo ES6, también es apropiado crear una aplicación con paquete acumulativo (división de código, etc.)

PD Además, el rollup no es fácil de realizar extensiones basadas en stream como glup o webpack, como separar tres partes de un archivo vue y procesar por separado (el plugin vue no parece ser compatible con ts)

4. Las dependencias externas son

para React y otras clases Las bibliotecas deben separarse como dependencias de terceros tanto como sea posible, en lugar de integrarse en paquetes, por varias razones:

El rendimiento se deteriorará. Por ejemplo, React 16 requirió un gran esfuerzo para cambiar a rollup + GCC (Google Closure Compiler), que alcanzó los 109kb. Lo compilé una vez y volví a antes de la liberación.

No favorece el almacenamiento en caché. Las bibliotecas de clases no se actualizan con frecuencia y se pueden utilizar como recursos estáticos para aprovechar al máximo las ventajas del almacenamiento en caché. El contenido de la compilación manual se ve afectado por la configuración de la herramienta

Las dependencias externas se pueden marcar a través de la configuración externa + global en el resumen:


external: ['react', 'react-dom'],
output: {
  globals: {
    'react': 'React',
    'react-dom': 'ReactDOM'
  }
}

El paquete generado de esta manera es:


// iife
(function (React,ReactDOM) {
    //...
}(React,ReactDOM));

// cjs
var React = _interopDefault(require('react'));
var ReactDOM = _interopDefault(require('react-dom'));

Por lo tanto, el código comercial generalmente se empaqueta en iife, y luego se hace referencia a la biblioteca de clases CDN de terceros a través de un script:


<script crossorigin src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>
<!-- 或者聚合的版本 -->
<script crossorigin src="//cdn.jsdelivr.net/combine/npm/[email protected]/umd/react.production.min.js,npm/[email protected]/umd/react-dom.production.min.js"></script>

Los externos y globales de PSrollup son un poco extraños, ya sea clave o de valor, o estas dos cosas deben usarse juntas, para obtener más información, consulte [pregunta] Diferencia entre

referencias
externas y globales
Webpack y Rollup: lo mismo pero diferente: muy interesante Encontrado demasiado tarde

Manejo de JavaScript de terceros con Rollup

Supongo que te gusta

Origin blog.51cto.com/15080030/2592709
Recomendado
Clasificación