chunk
由多个 模块
组合而成。可以将可执行的模块和他所依赖的模块组合成一个 chunk ,这就是打包。一个单页应用需要配置一个entry指明执行入口,web-webpack-plugin里的WebPlugin可以自动的完成这些工作:webpack会为entry生成一个包含这个入口的所有依赖文件的chunk,但是还需要一个html来加载chunk生成的js,如果还提取出css需要HTML文件中引入提取的css。
一个简单的webpack配置文件例子:
const { WebPlugin } = require('web-webpack-plugin');
module.exports = {
entry: {
app: './src/doc/index.js',
home: './src/doc/home.js'
},
plugins: [
// 一个WebPlugin对应生成一个html文件
new WebPlugin({
//输出的html文件名称
filename: 'index.html',
//这个html依赖的`entry`
requires: ['app','home'],
}),
],
};
说明:require: ['app', 'home']指明这个html依赖哪些entry,entry生成的js和css会自动注入到html中。
还支持配置这些资源注入方式,支持如下属性:
这些属性可以通过在js里配置,看个简单例子:
new WebPlugin({
filename: 'index.html',
requires: {
app:{
_dist:true,
_inline:false,
}
},
}),
这些属性还可以在模板中设置,使用模板好处就是可以灵活的控制资源的注入点
new WebPlugin({
filename: 'index.html',
template: './template.html',
}),
<!DOCTYPE html>
<html lang="zh-cn">
<head>
<link rel="stylesheet" href="app?_inline">
<script src="ie-polyfill?_ie"></script>
</head>
<body>
<div id="react-body"></div>
<script src="app"></script>
</body>
</html>
WebPlugin插件借鉴了fis3的思想,补足了webpack缺失的以HTML为入口的功能。想了解WebPlugin的更多功能,见文档。
一个项目中会包含多个单页应用,虽然多个单页面应用可以合成一个,但是这样做会导致用户没有访问的部分也加载了,如果项目中有很多的单页应用。为每一个单页应用配置一个entry和WebPlugin?如果又新增,又要新增webpack配置,这样做麻烦,这时候有一个插件web-webpack-plugin里的AutoWebPlugin方法可以解决这些问题。
module.exports = {
plugins: [
// 所有页面的入口目录
new AutoWebPlugin('./src/'),
]
};
分析:
AutoWebPlugin
会把./src/目录下所有每个文件夹作为一个单页页面的入口,自动为所有的页面入口配置一个 WebPlugin
输出对应的html。./src/
下新建一个文件夹包含这个单页应用所依赖的代码,AutoWebPlugin
自动生成一个名叫文件夹名称的html文件。一个好的代码分割对浏览器首屏效果提升很大。
最常见的react体系:
// vender.js 文件抽离基础库到单独的一个文件里防止跟随业务代码被刷新
// 所有页面都依赖的第三方库
// react基础
import 'react';
import 'react-dom';
import 'react-redux';
// redux基础
import 'redux';
import 'redux-thunk';
// webpack配置
{
entry: {
vendor: './path/to/vendor.js',
},
}
服务端渲染的代码要运行在nodejs环境,和浏览器不同的是,服务端渲染代码需要采用commonjs规范同时不应该包含除js之外的文件比如css。
webpack配置如下:
module.exports = {
target: 'node',
entry: {
'server_render': './src/server_render',
},
output: {
filename: './dist/server/[name].js',
libraryTarget: 'commonjs2',
},
module: {
rules: [
{
test: /\.js$/,
loader: 'babel-loader',
},
{
test: /\.(scss|css|pdf)$/,
loader: 'ignore-loader',
},
]
},
};
分析一下:
target: 'node'
指明构建出代码要运行在node环境中。libraryTarget: 'commonjs2'
指明输出的代码要是 commonjs 规范。{test: /\.(scss|css|pdf)$/,loader: 'ignore-loader'}
是为了防止不能在node里执行服务端渲染也用不上的文件被打包进去。fis3和webpack有很多相似地方也有不同的地方,相似地方:都采用commonjs规范,不同地方:导入css这些非js资源的方式。
fis3通过@require './index.scss',而webpack是通过require('./index.scss')。
如果想把fis3平滑迁移到webpack,可以使用comment-require-loader。
比如:你想在webpack构建是使用采用了fis3方式的imui模块
loaders:[{
test: /\.js$/,
loaders: ['comment-require-loader'],
include: [path.resolve(__dirname, 'node_modules/imui'),]
}]
如果你在社区找不到你的应用场景的解决方案,那就需要自己动手了写loader或者plugin了。
在你编写自定义webpack扩展前你需要想明白到底是要做一个loader还是plugin呢?可以这样判断:
如果你的扩展是想对一个个单独的文件进行转换那么就编写loader剩下的都是plugin。
其中对文件进行转换可以是像:
编写loader非常简单,以comment-require-loader为例:
module.exports = function (content) {
return replace(content);
};
loader的入口需要导出一个函数,这个函数要干的事情就是转换一个文件的内容。
函数接收的参数content是一个文件在转换前的字符串形式内容,需要返回一个新的字符串形式内容作为转换后的结果,所有通过模块化倒入的文件都会经过loader。从这里可以看出loader只能处理一个个单独的文件而不能处理代码块。可以参考官方文档。
plugin应用场景广泛,所以稍微复杂点。以end-webpack-plugin为例:
class EndWebpackPlugin {
constructor(doneCallback, failCallback) {
this.doneCallback = doneCallback;
this.failCallback = failCallback;
}
apply(compiler) {
// 监听webpack生命周期里的事件,做相应的处理
compiler.plugin('done', (stats) => {
this.doneCallback(stats);
});
compiler.plugin('failed', (err) => {
this.failCallback(err);
});
}
}
module.exports = EndWebpackPlugin;
loader的入口需要导出一个class,在new EndWebpackPlugin()的时候通过构造函数传入这个插件需要的参数,在webpack启动的时候会先实例化plugin,再调用plugin的apply方法,插件在apply函数里监听webpack生命周期里的事件,做相应的处理。
webpack plugin的两个核心概念:
Compiler 和 Compilation 都会广播一系列事件。webpack生命周期里有非常多的事件。
以上只是一个最简单的demo,更复杂的可以查看 how to write a plugin或参考web-webpack-plugin。