Echarts Taro WeChatアプレット開発におけるピット記録

背景
最近筆者はTaroを使ってマイクロクレジットのプログラムを開発しています。Echartsのグラフライブラリを導入する時、マイクロクレジットのテスト用のカバンが2 Mを超える一連の最適化措置の踏んだ記録があります。読者の回り道を少なくするよう指導してほしいです。
なぜEchartsを選んだのですか？
微信小プログラムのカタログ市場で一番多く使われているグラフライブラリは次の通りです。

echarts-for-weixin――echartWeChatウィジェットバージョン

wx-charts――ウィーチャットウィジェットに基づくグラフライブラリ

二つのグラフバンクの長所と短所を対照すると、ちょうど反対です。

echarts-for-weixin：機能は強大ですが、体積は非常に大きいです。

wx-charts：機能は比較的簡単ですが、体積は

です。
私はechartsの使用に慣れています。そして、グラフに必要な機能の一部はwx-chartsではサポートされていません。だから、最終的にecharts-for-weixinを使って、ピットを踏む旅が始まります。
シングルパックが2 Mを超えたら、どう処理しますか？
私はecharts-for-weixinを導入して、楽しい仕上げの需要、アップロードコードを準備してマイクロクレジットの体験版を発表します。ピットはここから始まります。

シングルパックが2 M上限を超えると、アップロードコードに異常が発生し、上のポップアップメッセージが表示されます。
WeChatアプレットの公式要求は、1パックで2 Mを超えず、全体で16 Mを超えない。
パッケージが2 Mを超える場合、最適化案は次の2つがあります。

マイクロパケットにsubpackage

をロードする。

パッケージ体積最適化（コード削減、圧縮、静的リソースCDNなど）

今回の開発の需要は新機能に属しているので、新機能モジュールを独立した分包ルートでロードします。しかし、分包した後、単包が2 Mを超える制限があります。

分析を通して、業務モジュールから引用されたechartsコンポーネントは、Taroによってcomon.jsモジュールに包装され、すべてのパケット分けモジュールがechartsのsizeを繰り返し計算することになり、旧パケットモジュールが2 Mの制限を超えることになる。
どうしてecharts-for-weixinはcomon.jsモジュールに包装されますか？
echartsはecharts-for-weixinコンポーネントと外部業務コンポーネントに依存されていて、Taroはecharts.jsが複数のモジュールに依存されていると考えて、comon.jsに包装されたからです。
この問題を解決するために、スプリットChunksパッケージ構成を採用し、echarts単独モジュールを包装し、対応する依存ページ（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]);
  }
 }

Taroはmini.webpackCharinを通じてwebpackの設定をカスタマイズします。公式サイト文書を参照してください。
webpackパッケージにスプリットChunksを配置します。公式サイト文書を参照してください。
mini.addChunkPagesによるパケット分割依存度設定は、公式サイト文書を参照してください。
以上の処理を経て、common.jsの体積は正常に回復しました。これで終わりだと思います。
その結果、新たなピットが現れました。

echarts-for-weixinコンポーネントが見つけられません。echartsモジュール依存…
一連の分析を経て、Taroが元のWeChunksパッケージに対する依存注入に問題があることがわかった。
Taroコンパイルが成功したら、手動でコンパイルしたC-canvas.jsを修正して、echarts依存を注入する必要があります。

上の処理を経て、やっと正常に運行しました。シングルパックが2 Mを超える問題も全部解決しました。
これで終わりだと思いますか？
毎回コンパイルした後、手動でコンパイルしたファイルを修正することはできないでしょう。もしいつバージョンを出しても手動で修正しないと、オンライン上の問題が発生し、リスクが高いです。
したがって、Taroパッケージのhackプラグインを書く必要があります。自動的にコンパイル後のechats依存コードを注入します。
Taroコンパイルプラグインを書くのは簡単です。政府はまだこの問題を修復していません。を参照してください。プラグインコードは以下の通りです。

const fs = require('fs');
const path = require('path');
module.exports.default = module.exports = (ctx, options) => {
 ctx.onBuildFinish(() => {
  console.log('echarts  hack  ')
  const target = path.join(ctx.paths.outputPath, 'subpackages/homeworkPage/studyData/ChartLine/ec-canvas//ec-canvas.js');
  const data = fs.readFileSync(target, 'utf8');
  fs.writeFileSync(target, `require("../../echartCommon");${data}`)
 })
}

注：Taroバージョン2.2以上がカスタムプラグインに対応しています。
最後に
EchartsはTaro WeChatのプログラム開発において、ピット記録をここで終了します。Taro WeChatのプログラムでechartsのグラフライブラリを使用しようとしている読者のためにいくつかの助けを与えたいです。
ここでEchartsのTaro WeChatアプリケーション開発におけるステップ記録に関する記事を紹介します。Taro WeChatプログラムEchartsの内容については以前の記事を検索してください。または下記の関連記事を引き続きご覧ください。これからもよろしくお願いします。