ホームページ > 記事 > ウェブフロントエンド > 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 パッケージ化されたプロジェクトで直接実行する場合たとえば、次のような複数の構成があります。現在の環境に渡すと、すべての設定ファイルはパッケージ化されます (ただし、実行されることはありません)。この場合、機密情報が漏洩する危険性があります。
// eslint-disable-next-line import/no-dynamic-require const options = require(`./_${process.env.API_ENV || 'development'}`); module.exports = options;モジュラーパッケージング
// 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; });
コードは次のとおりです:
new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(${enabledModules.join('|')})/.*$`))
高度な使用法
たとえば、srcディレクトリには、各モジュールのディレクトリに加えて、いくつかの一般的なメソッドクラスとフックディレクトリもあります。例: lib とフック。これらの 2 つのディレクトリは、他のサブモジュールによって共同参照される可能性があります。プラグイン正規表現内の
コードを次のように変更します。コードを圧縮し、source-map を追加します。サポート
サンプル プロジェクトのソース コード: https://github .com/AirDwing/webpack-server-bundle
PHP の単純なシステム クエリ モジュール コード。パッケージのダウンロード_PHP チュートリアル
以上がWebpack サーバー側コードのパッケージ化例の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。