哈，本人是REACT系开发者，工作中需要不停的折腾webpack，为了顺带学习VUE的开发思想和思路，顺理成章的请缨为公司小程序打个框架基础。前期也去了解了下各个小程序开发框架，大体上是通过转义的思路来解决小程序和VUE/REACT的模板、逻辑关系，不做展开讨论了。只是从本人角度分享通过webpack来构建小程序的开发架构。
通过观察小程序的原有架构，不难发现其已经是一套比较完善的mvvm架构了(类VUE)，融合了VUE及REACT的一些特点(以VUE为主)，但却有一些不足，缺失了前端开发人员常用的npm包的引入，动态样式的编译等等提升开发效率的工作环境、模式。因此我想如果通过webpack4来为原有架构做一个有益的补充，这样原生架构不就很完美了吗？
思路
对等编译输出小程序项目的所有文件(严格按照小程序需要的文件及目录结构输出)。js/wxs通过babel编译输出，wxml/json直接输出，wxss通过stylus编译输出(我们使用stylus开发样式)，顺带使用webpack抽离公共模块文件common.js，并将runtime运行时抽离作为一个独立文件。这样既精简了代码，又享用到了webpack为我们带来的好处。嗯，看上去很简单嘛，实际上却是踩了不少的坑！脚上的茧老厚了~~~
webpack module配置
module: { rules: [ { test: /\.(wxml|axml)/, // 为支付宝小程序留了个伏笔，哈哈 use: [ relativeFileLoader(isWechat ? 'wxml' : 'axml'), // 这里使用file-loader简单封装了一下 'extract-loader', 'html-loader' ] }, { test: /\.(jp(e?)g|png|gif)$/, use: relativeFileLoader() }, { test: /\.wxss$/, include: SRC, use: relativeFileLoader(), }, { test: /\.wxs$/, include: SRC, exclude: /node_modules/, use: [ relativeFileLoader(), { loader: 'babel-loader', options: { babelrc: false, presets: [ 'es2015', 'stage-0' ] }, } ] }, { test: /\.js$/, use: { loader: 'happypack/loader', options: { id: 'babel' } }, exclude: /node_modules/, }, { test: /\.styl$/, include: SRC, use: [ relativeFileLoader(isWechat ? 'wxss' : 'acss'), 'stylus-loader' ] } ] },
熟悉webpack的同学通过上面的moudle配置应该能够看出资源文件编译的思路，当然直接这样配置肯定做不到正确编译，还有一些坑需要踩
全文件entry
为了对等输出，我们需要把所有文件整理为entry给webpack处理，这样的好处是js能够使用npm包，所有文件都能够支持热更新机制(webpack的热更新响应非常快，gulp的热更新很难精细控制，当项目足够大的时候，响应很慢)
function entries(dir) { var jsFiles = {} let _partten = /[\/|\\][_](\w)+/; let re_common = /(.*)\/common\// const accessExts = ['.wxml', '.wxss', '.styl', '.wxs', '.json', '.png', '.jpg', '.jpeg', '.gif'] if (fse.existsSync(dir)) { globby.sync([`${dir}/**/*`, `!${dir}/js/**/cloudfunctions`, '!node_modules', `!${dir}/dist`]).forEach(function (item) { if (!re_common.test(item)) { if (!_partten.test(item)) { const fileObj = path.parse(item) const xcxSrc = path.join(dir, 'js') if (~item.indexOf(xcxSrc)) { const fileStat = fs.statSync(item) const relativeFile = item.replace(xcxSrc, '') let relativeKey = relativeFile.replace(fileObj.ext, '').substring(1) if (fileObj.ext == '.js') { jsFiles[relativeKey] = item } else { if (accessExts.indexOf(fileObj.ext) > -1) { jsFiles['nobuild__' + relativeFile] = item } } } } } }) } return jsFiles }
上述是entry的生成代码，涵盖了小程序目录结构下的所有需要的文件，并加上了一些特定的标识，以便于后续文件编译输出
非JS文件的输出
在entry方法中我们将wxml，wxss等文件作为entry统统灌给webpack去处理，正常我们使用webpack时是不会把非js文件作为entry输给webpack的。你猜webpack会报错吗，----- 哈哈，报错就讲不下去了，webpack会傻傻的把每个entry文件都当做js来对待，并且正常输出，*.wxml.js，等等，这是什么鬼，我并不需要这样的东东。加个插件来处理一下
compiler.hooks.compilation.tap('wpConcatFile', (compilation, params) => { compilation.hooks.beforeChunkAssets.tap('wpConcatFile', () => { compilation.chunks = compilation.chunks.filter(function (item) { return item.name.indexOf('nobuild__') == -1 }) }) ... ... }
nobuild__是在生成entry代码是给非js文件加上的prefix前缀，在插件中我们排除掉非js，将正常的js文件重新chunk，js文件就能够正常的输出了，那么那些非js文件呢？webpack并不会编译生成它们，中途它们就会被module中的xx-loader处理完,然后被file-loader给甩出去了。
全局变量替换
将全局变量替换为微信小程序的wx，我们通过插件解决