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。
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。