webpack 4を使って、アプレットの実現方法を開発します。

はい、私はREACT系の開発者です。仕事の中でwebpackを繰り返しています。VUEの開発思想と考え方を勉強するついでに、順調に章の招待状を作成します。前期にも各ウィジェット開発の枠組みを了解しましたが、基本的には転送の考え方で、ウィジェットとVUE/REACTのテンプレート、論理関係を解決し、議論を展開しませんでした。本人の立場から共有するだけで、webpackを通して、小さなプログラムの開発アーキテクチャを構築します。
小さいプログラムの既存のアーキテクチャを観察することによって、比較的に完璧なmvmアーキテクチャ（クラスVUE）であり、VUEとREACTのいくつかの特徴（VUEを中心として）を融合させたが、いくつかの欠点があり、先端開発者がよく使うnpmパッケージの導入、動的様式のコンパイルなど、開発効率を向上させる作業環境、モードが欠けていることが分かります。だからwebpack 4を通じて既存のアーキテクチャに有益な補足をすれば、元のアーキテクチャは完璧ではないかと思います。
考え方
ピアコンパイルは、ウィジェット項目のすべてのファイルを出力します。js/wxsはbabelコンパイルで出力し、wxml/jsonは直接出力し、wxssはstylasコンパイルで出力します。ついでに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をよく知っている学生は上のmoude配置を通じて、資源ファイルのコンパイルの構想を見抜くことができるはずです。もちろん、直接配置は正確なコンパイルができません。
ファイル
ピアツーピア出力のために、私たちはすべてのファイルをentryに整理してwebpackに処理する必要があります。このような利点はjsがnpmパッケージを使用することができ、すべてのファイルが熱更新機構をサポートできます。

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ファイル以外の出力
イベントの方法では、私たちはwxml、wxssなどのファイルをイベントとして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_u uイベントコードを生成する際には、jsファイルに加えられたprefixプレフィックスであり、プラグインの中でjsではないものを排除して、正常なjsファイルをchunkし直します。jsファイルは正常に出力できます。webpackはそれらをコンパイルして生成することはできません。途中でそれらはmoduleの中のx-loaderに処理されて、file-loaderに振られました。
グローバル変数の置換
グローバル変数をWeChatウィジェットの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,
 '
',
 '\/**auto import common&runtime js**\/',
 '
',
 contentObj,
);

上記のコードを通じて、各ファイルのソースコードを読み取り、グローバル変数window/globalをwxに置き換え、ソース再構築を行います。
実行時にファイルのインポート
私たちはruntime.jsとcommon.jsファイルを導入したいです。runtime実行環境はwebpackが各コンパイルファイルに挿入したdefine、require、moduleなどのファイルの紹介方法です。ファイルを簡単にするために、runtime.js、common.jsは私たちのために引き出した公共モジュールファイルです。web/h 5でこれらの資源を導入するのは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データサービスを提供してくれます。みんなは興味を持っています。また、バックグラウンドを訪問してくれます。
上記の操作によって、私たちはウィジェット構造のピア出力を得ることができます。残りは出力ファイルをウィジェットエディタに導入するだけで、次は開発作業です。うん、これで手続きにれんがを運んでくれます。楽しいですか？
コンパイルコードを参考にしたいなら、ここを見てもいいです。
もしあなたが私たちの仕組みを知りたいなら、ここを見てもいいです。  https://github.com/webkixi/aotoo-hub/blob/master/build/webpack.xcx.config.js
私たちのアーキテクチャを使いたいなら、怖くないですか？怖いなら、見てやってください。ハハ！ここを見ても大丈夫です。
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。