1. 后编译介绍
目前大部分的前端项目开发都是使用es6+的代码并且使用babel进行编译，而传统的对代码包的引入都是引入一个被babel编译好的文件入口，这样带来了一个缺点，那就是项目中无用的代码也会被引入到最终打包的文件中。
后编译的思想是不会在包发布的时候进行编译，而是会在使用这个包的前端项目构建的时候进行编译。
下面就来看一下cube-ui对更好的使用后编译作出的探索。
2. 后编译遇到的问题
2.1 后编译和普通编译的兼容
由于webpack的开发团队也考虑到直接引入一个编译好的代码包带来的一些问题，所以在webpack2.x之后引入了一个属性。
module.exports = {
// ...
resolve: {
mainFields: ["browser", "module", "main"]
}
// ...
}
在引入一个第三方包的时候，会根据mainFields的队列头到队列尾的顺序检测package.json文件中是否有这些字段值。
上面的示例代码是target值为webworker时的默认配置，当target为其他值时，mainFields的默认值为：
mainFields: ["module", "main"]
在使用cube-ui时我们如何配置使用后编译或者时普通编译呢？
后编译时直接引入代码包时就会默认引入ES2015 module的代码，对于普通编译需要在webpack.base.conf.js中配置别名解析。
module.exports = {
// ...
resolve: {
alias: {
// ...
"cube-ui": "cube-ui/lib"
}
}
// ...
}
这样在引入时就可以引入到编译后的代码。
2.2 引入路径
在做到上面的几步后，就可以实现代码包的后编译，但是这里有一个引入路径的问题。比如我们要引入cube-ui的switch组件，我们需要这样引入：
import Switch from 'cube-ui/src/modules/switch'
这样的引入方式对于用户来说肯定不是很友好。
通过cube-ui团队开发的webpack插件webpack-transform-modules-plugin可以通过下面的方式进行组件的引入。
import {Switch} from 'cube-ui'
在引入这个插件的同时需要在package.json中引入下面的代码：
{
// ...
"transformModules": {
"cube-ui": {
"transform": "cube-ui/src/modules/${member}",
"kebabCase": true
}
},
// ...
}
通过这段配置来解析cube-ui的引入路径。
同时还要在webpack.base.conf.js中添加webpack-transform-modules-plugin插件。
var PostCompilePlugin = require('webpack-post-compile-plugin')
var TransformModulesPlugin = require('webpack-transform-modules-plugin')
module.exports = {
// ...
plugins: [
// ...
new PostCompilePlugin(),
new TransformModulesPlugin()
]
// ...
}
2.3 嵌套后编译
如果我们要使用后编译还要在webpack配置的rules中加入include配置，比如要后编译代码包A和B，就要写下面的代码：
module.exports = {
// ...
module: {
rules: [
// ...
{
test: /\.js$/,
loader: 'babel-loader',
// 注意这里的 include
// 除了 src 还包含了额外的 node_modules 下的两个包
include: [
resolve('src'),
resolve('node_modules/A'),
resolve('node_modules/B')
]
},
// ...
]
},
// ...
}
如果在后编译的生态中，会出现下面的情况：
cube-ui嵌套编译
这里借用cube-ui团队的一张嵌套后编译的图。
当A为后编译，A依赖的包C和D也为后编译时，需要在应用的webpack配置中增加rules.include的配置：
module.exports = {
// ...
module: {
rules: [
// ...
{
test: /\.js$/,
loader: 'babel-loader',
// 注意这里的 include
// 除了 src 还包含了额外的 node_modules 下的两个包
include: [
resolve('src'),
resolve('node_modules/A'),
resolve('node_modules/B'),
resolve('node_modules/C'),
resolve('node_modules/D')
]
},
// ...
]
},
// ...
}
cube-ui团队为了解决这种情况开发了webpack插件webpack-post-compile-plugin，通过这个插件可以通过获取package.json文件中的compileDependencies属性来获取当前包依赖的后编译包，并且将这些包添加到webpack配置的rules.include中。
webpack-post-compile-plugin插件的核心代码如下：
PostCompilePlugin.prototype.apply = function (compiler) {
var that = this
compiler.plugin(['before-run', 'watch-run'], function (compiler, callback) {
// ...
var dependencies = that._collectCompileDependencies(compiler)
if (dependencies.length) {
var rules = compiler.options.module.rules
rules && rules.forEach(function (rule) {
if (rule.include) {
if (!Array.isArray(rule.include)) {
rule.include = [rule.include]
}
rule.include = rule.include.concat(dependencies)
}
})
}
callback()
})
}
就是在webpack编译过程中的before-run和watch-run的两个钩子中进行依赖的收集。
3. 使用后编译的其他问题
由于cube-ui使用的是stylus进行样式的编写，如果采用后编译需要在前端工程中配置stylus的解析。
在vue-loader的配置中添加下面的配置。
const stylusOptions = {
'resolve url': true
}
return {
css: generateLoaders(),
postcss: generateLoaders(),
less: generateLoaders('less'),
sass: generateLoaders('sass', { indentedSyntax: true }),
scss: generateLoaders('sass'),
stylus: generateLoaders('stylus',stylusOptions),
styl: generateLoaders('stylus',stylusOptions)
}
总结
后编译的优点是能对依赖包中的代码进行依赖分析，从而让公共的依赖被提取出来。由于后编译是在前端应用构建时一起构建，所以babel转换的API只有一份，不会冗余。
缺点是包的babel配置要与应用的babel配置兼容，依赖包不能使用alias和DefinePlugin。编译时间会变长。
后编译是一种生态，如果你编写的代码包需要使用后编译，那么就要遵守后编译的配置规定。
网友评论