微信小程序目錄市面上使用最多的兩款圖表庫，如下：

• echarts-for-weixin——echarts微信小程序版本
• wx-charts——基于微信小程序的圖表庫

對比兩款圖表庫優(yōu)缺點剛好相反。

• echarts-for-weixin：功能強大，但體積非常大
• wx-charts：功能相對簡單，但體積小

由于筆者對echarts使用較熟悉，且需求圖表需要支持的部分功能wx-charts不支持，所以最終選擇使用echarts-for-weixin，踩坑之旅就此開始。

筆者引入echarts-for-weixin，快樂的做完需求，準備上傳代碼發(fā)布微信小程序體驗版，坑就此開始...

當單包超過2M上限，則上傳代碼出現(xiàn)異常，出現(xiàn)上面彈窗提示。

微信小程序官方要求，單包不超過2M，整包不超過16M

遇到單包超過2M，優(yōu)化方案有如下兩種：

• 微信分包加載subpackages
• 單包體積優(yōu)化（縮減代碼、壓縮、靜態(tài)資源CDN等等）

由于筆者本次開發(fā)需求屬于新功能，所以把新功能模塊采用獨立的分包路由加載，但分包后，還是出現(xiàn)單包超過2M的限制。

經(jīng)過分析發(fā)現(xiàn)業(yè)務(wù)模塊引用的echarts組件，會被Taro打包到common.js模塊，導(dǎo)致所有的分包模塊都會重復(fù)計算echarts的size，導(dǎo)致舊分包模塊超過2M的限制。

為什么echarts-for-weixin會被打包到common.js模塊？

原因是echarts被echarts-for-weixin組件和外部業(yè)務(wù)組件所依賴，導(dǎo)致Taro認為echarts.js被多個模塊所依賴，所以打包到common.js。

為了解決此問題，采用splitChunks打包配置，將echarts單獨模塊打包，然后在對應(yīng)的依賴頁面（addChunkPages）注入依賴，配置如下：

// echartChunkName echarts打包后的輸出路徑
  mini: {
    webpackChain(chain) {
      chain.merge({
        optimization: {
          splitChunks: {
            cacheGroups: {
              [echartChunkName]: {
                name: echartChunkName,
                priority: 50,
                test(module) {
                  return /subpackages[\\/]homeworkPage[\\/]studyData[\\/]ChartLine[\\/]ec-canvas[\\/]echarts.js/.test(
                    module.resource
                  );
                },
              },
            },
          },
        },
      });
    },
    addChunkPages(pages, pagesNames) {
      pages.set("subpackages/homeworkPage/studyData/ChartLine/index", [echartChunkName]);
      pages.set("subpackages/homeworkPage/studyData/ChartLine/ec-canvas/ec-canvas", [echartChunkName]);
    }
  }
復(fù)制代碼

Taro通過mini.webpackChain自定義webpack配置

webpack分包配置splitChunks

通過mini.addChunkPages設(shè)置分包依賴

經(jīng)過以上處理，common.js體積恢復(fù)正常，以為就此結(jié)束。

結(jié)果新的坑又出現(xiàn)了......如下圖:

echarts-for-weixin組件找不到echarts模塊依賴...

經(jīng)過一系列的分析，發(fā)現(xiàn)Taro對原生微信組件splitChunks分包打包的依賴注入有問題官方還沒有修復(fù)此問題...

需要在Taro編譯成功后，手動修改編譯后的ec-canvas.js，注入echarts依賴，如下圖：

經(jīng)過上面的處理，終于正常運行，單包超過2M的問題也全部解決。

以為到此就結(jié)束了？

筆者總不能在每次編譯后，手動修改編譯后的文件吧，如果哪天發(fā)版本忘記手動修改，將導(dǎo)致線上問題，風(fēng)險高。

因此需要寫一個Taro打包hack插件，自動注入編譯后的echarts依賴代碼。

書寫Taro編譯插件很簡單，請參考官方文檔即可，插件代碼如下：

const fs = require('fs');
const path = require('path');
module.exports.default = module.exports = (ctx, options) => {
  ctx.onBuildFinish(() => {
    console.log('echarts構(gòu)建hack注入')
    const target = path.join(ctx.paths.outputPath, 'subpackages/homeworkPage/studyData/ChartLine/ec-canvas//ec-canvas.js');
    const data = http://www.wxapp-union.com/fs.readFileSync(target,'utf8');
    fs.writeFileSync(target, `require("../../echartCommon");${data}`)
  })
}
復(fù)制代碼

注：Taro版本2.2以上才支持自定義插件

最后

Echarts在Taro微信小程序開發(fā)踩坑記錄到此接近尾聲，希望能給正準備在Taro微信小程序使用echarts圖表庫的讀者一些幫助。