哈，本人是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的熱更新響應非?？欤琯ulp的熱更新很難精細控制，當項目足夠大的時候，響應很慢)
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，我們通過插件解決
const globalVar = 'wx'.........let contentObj = compilation.assets[file]let code = contentObj.source()code = code.replace(windowRegExp, that.globalVar);contentObj = new RawSource(code)compilation.assets[file] = new ConcatSource( contentSource, '/n', '//**auto import common&runtime js**//', '/n', contentObj,);
通過上述代碼不難看出，我們讀取了每個文件的源碼，并將全局變量window/global替換為wx，再進行源碼重組。
運行時文件引入
我們需要引入runtime.js和common.js文件，runtime運行環境是webpack為每個編譯文件插入的用于解析define, require, module等等這些的文件引入方法，為了精簡文件，我們將之抽離為runtime.js，common.js為我們抽離出來的公共模塊文件。在web/h5下引入這些資源是不是so easy，但你還記得我們是在小程序環境下嘛，并不能通過<script>標簽來引入資源文件啊啊啊，你會不會猛拍腦門，一下就慌了(哈哈)。老辦法，我們通過插件解決
const lens = []let posixPath = ''const matchIt = chunk.name.match(////g)if (matchIt) { matchIt.forEach(it => lens.push(this.prePath)) // posixPath = './'+lens.join('') posixPath = lens.join('')} else { posixPath = './'}let posixPathFile = posixPath + 'runtime.js'let contentSource = this.contentSource.replace('~~~~', posixPathFile)if (chunk.name.indexOf('runtime') > -1) { posixPathFile = posixPath + 'common.js' if (hasCommon) { contentSource = this.contentSource.replace('~~~~', posixPathFile) } else { contentSource = '' }}上述代碼片段中，posixPath是我們通過一個小的算法來推算資源引入的路徑深度變量，輸出并重寫源文件chunk，這樣我們就解決了資源引入的問題
webpack-dev-server
引入webpack-dev-server能夠使得webpack的編譯能夠簡單的輸出到硬盤上，webpack默認是內存文件系統，并不輸出(當然有其他方法，比如再寫個插件或更換文件系統啥的)，除了文件輸出，webpack-dev-server還能夠為我們提供mock數據服務，呵呵~，這里不展開了，大家有興趣百度一下，還能夠為我們訪問后臺接口作proxy，這里也不展開了。
通過上述操作，我們就能得到小程序結構的對等輸出，剩下我們只需要將輸出文件導入到小程序編輯器中，接下來就是開發工作了。嗯，這樣就可以開始給小程序搬磚了，開心嗎？
如果你想參考一下我們的編譯代碼，可以看這里 https://github.com/webkixi/aotoo-hub/blob/master/build/webpack.xcx.config.js
如果你想了解下我們的架構，可以看這里 https://github.com/webkixi/aotoo-hub
如果你想使用我們的架構，怕不怕？怕的話，你看著辦吧，哈哈! 不怕看這里 https://www.npmjs.com/package/aotoo-cli
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持武林網。
新聞熱點
疑難解答
