javascript - node - Depuración con webpack, ES6 y Babel
instalar babel js (3)
Esto parece algo que debería haber sido relativamente fácil de lograr, pero lamentablemente.
Tengo clase ES6:
''use strict'';
export class BaseModel {
constructor(options) {
console.log(options);
}
};
y módulo raíz que lo usa:
''use strict'';
import {BaseModel} from ''./base/model.js'';
export let init = function init() {
console.log(''In Bundle'');
new BaseModel({a: 30});
};
Mi objetivo es:
- pase lo anterior a través de Babel, para obtener el código ES5
- empacar los módulos con webpack
- ser capaz de depurar el resultado
Después de una prueba, esta es la configuración del paquete web que tengo:
{
entry: {
app: PATH.resolve(__dirname, ''src/bundle.js''),
},
output: {
path: PATH.resolve(__dirname, ''public/js''),
filename: ''bundle.js''
},
devtool: ''inline-source-map'',
module: {
loaders: [
{
test: //.js$/,
exclude: /(node_modules|bower_components)/,
loader: ''babel''
}
]
}
}
Esto parece estar funcionando, hasta cierto punto.
Entonces, puedo hacer eso:
Puedo hacer clic en F11 e ingresar el código, pero no puedo evaluar
BaseModel
:
que de alguna manera derrota el propósito (o uno de los propósitos) de la depuración.
Intenté
agregar
source-map-loader
en varios orden con
babel-loader
:
{
test: //.js$/,
loader: "source-map-loader"
}
en vano.
Nota al margen 1 : si abandono el paquete web y solo compilo mis módulos con mapas fuente a través de Babel en, por ejemplo, System.js:
babel src/ --out-dir public/js/ --debug --source-maps inline --modules system
- Todo funciona correctamente.
Nota al
?sourceMaps=true
2
: this
?sourceMaps=true
no parece hacer nada en absoluto, ya que, si elimino la configuración del mapa fuente del paquete web, no se conservan / generan mapas fuente.
Uno esperaría que los mapas fuente iniciales, producidos por Babel, se conservaran en los archivos resultantes.
No
Cualquier sugerencia sería muy apreciada
Deberá usar los nombres de las variables compiladas, no los originales. Los mapas fuente solo permiten que el navegador muestre el código fuente que corresponde al código compilado; no pueden hacer que el navegador resuelva los nombres de variables originales del código compilado.
Para ver los nombres de las variables compiladas, cambie a la fuente compilada o busque en el panel Variables de alcance a la derecha, que le mostrará (como dice en la lata) qué variables existen en el alcance actual.
IIRC Babel tiende a prefijar los nombres de los módulos con
_
, por lo que su variable
BaseModel
probablemente se llama
_baseModel
o similar.
Este es un problema con los mapas fuente de Javascript, que
actualmente no admiten nombres de símbolos de mapeo
, y babel, que cambia los nombres de
import
módulos
import
cuando se compila a CommonJS desde la sintaxis del módulo ES2105.
Babel hace esto para respaldar plenamente el hecho de que los módulos ES2015 exportan enlaces resolviendo todas las referencias a importaciones cada vez que se usan en código, en lugar de en el momento de la importación.
Si no está escribiendo módulos que dependen de la exportación de enlaces (como es probable, ya que en realidad no podría hacer esto con CommonJS), entonces puede preferir conservar los nombres de las variables al transpilar ES2015.
Creé una alternativa a la transformación del módulo nativo babel commonjs para Babel 6 que conserva los nombres de las variables:
babel-plugin-transform-es2015-modules-commonjs-simple
.
Este es un reemplazo
babel-plugin-transform-es2015-modules-commonjs
para
babel-plugin-transform-es2015-modules-commonjs
, la transformación nativa de babel.
Puede usar esto con webpack o nodo. Una configuración típica podría ser:
npm install --save-dev babel-preset-es2015-webpack
npm install --save-dev babel-plugin-transform-es2015-modules-commonjs-simple
El módulo
babel-preset-es2015-webpack
es una bifurcación del preajuste estándar es2015 que
no
incluye la transformación del módulo, ya que desea utilizar la versión alternativa.
Esto funciona para el nodo también.
Estos módulos se usan en
.babelrc
:
{
"presets": [
"es2015-webpack"
],
"plugins": [
"transform-runtime",
["transform-es2015-modules-commonjs-simple", {
"noMangle": true
}]
]
}
transform-runtime
suele ser una buena idea incluir en cualquier proyecto sustantivo para evitar la repetición adicional del código generado.
Configuración típica del módulo en
webpack.config.js
:
module: {
loaders: [
{
loader: "babel-loader",
include: [path.resolve(__dirname, "src")]
}
]
},
devtool: ''#inline-source-map''
El código resultante no cambiará los nombres de las importaciones, por lo que la depuración con mapas de origen le proporcionará acceso a los símbolos.
Tuve un buen éxito al agregar la declaración
depurador
en sus archivos javascript / mecanografiados incluso en archivos marco de angular o vue2 como * .vue
Por lo tanto, incluso si el archivo se convierte o cambia o cambia de nombre o sus asignaciones de ruta a URL no funcionan, el depurador continuará de todos modos.