1.NPMスクリプトを使用して開発コマンドを管理する
- 使用
NPM Scripts
されるコマンドの開発、設定するためにも、切り替えて、我々はスクリプトを変更してもそう、フィールドをコマンドを使用して、チームの残りのために他のパッケージ化ツールには同じまま、提案されたコマンドは、次のとおりです。package.json
scripts
Webpack
npm start
:同等でnpm run start
、ローカル開発サービスを迅速に開始するコマンドを開発するために使用されます。npm run build
:本番環境でのパッケージングに使用されます。npm run test/lint
関連するものに応じて、同様のその他のコマンドを追加できます。
package.json
使用cross-env
環境を区別するために、次の例を見て:
{
// ...
"scripts": {
"start": "cross-env NODE_ENV=development webpack --config webpack.config.dev.js --mode development",
"build": "cross-env NODE_ENV=production webpack --config webpack.config.prod.js --mode producation",
"analyzer": "cross-env NODE_ENV=production webpack --config webpack.config.analyzer.js --mode producation",
"lint": "lint-staged"
}
// ...
}
2つ目は、Webpackがマルチ環境構成を区別することです。
- 本番環境と開発環境の構成、および一般的なパッケージ構成を区別します。つまり
Webpack
、構成ファイルは次のように分割されます。
- 通用配置
webpack.config.base.js
; - 開発環境の構成
webpack.config.dev.js
; - 実稼働環境の構成
webpack.config.prod.js
;
- webpack.config.base.js
共通の構成をwebpack.config.base.js
一般的な構成のために、例えばentry、loader 和 plugin
のような、それだけにはいくつかの必要cross-env
渡すNODE_ENV
よう構成環境変数を行う:NODE_ENV=development
使用時間style-loader
、及びproduction
使用された場合mini-css-extract-plugin
にloader
、本番環境CSS
別個生成CSS
ファイル。
// webpack.config.base.js
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const isProduction = process.env.NODE_ENV === 'production';
module.exports = {
// ...
module: {
rules: [
{
test: /\.css?$/,
use: [
{
loader: isProduction ? MiniCssExtractPlugin.loader : 'style-loader'
},
{
loader: 'css-loader',
options: {
importLoaders: 1,
sourceMap: !isProduction
}
},
{
loader: 'postcss-loader',
options: {
sourceMap: !isProduction
}
}
]
}
]
}
// ...
};
-
webpack.config.dev.js
開発環境の設定をwebpack.config.dev.js
開発環境の設定、主のために主にdevServer
、API mock
効率に焦点を当てた構成の一部であり、他の関連する構成、速度最適化パッケージも非常に重要です。 -
webpack.config.prod.js
本番構成のwebpack.config.prod.js、ラインフォーカスのこの部分はsplitChunks
、リソース圧縮、CDN
パス構成(output
構成)を含む最適な構成パッケージ構成であり、他の構成も構成terser-webpack-plugin
の一部を強制的に削除する場合があります削除されたデバッグ情報を忘れてください:例えばdebugger、alert
。
sourcemap
オンライン環境のsourcemap
後Chrome
、ソースコード行を直接表示する他のツールを介して他のツールと同等になるため、本番環境でパッケージを生成してオンライン環境にアップロードしない場合は、パッケージの生成は推奨されないことに注意してください。これは非常に危険です。しかし、あなたは同様のプロジェクトが使用している場合Sentry
されJavaScript
収集と分析プラットフォームを与えられて、私たちがすることができsourcemap
て行くWebpack
、生成ライン上のパッケージにこれらのファイルを削除することを忘れないでください、対応するプラットフォームにアップロードした後、オンラインにアップロードを防止するために!
-
webpack.config.analyzer.js
これらの3つのプロファイルに加えて、コードパッケージの分析を支援するために、分割を行うのが妥当であるため、を追加できます。webpack.config.analyzer.js
この構成は実際に継承されwebpack.config.prod.js
、webpack-bundle-analyzer
プラグイン構成を追加します。 -
プロファイルを分割した後、
webpack-merge
管理構成ファイルの関係を使用
Webpack
します。それぞれの関係には、次のような依存関係があります。
webpack.config.dev.js
それらはマージされwebpack.config.base.js
、それらの構成。webpack.config.prod.js
合併webpack.config.base.js
とその構成;webpack.config.analyzer.js
合併webpack.config.prod.js
とその構成、およびwebpack.config.prod.js
からwebpack.config.base.js
です。
- この構成で関係を維持する場合は、
webpack-merge
このツールライブラリを使用して、webpack-merge
主に、関数の関数と同様に、2つの構成をマージするためのWebpack
構成オブジェクトMerge
関数を提供する必要Object.assign
があります。webpack.config.analyzer.js
見webpack-merge
使用方法:
const merge = require('webpack-merge');
const prodWebpackConfig = require('./webpack.config.prod.js');
const {
BundleAnalyzerPlugin} = require('webpack-bundle-analyzer');
module.exports = merge(prodWebpackConfig, {
// 增加 webpack-bundle-analyzer 配置
plugins: [new BundleAnalyzerPlugin()]
});
3.スプリットチャンクの合理的な使用
splitChunks
主にリソースの合理的な分割のサイズで使用する場合は、キャッシュヒット率を向上させ、それによって合理性の分割のロード時間を削減します。強度を把握するために注意を払う必要があります。薄すぎると利用できずHTTP Cache
、厚すぎるとリードします。この度の読み込みを遅くすることは一般的に定義されていませんが、一般的に言えば、コードは次の3つの原則に従って分割できます。
- 変更の頻度;
- ページ
Router
; - 動きと静的の分離。
-
分割に
使用splitChunks
する頻度に応じてコード変更の頻度を変更します。これらは、common
コードとしてまとめられた共通のフレームワークとライブラリを頻繁に変更することはなく、ビジネスコードはパブリック部分とプライベート部分に従ってページ間で分割されます。 -
ページルーター
が頻繁に変更しないフレームワークとライブラリコードを分割した後、残りはビジネスコードです。ビジネスコードは、異なるページ間の共通コードに従って分割できるため、フレームワークコードとライブラリコードは1つのページと組み合わせることができます。共通コードはブラウザにキャッシュされ、2番目のページにアクセスしても、フレームコードと共通コードページの要求は増加しません。 -
動的と静的の分離とは、頻繁に使用されない、または動的かつ非同期にロード(使用import()或者require.ensure())
する必要があるページ内のモジュールコードを個別に分割できることを意味chunks
します。これにより、ページの最初の画面の速度が保証されます。さらに同様のVue、React
アプリケーションである単一ページでは、ページRouter
コードが非同期に読み込まれ、ページ全体が現在のページの最初のエントリになり、大きなフレームで入力されたコードが読み込まれるため、ページクリックジャンプで必要な動的読み込みは2つだけです。Router
へのコード。
4、チャンクのハッシュ値を指定します
- 実稼働環境にパッケージ化されている構成ファイルは、次の推奨構成ルールである必要が
filename
あります。hash
hash
JavaScript
ファイルの使用法[chunkhash]
:;CSS
ファイルの使用法[contenthash]
:;- 使用されるその他の静的リソース:構成
[hash]
内url-loader
の画像、フォントなど。[hash]
文法レベルでの5つのベストプラクティス
-
ES6 Modules
そのTree-Shaking
作業を確実にするための文法の使用。 -
フェアユースは
Ployfill
、使用することをお勧めしますプログラムを。@babel/preset-env
useBuiltIns='usage'
-
Webpack
次の(magic comments)
ような魔法のコメントの合理的な使用:動的にロードされたモジュールの使用にwebpackChunkName
は名前が付けられていますwebpackPrefetch
。プリロードされる前に重要なリソースを使用することもできます。 -
フレームワークまたはクラスライブラリの適切なバージョンを使用します。次に例を示します。
Lodash
使用lodash-es
バージョンとモジュールによって使用されます。Momentjs
使用date-fns
の代わりに、モジュールが使用します。Zepto
インプレースを使用してページを移動するjQuery
;Vue、San、React
適切な種類のフレームワークライブラリを選択して、実際の状況をVue
構築します。たとえば、実際に構築するビルドには、ブラウザバージョン、ESM
バージョン、UMD
複数バージョン、フルバージョンなどが含まれます。
Webpack構成に関する6つのその他のベストプラクティス
mini-css-extract-plugin
エクスポートCSS
ドキュメントを使用した実稼働環境。- 本番環境の圧縮
JavaScript、CSS、图片、SVG
。 - 検索パスの合理的な割り当て、設定などの検索時間の短縮
alias
、プロジェクトのパスの追加、node_modules
検索する調査など。 - で
rule
設定があるtest、include、exclude
制御範囲、ベストプラクティスの三つの可能な設定:
test
正規表現を使用したファイル名の照合のみ。- 中
include
およびexclude
絶対パスアレイを使用して、 - それを避けて
exclude
、それを使用することを好むようにしてくださいinclude
。
icon
画像は、多くの使用をファイルCSS Sprite
の設定防ぐために、写真をマージするurl-loader
と、その結果、不合理の値を内のファイル仕方導入引き起こし、ファイル、ファイルが大きすぎます。svg-url-loader
limit
icon
Base64
CSS
CSS
7つ、その他のベストプラクティス
- 標準化された
Git
ワークフロー:
- 各送信が自動的にチェックを行う前に役立つライブラリ
Git Hook
のHusky
タイプと同様に、を使用します。Git Hook
(pre-commit)
lint
- 提出
Commitizen
を規制するために使用します;Git
Commit Log
-
コンポーネントベースの開発、公共
UI
アセンブリ、公共図書館の建物、除算に特定のプロジェクトのために、より抽象的、必要があるとここでは、例えば、我々は複数のページ共通することができUI
抽象化された部品、またと同様に、一般的なツールのライブラリを構築することができLodash
ていますクラスライブラリ -
便利な
CSS
前言語を選択してくださいSass、Less、Stylus
。チームだけが簡単に使用できます。 -
コード仕様、ディレクトリ構造、ドキュメント仕様などを含むルールと規則を指定します。
-
フロントエンドとリアエンドを分離し、適切な
Mock
プログラムを選択します。 -
標準プロジェクトのスキャフォールディングにベストプラクティスを作成し、スキャフォールディングツールを使用して新しいプロジェクトを作成します。
-
ベストプラクティスのツールチェーンの実行に
Webpack
基づいてWebpack
いても、構成に統合された抽象的なソリューション。