Webpack サーバー側コードのパッケージ化例の詳細な説明

環境変数

以前は、プロジェクト内で process.env.NODE_ENV を使用することがよくありましたが、この変数は Webpack のパッケージ化に影響を及ぼし、運用中に最適化される この記事では主に Webpack サーバー側について編集者が考えています。コードパッケージ化のサンプルコードが非常に優れているので、参考として共有します。編集者をフォローして見てみましょう。皆さんのお役に立てれば幸いです。

他の環境変数を使用して区別します:

new webpack.DefinePlugin({
 'process.env.NODE_ENV': '"production"',
 'process.env.API_ENV': `"${process.env.API_ENV || 'development'}"`
})

このように、NODE_ENV は常に本番環境です。

実際の開発/本番環境では、使用する process.env.API_ENV 変数を使用します (このプロジェクトのためは koa インターフェイス サービス プロジェクトなので、このように名前を付ければ、満足する限り任意に変更できます)。

動的構成とパッケージ化

注

以前は動的に構成していましたNode.js バックエンド プロジェクト 設定の読み込みは通常次のように記述されます:

const ENV = process.env.NODE_ENV || 'development';
// eslint-disable-next-line import/no-dynamic-require
const options = require(`./_${ENV}`);

module.exports = options;

可読性を向上させ、ENV を再利用できるようにするために、変数を個別に定義します。

これを webpack パッケージ化されたプロジェクトで直接実行する場合たとえば、次のような複数の構成があります。現在の環境に渡すと、すべての設定ファイルはパッケージ化されます (ただし、実行されることはありません)。この場合、機密情報が漏洩する危険性があります。

正しい姿勢は次のようになります:

• config/index .js

• // eslint-disable-next-line import/no-dynamic-require
  const options = require(`./_${process.env.API_ENV || 'development'}`);
  
  module.exports = options;

  モジュラーパッケージング

• たとえば、負荷分散のニーズや顧客がカスタマイズしたモジュラー製品の場合、プロジェクト内に多くのモジュールがある場合、それらを module にパッケージ化する必要があります。他のモジュール (決して実行されない) が webpack バンドルにパッケージ化されるのを防ぐため。

// config/_development.js
exports.enabledModules = ['user', 'demo']; 
// 可能 src 目录下 还有其他模块目录, 如 'manage' 等

サーバーにロードすると、次のようになります:

// src/server.js
// 动态加载启用的模块
enabledModules.forEach((mod) => {
 /* eslint-disable global-require,import/no-dynamic-require */
 const routes = require(`./${mod}/route`);
 routes.middleware() |> app.use;
});

その場合、ContextReplacementPlugin プラグインが必要です

コードは次のとおりです:

new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(${enabledModules.join('|')})/.*$`))

高度な使用法

たとえば、srcディレクトリには、各モジュールのディレクトリに加えて、いくつかの一般的なメソッドクラスとフックディレクトリもあります。例: lib とフック。これらの 2 つのディレクトリは、他のサブモジュールによって共同参照される可能性があります。プラグイン正規表現内の

コードを次のように変更します。コードを圧縮し、source-map を追加します。サポート

Uglifyjs または Uglify-es は、実際にはサーバー側のコード パッケージ化用です。これはフレンドリーではなく、パッケージングの失敗を引き起こす可能性があります。代わりに、babel-minify-webpack-plugin プラグインを使用してください。 - ソース コードの問題の場所をサポートするプラグイン

サンプル プロジェクトのソース コード: https://github .com/AirDwing/webpack-server-bundle

関連する推奨事項:

PHP の単純なシステム クエリ モジュール コード。パッケージのダウンロード_PHP チュートリアル

以上がWebpack サーバー側コードのパッケージ化例の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。