javascript - run - webpack wikipedia

Salida de un módulo de ES usando webpack

Question

Con Rollup puedo enviar un módulo ES simplemente configurando la opción de format en ''es'' . ¿Cómo puedo hacer lo mismo con el paquete web? Si no es posible ahora, ¿webpack tiene algún plan para agregarlo?

Lo único que he encontrado en la documentación para output.libraryTarget que menciona los módulos ES es esto:

libraryTarget: "commonjs-module" - module.exports usando el objeto module.exports ( output.library es ignorado), __esModule está definido (está enhebrado como módulo ES2015 en modo interoperativo)

Sin embargo, no está claro para mí. ¿Es lo mismo que libraryTarget: "commonjs2" con la única diferencia de que __esModule está definido? ¿Qué es el "modo de interoperabilidad"?

Answer 1

En primer lugar, me gustaría establecer la diferencia entre commonJS y commonJS2

CommonJS no admite el uso de module.exports = function() {} que es utilizado por node.js y muchas otras implementaciones commonJS .

Webpack2 emplea el concepto de agrupar el código de la biblioteca y para el uso generalizado de la misma y para que sea compatible con el trabajo en diferentes entornos usamos la opción - libraryTarget

Ahora la parte aquí responderá sus dos preguntas

Las posibles opciones de biblioteca admitidas en webpack2 son

• libraryTarget: "umd", // enum
• libraryTarget: "umd-module", // ES2015 module wrapped in UMD
• libraryTarget: "commonjs-module", // ES2015 module wrapped in CommonJS
• libraryTarget: "commonjs2", // exported with module.exports
• libraryTarget: "commonjs", // exported as properties to exports
• libraryTarget: "amd", // defined with AMD defined method
• libraryTarget: "this", // property set on this
• libraryTarget: "var", // variable defined in root scope

Interlop tiene el siguiente significado

Para fomentar el uso de los módulos CommonJS y ES6 , al exportar una default export sin ningún otro module.exports exports se establecerán además de las exports["default"] como se muestra en el siguiente ejemplo

export default test;
exports["default"] = test;
module.exports = exports["default"];

Así que, básicamente, significa que el commonJS-module se puede usar exponiéndolo como module.exports utilizando el módulo de enclavamiento con ES2015 envuelto en commonJS

Se puede encontrar más información sobre el interloping en este blogpost y en el link stackoverflow.

La idea básica es que en ES6 runtime las propiedades de exportación e importación no se pueden cambiar, pero en commonJS esto funciona bien ya que los cambios requeridos ocurren en el tiempo de ejecución, por lo tanto, ES2015 está enlazado con commonJS .

Actualizar

Webpack 2 ofrece la opción de crear la biblioteca que se puede agrupar e incluir .

Si desea que su módulo se use en diferentes entornos , puede agruparlo como una biblioteca agregando las opciones de la biblioteca y enviarlo a su entorno específico . Procedimiento mencionado en los docs .

Otro ejemplo simple sobre cómo usar commonjs-module

Un punto importante a tener en cuenta aquí es que babel agrega exports.__esModule = true a cada es6 module y al importarlo llama al _interopRequire para verificar esa propiedad.

__esModule = true debe establecerse solo en la exportación de la biblioteca . Debe establecerse en las exports del módulo de entrada . Los módulos internos no necesitan __esModule , es solo un truco de Babel.

Como se menciona en los documentos

__esModule está definido (está enhebrado como módulo ES2015 en modo interoperativo )

Uso como se menciona en los casos de prueba

export * from "./a";
export default "default-value";
export var b = "b";
import d from "library";
import { a, b } from "library";

Answer 2

Webpack2 aún no tiene libraryTarget relevante, no genera paquetes ES6. Desde el otro lado Si agrupa su biblioteca en CommonJS, los bundlers no podrán ejecutar Tree Shaking, ya que no podrán eliminar módulos que no se usen. Eso se debe a que los módulos de ES aún están en desarrollo, por lo que nadie envía paquetes ES al navegador, mientras que el paquete web se usa principalmente para crear paquetes habilitados para el navegador.

Desde el otro lado, si está publicando una biblioteca, puede proporcionar los objetivos CommonJS (umd) y ES, gracias a la clave "módulo" en el paquete. json . En realidad, no necesitas un paquete web para publicar el objetivo ES, todo lo que necesitas hacer es ejecutar babel en cada archivo para obtener el estándar es2015, por ejemplo, si estás utilizando reaccionar, puedes ejecutar babel con el preajuste "reaccionar". Si su fuente ya es ES 2015 sin características adicionales, puede apuntar el módulo directamente a su src / index.js:

//package.json
...
"module": "src/index.js"
"main": "dist/your/library/bundle.js
...

Me pareció conveniente usar babel para manejar export v from ''mod'' instrucciones export v from ''mod'' en mi index.js principal, así que tengo 1 archivo de módulo exportando todos mis módulos. Esto se logra con babel-plugin-transform-export-extensions (también incluido en el preajuste Stage-1).

Veo este enfoque desde la biblioteca reaccionar-bootstrap, puedes ver scripts en su github (son webpack1). He mejorado un poco sus scripts en mi repos-sigma repo , puede copiar los siguientes archivos que harán lo que necesita:

config/babel.config.js
scripts/buildBabel.js
scripts/es/build.js
scripts/build.js // this is command line controller, if you need just ES you don''t need it

También mire lib target (scripts / lib / build.js y .babelrc), proporciono lib transpiled modules para que los usuarios de la biblioteca puedan incluir solo los módulos que necesiten incluso sin que ES especifique explícitamente require ("react-sigma / lib / Sigma /") , ¡especialmente útil si tu lib es pesado y modular!