前言
### 从源码转换讲起
JavaScript脚本正变得越来越复杂。大部分源码(尤其是各种函数库和框架)都要经过转换,才能投入生产环境。
常见的源码转换,主要是以下三种情况:
(1)压缩,减小体积。比如jQuery 1.9的源码,压缩前是252KB,压缩后是32KB。
(2)多个文件合并,减少HTTP请求数。
(3)其他语言编译成JavaScript。最常见的例子就是CoffeeScript。
这三种情况,都使得实际运行的代码不同于开发代码,除错(debug)变得困难重重。
通常,JavaScript的解释器会告诉你,第几行第几列代码出错。但是,这对于转换后的代码毫无用处。
举例来说,jQuery 1.9压缩后只有3行,每行3万个字符,所有内部变量都改了名字。
你看着报错信息,感到毫无头绪,根本不知道它所对应的原始位置。
这就是Source map想要解决的问题。
什么是sourceMap
简单说,Source map就是一个信息文件,里面储存着位置信息。也就是说,转换后的代码的每一个位置,所对应的转换前的位置。
有了它,出错的时候,除错工具将直接显示原始代码,而不是转换后的代码。这无疑给开发者带来了很大方便
引用sourcemap在文件的末尾加上
//# sourceMappingURL = filename.map 这样就会自动请求sourcemap文件,然后逆向解析源代码,便于开发者调试
webpack配置sourcemap
devtool: "source-map",//在webpack中加入这个配置就就可以使用sourcemap了
//其实webpack不仅仅只有这一种模式还有其他模式的sourcemap,一共有12种,每个工作模式有一些差距,毫无疑问
//速度最快的质量最差,速度最慢的质量最好
webpack-sourcemap工作模式
1、devtool api名称
2、build 初次构建速度
3、rebuild 再次构建速度
4、producttion 是否适合生产环境
webpack-sourcemap配置如下
这里对每个模式进行对比
const HtmlWebpackPlugin = require('html-webpack-plugin')
const allModes = [
'eval',
'cheap-eval-source-map',
'cheap-module-eval-source-map',
'eval-source-map',
'cheap-source-map',
'cheap-module-source-map',
'inline-cheap-source-map',
'inline-cheap-module-source-map',
'source-map',
'inline-source-map',
'hidden-source-map',
'nosources-source-map'
]
module.exports = allModes.map(item => {
return {
devtool: item,
mode: 'none',
entry: './src/main.js',
output: {
filename: `js/${item}.js`
},
module: {
rules: [
{
test: /\.js$/,
use: {
loader: 'babel-loader',
options: {
presets: ['@babel/preset-env']
}
}
}
]
},
plugins: [
new HtmlWebpackPlugin({
filename: `${item}.html`
})
]
}
})
我个人比较偏好的devtool配置一般是
devtool :"cheap-module-eval-cource-map"//仅限开发环境
主要有以下几个特点
1、代码每行不会超过80个字符
2、代码经过loader转换过后的差异较大
3、首次打包速度快慢无所谓,重新导报相对较快
devtool:none//生产环境,不生成source-map文件,因为如果暴露sourcemap文件,容易造成源代码泄露,
//一般不建议在生产环境生辰sourcemap文件,如果实在是对自己的代码没有信心的话可以选择nosource-source-map
//这个模式是,会输出源代码出错的行数,并不会暴露出源代码,当然了,这些选择并没有绝对的,主要是看自己的需求
无以至千里.不积小流,无以成江海
谢谢观看,如有不足,敬请指教 不积跬步,