此文已由作者刘诗川授权网易云社区发布。
欢迎访问网易云社区,了解更多网易技术产品运营经验。
使用webpack也有一段时间了,经常是照搬别人的设置,并不知道为什么要这么做,所以决定结合自己在使用webpack中学习到的经验和遇到的问题进行一下总结。本文并没有涵盖所有的webpack配置。
CLI
就是command line interface
的缩写,就是在命令行模式下使用webpack,最简单的用法就是
webpack <entry> <output>
虽然还可以加入一些基础的设置,但是这种用法远远达不到我们的要求,远不如通过一个config文件来控制显得直观和可控,但是CLI模式中有许多参数我们还是配合config文件来使用的,比如
-d
或者-p
可以快速应用webpack debug模式或者production模式所需的一些常用设置,比如sourcemap,代码压缩等--watch
可以设置webpack监控entry中的文件改动,自动重新编译--progress
可以设置webpack在编译时显示编译的百分比进度--colors
输出结果带彩色,比如:会用红色显示耗时较长的步骤--profile
输出性能数据,可以看到每一步的耗时--display-modules
默认情况下 node_modules 下的模块会被隐藏,加上这个参数可以显示这些被隐藏的模块webpack主要的使用方式还是通过文件来配置,默认的配置文件名为webpack.config.js,可以通过webpack --config example.config.js
来设置成其他文件名。
entry就是webpack编译打包功能的入口配置,它可以是字符串、数组或者一个对象,output就是webpack的最终打包的输出文件
entry
如果为字符串就代表一个入口文件,数组代表多个入口文件,这两种情况如果没有特殊配置,最终都会打包成一个文件,即output指定的文件名;entry
如果为对象一般都会指定2个以上的多个入口文件,比如:
entry: {
page1: './page1',
page2: ['./entry1', './entry2']
},
这种情况下,output必须是按照entry指定的输出文件名,比如:
output: {
filename: '[name].bundle.js',
chunkFilename: '[id].bundle.js'
}
其中[name]
代表entry设置中对应的键名page1
、page2
,[id]
代表webpack打包中自动给各个模块所设置的模块id;
output
中filename
就是与entry对应的输出文件,而chunkFilename
指的是一些并未在entry中指定输出文件名的输出文件,比如通过CommonJS的require.ensure方法异步加载的文件模块(下文会介绍);
output
的publicPath
就是css中引用的图片、字体或其他文件路径经过webpack打包后得到的新路径,或者是图片上传后的cdn地址, 比如在CSS中有以下图片引用:
div{
background-image: url(../images/picA.jpg);
}
而output中publicPath
设置为:
output: {
path: './dist',
publicPath: './dist/images'
},
再配合webpack中处理图片的loade配置:
{
test: /\.(png|jpg|GIF)$/,
loader: 'file-loader?name=/dist/images/[name].[ext]'
}
最终打包得到的css中图片的地址就是我们想要的位置,即:
div{
background-image: url(./dist/images/picA.jpg);
}
resolve
是用来配置webpack如何解析模块路径的,这里只介绍一些常用的配置
resolve.alias
就是使用别名来处理模块,就是把用户对某个模块的请求重定向到alias指定的路径,比如:
entry: 'entry.js',
output: {
filename: 'bundle.js'
},
resolve: {
alias: {
moment: "moment/min/moment-with-locales.min.js"
}
}
这样待打包的entry.js
中的require('moment');
其实就等价于 require('moment/min/moment-with-locales.min.js');
这样做的好处是如果待打包的JS中引用了moment
这个模块,webpack就不需要去解析node_modules
中引入的moment包的整个内容,因为这个包中含有大量的涉及时间本地化的一些逻辑文件,这些文件其实都是不需要webpack去关心的,解析这些文件会拖慢我们的打包速度;而使用了别名后,打包moment
这个模块的时间将会缩短一半以上。
resolve.root
指定的是并未存放在node_modules
文件夹下的自定义模块的路径
resolve.fallback
是模块在root及默认路径下都未找到时的最终查找路径
modules
就是配置webpack如何使用各种loaders来解析各种类型的模块的,这部分还是比较简单直观的,主要介绍一些其他经验
webpack使用loaders解析模块时,分别有个3个状态,分别是preloaders,loaders,postloaders
,分别代表前中后三个处理状态,这个不是很常用,官方的建议是:
noParse
是webpack中一个比较有用的配置项,如果你确定一个模块中没有其它新的依赖 就可以配置这项,webpack 将不再扫描这个文件中的依赖:
module: {
noParse: ['/moment-with-locales/']
}
这样设置noParse
后,再结合上面的alias配置,webapck的解析moment
流程为:
entry.js
文件对 moment
的请求;alias
重定向,转而请求 moment/min/moment-with-locales.min.js
;noParse
规则中的 /moment-with-locales/
一条生效,所以 webpack 就直接把依赖打包进了 bundle.js
。这样又进一步减少了webpack的打包时间,因为webpack甚至不需要知道moment中的内容。
externals
指明了那些模块不需要被webpack打包进最后的bundle,而是通过单独的请求来获取,这样就可以配合一些已有的CDN服务来提高访问的速度,还可以提高打包的速度,减小打包文件的体积。比如还是上文的moment模块,就可以使用externals
将它声明为一个外部依赖:
externals: {
moment: true
}
然后在html页面中手动引入或者借助一些插件引入:
<script src="//apps.bdimg.com/libs/moment/2.8.3/moment-with-locales.min.js"></script>
这样又可以进一步减少webpack打包时间。
webpack的devtool
用于在对打包后的文件进行调试时方便进行错误定位,它有7种模式,而且模式之间还能任意组合。
eval
每个模块被转化为字符串,在尾部添加//# souceURL
(指明eval前文件)后,被eval包裹起来source-map
最原始的source-map实现方式,打包代码的同时生成一个sourcemap文件,并在打包文件的末尾添加//# sourceMappingURL
,该注释会告诉JS引擎sourcemap文件的位置hidden-source-map
打包结果与source-map
一致,但是打包文件结尾不显示//# sourceMappingURL
,JS引擎依靠打包的文件名去查找相应sourcemap文件inline-source-map
直接打包文件的结尾追加包含打包前的每个文件的完整sourcemap信息的//# sourceMappingURL
, 该信息为Base64编码的字符串eval-source-map
将每个模块转化为字符串,使用eval包裹,并将打包前每个模块的sourcemap信息转换为Base64编码,拼接在每个打包后模块的结尾cheap-source-map
与source-map
模式原理相同,但是不包含源文件的列信息,也不包含 loader 的 sourcemap,(譬如 babel 的 sourcemap)cheap-module-source-map
不包含列信息,同时 loader 的 sourcemap 也被简化为只包含对应行的,在打包文件的末尾通过//# sourceMappingURL
标识对应的sourcemap文件位置这么多的模式,不可能都使用,所以,开发环境下,推荐使用cheap-module-eval-source-map
,这是cheap-module-source-map
和eval
模式的组合,也是webpack使用-d
命令下的默认模式;而生产模式下,推荐使用cheap-module-source-map
模式。
最后介绍一些比较实用的webpack插件,它们的功能非常全面。
这是个很常用的插件,用途就是把打包在js中的css提取出来,成为一个单独的css文件,用法为:
var ExtractTextPlugin = require("extract-text-webpack-plugin");
module.exports = {
module: {
loaders: [
{ test: /\.css$/, loader: ExtractTextPlugin.extract("style-loader", "css-loader") }
]
},
plugins: [
new ExtractTextPlugin("styles.css")
]
}
针对某些或全部css文件的loader使用,loader对应值的写法为:ExtractTextPlugin.extract([notExtractLoader], loader, [options])
,需要注意的是options
中publicPath
这个配置,可以覆盖webpack的output
中设置的publicPath
的,但是只针对这一个loader对应的文件。
这是webpack内置的plugin,用作页面模块的热替换。就是在webpack运行了一次打包后不会直接结束,而是继续监视着入口资源文件,一旦他们发生改动,可以通过页面与服务端建立的WebSocket
连接立即通知页面进行模块的热替换,而不需要自己手动或自动刷新整个页面。 要使用这个插件,webpack.config.js
需要进行如下设置:
plugins:[
new webpack.HotModuleReplacementPlugin(),
]
然后需要借助一个Node脚本server.js
对webpack-dev-server
进行如下设置:
var webpack = require('webpack');
var webpackDevServer = require('webpack-dev-server');
var config = require("./webpack.config.js");
config.entry.app.unshift("webpack-dev-server/client?http://localhost:8090/", "webpack/hot/dev-server");
var compiler = webpack(config);
var server = new webpackDevServer(compiler, {
hot: true,
historyApiFallback: true,
noInfo: true,
stats: { colors: true }
});
server.listen(8090);
它的原理就是给webpack的entry注入热替换的代码模块,然后通过webpack-dev-server
这个小型的Node Express
服务器对生成的文件提供访问。 最后,通过运行node server.js
,页面就可以通过localhost:8090
进行访问并且具有热替换功能了。
附上一张代码热替换的console
信息图:
其实以上这些配置,其实完全可以通过一行Webpack-dev-server CLI
命令来实现,就是在安装了webpack-dev-server
的前提下,运行webpack-dev-server --inline --hot
,它会自动进行所需要的代码注入。 我之所以更愿意选择用Node.js API的方式来运行,除了这样的配置更加直观可控外,还可以配合nodemon
插件,实现前后端全部自动刷新:直需要安装nodemon
插件,然后把node server.js
改为nodemon server.js
就可以了。
CommonsChunkPlugin
也是webpack内置的plugin,它的作用是可以将webpack入口文件中的共用模块提取出来单独生成一个文件,这样的话,再配合浏览器的缓存,这些共用的文件就只需要第一次访问服务器进行获取,之后的访问就可以从缓存来获取来访问的速度,而不是每次都重新从一个较大的js文件来获取。 这里用Vue
官方提供的脚手架中的webpack CommonsChunkPlugin
配置来进行分析,这应该是比较规范的公共包的提取方案。
entry: {
app: ['./src/main.js'],
},
output: {
path: path.resolve(__dirname, 'dist'),
publicPath: './',
filename: '[name].[chunkhash:7].js', //使用模块名加hash的方式,既便于理解和管理,也便于CDN缓存的利用和更新
chunkFilename: '[id].[chunkhash:7].js'//对应于未指定模块名的模块生成的文件,稍后会介绍
},
plugins: [
// 提取node_modules中的代码成vendor模块,这些模块一般很少变动
// 提取出来以后可以充分利用webpack的缓存,加快二次打包的速度,还可以结合浏览器的缓存加快页面的加载速度
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
minChunks: function(module, count) {
// any required modules inside node_modules are extracted to vendor
return (
module.resource &&
/\.js$/.test(module.resource) &&
module.resource.indexOf(
path.join(__dirname, './node_modules')
) === 0
)
}
}),
// 将上面代码打包的vendor模块中的共用模块打包成manifest模块
// 这里面主要包括的是webpack模块机制的底层代码(`webpack bootstrap logic`)和底层代码构建好后需要启动的模块的清单(`module manifest`)
// 在使用webpack给生成的模块添加chunkhash后,随着业务代码的改变,业务代码的hash也随之改变
// 本模块引用的模块清单也发生了改变,从而本模块的hash也会改变,但是却很大几率能使得由node_modules打包的vendor模块的hash无需改变
// 从而更有效率的利用好浏览器的缓存,提高加载速度,节省用来流量等
new webpack.optimize.CommonsChunkPlugin({
name: 'manifest',
filename: '[name].[hash:7].js',
chunks: ['vendor']
}),
]
这样配置的原因参考代码中的注释,其中manifest
模块需要单独设置filename
为'[name].[hash:7].js'
,否则将会在打包过程中报错。 通过上述设置实现的打包hash变化过程如下:
我在这两次打包之间只是修改了一个Vue组件的标题文字,可以看到,通过上述设置,只改变了manifest
和app
两个模块的hash,而存放node_modules
模块的vendor
模块hash并为改变,从而使得用户访问改动后的页面的时候可以更大限度的利用缓存来提高访问速度。
相关文章:webpack常用配置详解下篇
免费领取验证码、内容安全、短信发送、直播点播体验包及云服务器等套餐
更多网易技术、产品、运营经验分享请点击。