用戶
 找回密碼
 立即注冊

QQ登錄

只需一步,快速開始

掃一掃,登錄網站

小程序社區 首頁 資訊/觀點 查看內容

2010湖人vs凯尔特人:用webpack4開發小程序

湖人vs爵士季后赛 www.nbgeh.club Rolan 2019-6-4 00:22

哈,本人是REACT系開發者,工作中需要不停的折騰webpack,為了順帶學習VUE的開發思想和思路,順理成章的請纓為公司小程序打個框架基礎。前期也去了解了下各個小程序開發框架,大體上是通過轉義的思路來解決小程序和V ...

哈,本人是REACT系開發者,工作中需要不停的折騰webpack,為了順帶學習VUE的開發思想和思路,順理成章的請纓為公司湖人vs爵士季后赛打個框架基礎。前期也去了解了下各個小程序開發框架,大體上是通過轉義的思路來解決小程序和VUE/REACT的模板、邏輯關系,不做展開討論了。只是從本人角度分享通過webpack來構建小程序的開發架構。

通過觀察小程序的原有架構,不難發現其已經是一套比較完善的mvvm架構了(類VUE),融合了VUE及REACT的一些特點(以VUE為主),但卻有一些不足,缺失了前端開發人員常用的npm包的引入,動態樣式的編譯等等提升開發效率的工作環境、模式。因此我想如果通過webpack4來為原有架構做一個有益的補充,這樣原生架構不就很完美了嗎?

思路

對等編譯輸出小程序項目的所有文件(嚴格按照小程序需要的文件及目錄結構輸出)。js/wxs通過babel編譯輸出,wxml/json直接輸出,wxss通過stylus編譯輸出(我們使用stylus開發樣式),順帶使用webpack抽離公共??槲募?nbsp;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 ,我們通過插件解決

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,這里也不展開了。

通過上述操作,我們就能得到小程序結構的對等輸出,剩下我們只需要將輸出文件導入到小程序編輯器中,接下來就是開發工作了。嗯,這樣就可以開始給小程序搬磚了,開心嗎?

如果你想參考一下我們的編譯代碼,可以看這里 github.com/webkixi/aot…

如果你想了解下我們的架構,可以看這里 github.com/webkixi/aot…

如果你想使用我們的架構,怕不怕?怕的話,你看著辦吧,哈哈! 不怕看這里 www.npmjs.com/package/aot…

如果你還想看看我們的小程序,看這里 developers.weixin.qq.com/community/d…

分享至 : QQ空間
收藏
原作者: 天天修改 來自: 掘金