-
次のモジュールはどのような結果をエクスポートしますか?
exports.a = 'a'; module.exports.b = 'b'; this.c = 'c'; module.exports = { d: 'd' }
参考回答:
{ d: 'd' }
-
フロントエンドエンジニアリング、モジュール化、コンポーネント化についてのあなたの理解について教えてください。
参考回答:
このうちモジュール化は基礎であり、モジュール化がなければコンポーネント化もエンジニアリングもありません。
モジュール化の出現により、フロントエンドを悩ませている 2 つの大きな問題、地球規模の汚染と依存関係の混乱が解決され、フロントエンド プロジェクトを細かく分割できるようになりました。
エンジニアリングの出現により、フロントエンド開発環境と本番環境の矛盾した要件の間の矛盾が解決されました。開発環境では、コードの使用を可能な限り細分化し、コード形式を可能な限り統一および標準化することを望みますが、本番環境では、コードを可能な限り圧縮および難読化し、サイズを小さくすることを望みます。可能な限り最適化されています。この矛盾を解決するのがエンジニアリングの出現です。これにより、開発環境で快適にコードを記述し、それをパッケージ化して最適な運用環境のコードを生成できるようになります。これにより、開発者のエネルギーが解放され、開発者は開発環境に集中できるようになります。開発環境。
コンポーネント開発は、一部のフロントエンド フレームワークによってもたらされる概念です。これは、Web ページ、サイト、または完全な製品ラインを複数の小さなコンポーネントに分割します。コンポーネントは、その領域の特定の完全な機能を含む再利用可能なユニットです。このように、フロントエンドは複雑なアプリケーションを開発する機能を備えています。
-
webpackとgulpの違いは何ですか?
ライブ解説
参考回答:
webpack はモジュールベースのビルド ツールで、gulp はワークフロー ベースのビルド ツールです。
Webpack はパッケージャーであり、エントリを開始点として使用してプロジェクト全体の依存関係グラフを構築し、それをパッケージ化してマージしてパッケージ化結果を生成します。
Gulp はプロセス マネージャーです。各ステップが何を行うかは、開発者がどのように構成するかに完全に依存します。各ステップは接続されて完全なビルド パイプラインを形成します。
両者の間に矛盾はなく、webpack を gulp パイプラインのリンクとして使用することで、プロジェクト内で webpack と gulp を同時に使用できます。
-
Webpackのloader属性とplugins属性の違いは何ですか?
参考回答:
これらはすべて、Webpack 機能の拡張ポイントです。
ローダーはローダーであり、主にJSコードのダウングレード、CSSのプリコンパイル、モジュール化などのコード変換に使用されます。
プラグインはプラグインです。Webpack パッケージ化プロセスの各リンクはフック関数を提供します。これらのフック関数を使用して、パッケージ化ライフサイクルに参加し、ページや CSS ファイルの生成、パッケージ化結果の圧縮など、Webpack の特定の機能を変更または追加できます。 、など。
-
Webpack の中心となる概念は何ですか?
参考回答:
-
ローダ
ローダー。主に JS コードのダウングレード、CSS のプリコンパイル、モジュール化などのコード変換に使用されます。
-
プラグイン
プラグイン、Webpack パッケージ化プロセスの各リンクはフック関数を提供します。これらのフック関数を使用して、パッケージ化ライフサイクルに参加したり、ページや CSS ファイルの生成、パッケージ化結果の圧縮など、Webpack の特定の機能を変更または追加したりできます。 。
-
モジュール
モジュール。webpack は、js、css、html、画像など、すべての依存関係をモジュールとして扱います。それらはすべてモジュールです。
-
エントリ
入り口。パッケージ化プロセスの概念では、webpack は 1 つ以上のファイルをエントリ ポイントとして使用し、依存関係全体を分析します。
-
かたまり
パッケージ化プロセスの概念。チャンクは比較的独立したパッケージ化プロセスです。チャンクは 1 つ以上のファイルをエントリ ポイントとして使用し、依存関係全体を分析し、最終的にパッケージ化とマージを完了します。
-
バンドル
webpackのパッケージ化結果
-
木が揺れる
木の揺れの最適化。パッケージ化された結果から、未使用のコードを削除します。
-
HMR
ホットなアップデート。つまり、運用中にコードの変更が発生した場合、プロジェクト全体を再起動する必要はなく、コードの変更された部分のみが更新されます。
-
開発サーバー
開発サーバー。パッケージ化された結果へのアクセスをホストするために開発環境に構築された一時サーバー
-
-
commonjs モジュールと es6 モジュールの違いは何ですか?
参考回答:
- CMJ はコミュニティ標準であり、ESM は公式標準です
- CMJ は API を使用して実現されるモジュール性であり、ESM は新しい構文を使用して実現されるモジュール性です。
- CMJ はノード環境でのみサポートされ、ESM はすべての環境でサポートされます。
- CMJ は動的依存関係であり、ESM は動的依存関係と静的依存関係の両方をサポートします。
- ESM はインポート時にシンボル バインディングを持ちますが、CMJ は通常の関数呼び出しと代入です。
-
ES6 でモジュール型の非同期読み込みを実装するにはどうすればよいですか?
参考回答:
動的インポートを使用するだけです。インポート後、Promise を取得します。完了後、すべてのエクスポート結果を含むモジュール オブジェクトを取得します。
-
Webpack におけるいくつかのハッシュの実装原則は何ですか?
参考回答:
-
ハッシュ
ハッシュはプロジェクト全体の構築に関係しており、プロジェクト内でファイルに変更がある限り、プロジェクト構築全体のハッシュ値が変化し、すべてのファイルが同じハッシュ値を共有します。
-
チャンクハッシュ
各パッケージ化プロセスには個別のハッシュ値があり、プロジェクトに複数のエントリがある場合、各エントリは独自のチャンクハッシュを保持します。
-
コンテンツハッシュ
各ファイルのコンテンツには、パッケージ化結果ファイルのコンテンツに関連付けられた個別のハッシュ値があり、ファイルのコンテンツが変更されない限り、コンテンツ ハッシュも変更されません。
-
-
Webpack がハッシュ命名を使用する場合、ハッシュは毎回再生成されますか?
参考回答:
しません。関連付けられたコンテンツが変更されたかどうかに関係し、変更がない場合、ハッシュは変更されません。具体的には、contenthash は特定のパッケージング ファイルのコンテンツに関連付けられ、chunkhash は特定のエントリから始まるパッケージ化プロセスに含まれるコンテンツに関連付けられ、hash はプロジェクト全体のすべてのモジュールのコンテンツに関連付けられます。
-
Webpack では画像はどのように処理されますか? (抖音生放送)
参考回答:
Webpack 自体は画像を処理しません。画像コンテンツを JS コードとして解析します。その結果、エラーが発生し、パッケージ化が失敗します。画像を処理したい場合は、ローダーを介して画像を処理する必要があります。このうち、url-loader は画像を Base64 エンコードに変換してからデータ URL を取得し、file-loader は画像をパッケージング ディレクトリに生成してからリソース パスを取得します。しかし、どのタイプのローダーであっても、その中心的な機能は画像コンテンツを JS コードに変換することです。これは、画像コンテンツが JS コードに変換されて初めて webpack がそれを認識できるためです。
-
webpack でパッケージ化された HTML の先頭にスタイルが配置され、スクリプトが最後に配置されるのはなぜですか?
注: この質問の形式には問題があります。Webpack 自体は HTML をパッケージ化しません。逆に、HTML コードに遭遇すると、Webpack 自体は JS しか認識できないため、パッケージ化に直接失敗します。html ファイルをパッケージ化できるのはプラグインまたはローダーの役割によるもので、その中で最も一般的なプラグインは html-webpack-plugin です。したがって、この質問の正しい表現は次のようになります。「なぜ html-webpack-plugin によってパッケージ化された HTML の先頭にスタイルが配置され、スクリプトが下部に配置されるのですか?」
参考回答:
ブラウザは HTML を解析するときに上から下に解析し、スタイルと JS に遭遇すると HTML 解析を停止し、スタイルの解析と JS の実行に切り替えます。ページのちらつきを避けるために、ページのスタイル解析が完了した後に HTML を解析することをよく望みます。これに基づいて、スタイルを先頭に配置する必要があります。逆に、HTML を解析した後に JS を実行することを望みます。 , ユーザーができるだけ早くページにアクセスしてページを表示できるようにするとともに、実行時に JS が完全な DOM ツリーを取得できるようにするため、これに基づいて、JS コードを一番下に配置する必要があります。
ただし、HTML5 では async 属性と defer 属性が使用されます。これらの属性を使用すると、JS の問題をより適切に解決できます。スクリプトを先頭に置くと、ブラウザはできるだけ早くダウンロードできるようになりますが、実行は遅れます。実際、html-webpack-plugin の新しいバージョンでは、これはすでに行われています。
-
開発環境では CDN を使用せず、運用環境では CDN を使用するように webpack を構成するにはどうすればよいですか?
CDN を構成するには、次の 2 つの手順があります。
- cdn 参照を HTML テンプレートに直接追加する
- webpack 設定に、
externals
モジュールをパッケージ化せず、代わりにグローバル変数を使用するように webpack に指示する設定を追加します。
開発環境で CDN を使用したくない場合は、環境変数に基づいて異なる環境を判断し、異なるパッケージング プロセスを実行するだけで済みます。
- HTMLテンプレートでの判定にはejsテンプレート構文を使用し、本番環境のみにCDNを導入する
- Webpack 設定では、環境変数に基づいて設定
process.env
を使用するかどうかを決定できます。externals
package.json
スクリプト内にさまざまな環境変数を設定して、パッケージ化または開発の開始を完了します。
-
webpack4におけるツリーシェイキングのワークフローを紹介してください。
推奨読書: https://tsejx.github.io/webpack-guidebook/principle-analysis/operational-principle/tree-shaking
参考回答:
ツリーシェイキングは ESM の静的インポート構文のみをサポートしており、CMJ または ESM での動的インポートではツリーシェイキングはサポートされていません。
具体的なプロセスは主に、マーク付けと削除の 2 つのステップに分かれています。
-
マーク
Webpack が依存関係を分析するとき、コメントを使用してインポートとエクスポートをマークします。他のモジュールで使用されていないモジュール内のエクスポートは、未使用のハーモニー エクスポートとしてマークされます。
-
消去
次に、Uglifyjs (または他の同様のツール) ステップでコードの合理化を実行し、役に立たないとマークされたコードを削除します。
-
-
Webpack ローダーの役割を教えてください。
参考回答:
コードの変換に使用します。場合によっては、Webpack が画像や CSS などの特定のコンテンツを認識できないため、ローダーによって JS コードに変換する必要があることが原因です。場合によっては、一部のコードが JS 互換処理などの特別な処理を必要とし、ローダーによってさらに変換する必要があることが原因である場合があります。どのような状況であっても、ローダーの役割はコードを変換するという 1 つだけです。
-
開発プロセス中に既存のモジュールを拡張する必要がある場合、呼び出し元に影響を与えないように開発を実行するにはどうすればよいでしょうか?
参考回答:
実際、これはバージョン管理の問題です。
このモジュールのアップグレードで一部のバグが修正されるだけの場合は、メジャー バージョンとマイナー バージョン番号に影響を与えることなく、パッチ バージョンとしてアップグレードできます。
このモジュールのアップグレードによって新しいコンテンツが追加され、以前の API と完全な互換性がある場合は、マイナー バージョンとしてアップグレードできます。
このモジュールのアップグレードで以前の API が変更される場合、メジャー バージョンとしてアップグレードされます。
プロジェクトを開発するときは、プロジェクトをモジュールのメイン バージョンに依存させるため、モジュールが更新された場合、メイン バージョンが更新されない限り、プロジェクトはコードを変更せずにモジュールのバージョンを簡単にアップグレードできます。ただし、メジャー バージョンの更新が含まれる場合、プロジェクトはこのバージョンの更新を完全に無視し、コードを変更せずに古いバージョンを引き続き使用できます。もちろん、メイン バージョンもアップグレードできますが、コードの変更が含まれるため、アップグレードと同様です。 vue2.vue3 に移行すると、多くの変更が必要になります。
モジュールを開発するときは、最初に API を慎重に設計し、API インターフェイスが安定していることを確認し、メインのバージョン番号を頻繁に変更しないようにする必要があります。本当にメイン バージョンを更新したい場合は、2 つのバージョン (新しいメイン バージョン、古いメイン バージョン) を一定期間同時に維持し、他のプロジェクトがアップグレードするのに一定の時間を与える必要があります。
-
エクスポートとエクスポートのデフォルトの違いは何ですか?
参考回答:
エクスポートは通常のエクスポートであり、名前付きエクスポートとも呼ばれます。名前が示すように、変数定義や関数定義など、エクスポートするデータには名前を付ける必要があります。エクスポートされたモジュール オブジェクトでは、名前はモジュール オブジェクトの属性名になります。モジュール内には複数の名前付きエクスポートが存在する可能性があります
エクスポート デフォルトはデフォルトのエクスポートです。モジュール オブジェクト内の名前はデフォルトで固定されているため、名前を付ける必要はありません。通常は式またはリテラルをエクスポートします。モジュール内に存在できるデフォルトのエクスポートは 1 つだけです。
-
Webpack のパッケージ化原理は何ですか?
参考回答:
- 初期化パラメータ: 設定ファイルとシェルステートメントからパラメータを読み取ってマージし、最終パラメータを取得します。
- コンパイルの開始: 前の手順で取得したパラメーターを使用して Compiler オブジェクトを初期化し、構成されているすべてのプラグインをロードし、
run
オブジェクトのメソッドを実行してコンパイルを開始します。 - エントリの決定:設定に従って
entry
すべてのエントリ ファイルを検索します - モジュールのコンパイル: エントリ ファイルから開始して、
loader
モジュールを翻訳するように設定されているすべてのメソッドを呼び出し、翻訳されたコンテンツを AST に変換します。AST を分析して、モジュールが依存するモジュールを見つけて、すべてのエントリ ファイルが完成するまでこの手順を続けます。依存递归
ファイルはこの処理ステップの後にあります - モジュールのコンパイルを完了する: ステップ 4 を使用してすべてのモジュールを翻訳した後
loader
、各モジュールの最終的に翻訳されたコンテンツとモジュール間の関係が取得されます。依赖关系图
- 出力リソース: エントリとモジュール間の依存関係に従って、それらを複数のモジュールにアセンブルし
Chunk
、各チャンクを別個のファイルに変換して出力リストに追加します。このステップは、出力コンテンツを変更する最後の機会です。 - 出力完了: 出力内容決定後、設定に従って出力パスとファイル名を決定し、ファイル内容をファイルシステムに書き込みます
-
Webpack ホット アップデートの原理は何ですか?
参考回答:
ホット アップデートを有効にすると、WebSocket スクリプトがページに埋め込まれ、同時に開発サーバーもクライアントと WebSocket 通信を確立し、ソース コードが変更されると、Webpack は次の処理を実行します。
- webpackの再パッケージ化
- webpack-dev-server はモジュールの変更を検出し、webscoket を通じて変更が発生したことをクライアントに通知します。
- メッセージを受信したクライアントは、ajax経由で開発サーバーにリクエストを送信し、過去にパッケージ化したハッシュ値を含むjsonファイルをサーバーに要求します。
- サーバーは、どのモジュールが変更されたかをクライアントに通知し、また、このパッケージ化によって生成された新しいハッシュ値もクライアントに通知します。
- クライアントは再び過去のハッシュ値を使用して、変更されたモジュールを JSONP でリクエストします。
- サーバーはモジュールのコードを更新する関数呼び出しで応答します。
- この時点で、モジュール コードは更新されています。クライアントは、以前のリスニング構成に従って対応するモジュールが変更された後、コールバック関数を実行します。
-
Webpack のパッケージング速度を最適化するにはどうすればよいですか?
参考回答:
-
解析なし
多くのサードパーティ ライブラリ自体はすでにパッケージ化されたコードです。この種のコードは解析する必要はありません。noParse 構成を使用して、これらのサードパーティ ライブラリを除外できます。
-
外観
CDN はいくつかのよく知られたサードパーティ ライブラリに使用でき、これらのライブラリは外部経由でパッケージ化されないように構成できます。
-
ローダーのスコープを制限する
ローダーを使用する場合、exclude を使用して不要なコンパイルを除外できます。たとえば、babel-loader はパッケージ化されたサードパーティのライブラリをダウングレードする必要がなく、除外できます。
-
ローダーキャッシュを有効にする
キャッシュされたローダーのコンパイル結果を使用すると、
cache-loader
ソース コードが変更されていない場合にコンパイルが繰り返されることを避けることができます。 -
マルチスレッドコンパイルを有効にする
thread-loader
マルチスレッド コンパイルを使用すると、コンパイル効率を向上させることができます。 -
ダイナミックリンクライブラリ
パッケージ化が必要な一部のサードパーティ ライブラリについては、dll を使用して個別にパッケージ化すると、DLLPlugin によって現在のプロジェクトに統合されるため、開発中にこれらのライブラリを頻繁にパッケージ化する必要がなくなります。
-
-
Webpack は動的インポートをどのように実装しますか?
参考回答:
コード内で動的なインポート ステートメントが見つかると、webpack はインポートされたモジュールとその依存関係をパッケージ化用の別のチャンクに割り当て、別のパッケージ化結果を形成します。動的にインポートされたステートメントは通常の関数呼び出しにコンパイルされ、関数が実行されると、JSONP を使用して、分離されたパッケージがモジュール コレクションに動的にロードされます。
-
Webpack が持つファイルのフィンガープリントの種類について話しましょう。
参考回答:
-
ハッシュ
ハッシュはプロジェクト全体の構築に関係しており、プロジェクト内でファイルに変更がある限り、プロジェクト構築全体のハッシュ値が変化し、すべてのファイルが同じハッシュ値を共有します。
-
チャンクハッシュ
各パッケージ化プロセスには個別のハッシュ値があり、プロジェクトに複数のエントリがある場合、各エントリは独自のチャンクハッシュを保持します。
-
コンテンツハッシュ
各ファイルのコンテンツには、パッケージ化結果ファイルのコンテンツに関連付けられた個別のハッシュ値があり、ファイルのコンテンツが変更されない限り、コンテンツ ハッシュも変更されません。
-
-
一般的に使用される Webpack ローダーは何ですか?
参考回答:
- キャッシュローダー: コンパイルキャッシュを有効にする
- thread-loader: マルチスレッドコンパイルを有効にする
- css-loader: CSSコードをJSにコンパイルします
- file-loader: ファイルを出力ディレクトリに保存し、ファイルの内容をファイル パスに変換します。
- postcss-loader: postcss を使用して CSS コードをコンパイルする
- url-loader: ファイルの内容を dataurl に変換します。
- less-loader: 少ないコードを CSS コードに変換します。
- sass-loader: Sass コードを CSS コードに変換する
- vue-loader: 単一ファイルのコンポーネントをコンパイルする
- babel-loader: JS コードをダウングレードします。
-
Webpack で一般的に使用されるプラグインを教えてください。
参考回答:
- clean-webpack-plugin: 出力ディレクトリをクリアします
- copy-webpack-plugin: ファイルを出力ディレクトリにコピーします
- html-webpack-plugin: HTML ファイルを生成する
- mini-css-extract-plugin: CSS を別のファイルにパッケージ化するプラグイン
- HotModuleReplacementPlugin: ホット アップデート プラグイン
- purifycss-webpack: 無駄な CSS コードを削除する
- optimize-css-assets-webpack-plugin: CSS のパッケージ化ボリュームを最適化します。
- uglify-js-plugin: JS コードを圧縮して難読化する
- 圧縮-webpack-プラグイン: gzip圧縮
- webpack-bundle-analyzer: パッケージ化結果を分析する
-
babel-loader を使用する際の問題は何ですか?また、最適化するにはどうすればよいですか?
参考回答:
- 特別な処理が行われない場合、babel-loader は一致するすべてのモジュールをダウングレードしますが、互換性の問題に既に対処しているサードパーティ ライブラリにとっては不要であるため、除外設定を使用してこれらのサードパーティ ライブラリを除外できます。
- 古いバージョンの babel-loader では、デフォルトで ESM への変換が有効になっているため、webpack のツリーシェイクが無効になりますが、ツリーシェイクでは ESM 構文を保持する必要があるため、Webpack の ESM 変換をオフにする必要があります。 babel-loader. 新しいバージョンでは、デフォルトでオフになっています。
-
babel はどのようにクラスをコンパイルしますか?
参考回答:
基本的に、クラス構文は通常のコンストラクター定義に変換され、次の処理が行われます。
- これが何を指すのかの検出を追加しました
- プロトタイプおよび静的メソッドを列挙不可能にする
- コード全体を即時実行関数に入れ、実行後にコンストラクター自体を返します。
-
babel-polyfill の役割を説明してください。
例証します:
babel-polyfill はすでに非常に古いプロジェクトです。Babel はバージョン 7.4 からサポートしなくなり、代わりにより強力な core-js を使用します。この質問は、「core-js の役割は何か」を尋ねるのにも適しています。
参考回答:
デフォルトでは、babel 自体は新しい構文を変換するだけで、新しい API は処理しません。新しい API は古い環境ではサポートできないため (たとえば、IE6 はフェッチ API をサポートできない)、古い言語の機能を使用して新しい API を実装するパッチが必要です。これには babel-polyfill が使用されます。
-
less の & 演算子が何に使用されるのか説明してください。
参考回答:
アンパサンドの後の内容は親セレクターとマージされます。つまり、途中にスペース文字は追加されません。
-
フロントエンドエンジニアリングでは最適化のどのような側面を実行できますか?
参考回答:
-
伝送性能の最適化
-
圧縮と難読化
Uglifyjs または他の同様のツールを使用して、パッケージ化結果を圧縮および難読化すると、パッケージ サイズを効果的に削減できます。
-
木が揺れる
プロジェクトでは可能な限り ESM を使用してください。これにより、ツリー シェーキングの最適化が効果的に利用され、パッケージ サイズが削減されます。
-
共通モジュールの抽出
ブラウザのキャッシュを最大限に活用できるように、いくつかのパブリック コードを個別にパッケージ化します。他のコードを変更した後でも、パブリック コードは影響を受けず、ブラウザはキャッシュから直接パブリック コードを見つけることができます。
dll、splitChunks などの特定のメソッドが多数あります。
-
非同期読み込み
実行が遅れる可能性のある一部のモジュールについては、動的インポートを使用して非同期的にロードできるため、パッケージ化の結果では別のパッケージが形成されます。同時に、ページの更新時にロードする必要はありません。最初は解析されますが、ページ解析が完了した後、JS の実行中にそれらをロードします。
これにより、ページの応答性が大幅に向上し、単一ページのアプリケーションで特に役立ちます。
-
CDN
いくつかのよく知られたライブラリに CDN を使用すると、パッケージ化時間を節約できるだけでなく、ライブラリの読み込み速度も大幅に向上します。
-
gzip
現在、ブラウザは一般に gzip 形式をサポートしているため、静的ファイルは gzip を使用して圧縮できます。
-
環境適応
一部のパッケージ化結果には互換性コードが多く含まれていますが、これらのコードはブラウザの新しいバージョンでは意味がありません。したがって、ブラウザを複数のレベルに分割し、異なるレベルのブラウザに異なるパッケージング結果を与えることができます。
-
-
包装プロセスの最適化
-
解析なし
多くのサードパーティ ライブラリ自体はすでにパッケージ化されたコードです。この種のコードは解析する必要はありません。noParse 構成を使用して、これらのサードパーティ ライブラリを除外できます。
-
外観
CDN はいくつかのよく知られたサードパーティ ライブラリに使用でき、これらのライブラリは外部経由でパッケージ化されないように構成できます。
-
ローダーのスコープを制限する
ローダーを使用する場合、exclude を使用して不要なコンパイルを除外できます。たとえば、babel-loader はパッケージ化されたサードパーティのライブラリをダウングレードする必要がなく、除外できます。
-
ローダーキャッシュを有効にする
キャッシュされたローダーのコンパイル結果を使用すると、
cache-loader
ソース コードが変更されていない場合にコンパイルが繰り返されることを避けることができます。 -
マルチスレッドコンパイルを有効にする
thread-loader
マルチスレッド コンパイルを使用すると、コンパイル効率を向上させることができます。 -
ダイナミックリンクライブラリ
パッケージ化が必要な一部のサードパーティ ライブラリについては、dll を使用して個別にパッケージ化すると、DLLPlugin によって現在のプロジェクトに統合されるため、開発中にこれらのライブラリを頻繁にパッケージ化する必要がなくなります。
-
-
開発経験の最適化
-
糸くず
eslint や stylelint などのツールを使用して、チームのコード スタイルの一貫性を確保します。
-
HMR
ホットリプレースメントを使用して、ページの更新による状態損失を回避し、開発エクスペリエンスを向上させます。
-
-
-
プロジェクト パッケージが特に大きい場合、それを最適化するにはどうすればよいでしょうか?
参考回答:
-
CDN
プロジェクトでいくつかの既知のサードパーティ ライブラリが使用されている場合は、パッケージ化の代わりに CDN の使用を検討できます。
-
共通モジュールの抽出
プロジェクトでいくつかの大規模な公共ライブラリが使用されている場合は、それらを分割して個別にパッケージ化することを検討できます。
-
非同期読み込み
最初に実行する必要のないモジュールについては、動的インポートを使用して非同期にロードし、メイン パッケージのサイズを最小限に抑えることを検討できます。
-
圧縮、難読化
-
木が揺れる
インポートとエクスポートには ESM 構文を使用し、ツリー シェークを最大限に活用して無駄なコードを削除してください。
-
gzip
gzip 圧縮をオンにして、パッケージ サイズをさらに削減します。
-
環境適応
一部のパッケージ化結果には互換性コードが多く含まれていますが、これらのコードはブラウザの新しいバージョンでは意味がありません。したがって、ブラウザを複数のレベルに分割し、異なるレベルのブラウザに異なるパッケージング結果を与えることができます。
-
-
Webpack は最初の画面の読み込みをどのように最適化しますか?
参考回答:
-
CDN
プロジェクトでいくつかの既知のサードパーティ ライブラリが使用されている場合は、パッケージ化の代わりに CDN の使用を検討できます。
-
共通モジュールの抽出
プロジェクトでいくつかの大規模な公共ライブラリが使用されている場合は、それらを分割して個別にパッケージ化することを検討できます。
-
非同期読み込み
最初に実行する必要のないモジュールについては、動的インポートを使用して非同期にロードし、メイン パッケージのサイズを最小限に抑えることを検討できます。
-
圧縮、難読化
-
木が揺れる
インポートとエクスポートには ESM 構文を使用し、ツリー シェークを最大限に活用して無駄なコードを削除してください。
-
gzip
gzip 圧縮をオンにして、パッケージ サイズをさらに削減します。
-
環境適応
一部のパッケージ化結果には互換性コードが多く含まれていますが、これらのコードはブラウザの新しいバージョンでは意味がありません。したがって、ブラウザを複数のレベルに分割し、異なるレベルのブラウザに異なるパッケージング結果を与えることができます。
-
-
Webpack スコープホイスティングを導入しますか?
参考回答:
スコープホイスティングは、Webpack の組み込みの最適化であり、モジュールの最適化であり、運用環境でパッケージ化するときに自動的にオンになります。
スコープホイスティングが有効になっていない場合、webpack は各モジュールのコードを独立した関数環境に配置し、モジュールのスコープが相互に干渉しないようにします。
スコープホイスティングの役割はまったく逆で、複数のモジュールのコードを実行用の関数環境にマージすることです。このプロセス中に、webpack はモジュール コードを正しい順序でマージし、名前の重複を避けるために関連する識別子を適切に処理します。
これの利点は、関数呼び出しが減り、動作効率が向上し、パッケージング量も削減されることです。
ただし、スコープホイスティングを有効にするための前提条件があり、一部のモジュールが他のモジュールによって複数回参照されている場合、動的にインポートされたモジュールが使用されている場合、または非 ESM モジュールが使用されている場合、スコープホイスティングは発生しません。
-
Webpack プロキシはどのように機能しますか? なぜクロスドメインの問題を解決できるのでしょうか?
例証します:
厳密に言えば、webpack は単なるパッケージング ツールであり、プロキシの機能はもちろん、サーバーの機能もありません。webpack でプロキシ設定を使用できる理由は、そのプラグインの 1 つである webpack-dev-server の機能のためです。
したがって、「webpack-dev-server はどのように機能しますか? なぜクロスドメインの問題を解決できるのですか?」という質問をする必要があります。
参考回答:
まず、プロキシ設定は開発環境用であり、本番環境では意味がありません。
webpack-dev-server を通じて開発サーバーを起動すると、開発サーバーにアクセスすることですべてのパッケージ化リソースを取得できます。
同時にプロキシを設定し、開発サーバーに特定のアドレスを要求すると、開発サーバーはそれをターゲットアドレスにプロキシします。したがって、プロキシ アドレスに対する後続のリクエストは、開発サーバーにリクエストを送信するように変更できます。
このように、静的ページをリクエストするドメインとプロキシ アドレスをリクエストするドメインは同じソースを持ち、両方とも開発サーバーをリクエストするため、クロスドメインの問題は発生しません。
-
このコンポーネント ライブラリに依存するすべてのプロジェクトは、コンポーネントのリリース時にアップグレードする必要がありますか?
参考回答:
実際、これはバージョン管理の問題です。
このモジュールのアップグレードで一部のバグが修正されるだけの場合は、メジャー バージョンとマイナー バージョン番号に影響を与えることなく、パッチ バージョンとしてアップグレードできます。
このモジュールのアップグレードによって新しいコンテンツが追加され、以前の API と完全な互換性がある場合は、マイナー バージョンとしてアップグレードできます。
このモジュールのアップグレードで以前の API が変更される場合、メジャー バージョンとしてアップグレードされます。
プロジェクトを開発するときは、プロジェクトをモジュールのメイン バージョンに依存させるため、モジュールが更新された場合、メイン バージョンが更新されない限り、プロジェクトはコードを変更せずにモジュールのバージョンを簡単にアップグレードできます。ただし、メジャー バージョンの更新が含まれる場合、プロジェクトはこのバージョンの更新を完全に無視し、コードを変更せずに古いバージョンを引き続き使用できます。もちろん、メイン バージョンもアップグレードできますが、コードの変更が含まれるため、アップグレードと同様です。 vue2.vue3 に移行すると、多くの変更が必要になります。
モジュールを開発するときは、最初に API を慎重に設計し、API インターフェイスが安定していることを確認し、メインのバージョン番号を頻繁に変更しないようにする必要があります。本当にメイン バージョンを更新したい場合は、2 つのバージョン (新しいメイン バージョン、古いメイン バージョン) を一定期間同時に維持し、他のプロジェクトがアップグレードするのに一定の時間を与える必要があります。
-
開発プロセス中にパブリックコンポーネントを設計するにはどうすればよいですか? (バイトダンス)
参考回答:
-
使用シナリオの決定
このパブリック コンポーネントの必要性がどのようにして生じるのか、現在の使用シナリオは何か、将来的にどのような使用シナリオが発生する可能性があるのかを明確にします。
使用シナリオを明確にすることは非常に重要であり、これにより、このコンポーネントの使用境界がどこにあるのか、どの程度まで汎用性があるのかが決まり、このコンポーネントの開発の難易度が決まります。
-
デザインコンポーネントの機能
コンポーネントの使用シナリオに基づいて、コンポーネントのプロパティ、イベント、および使用方法のドキュメントを設計します。
-
テストケース
使用法ドキュメントに従ってコンポーネントのテスト ケースを作成します。
-
完全な開発
使用説明書とテストケースに従って開発を完了
-
-
プロジェクト (ByteDance) でどのような Webpack 最適化が行われたかを教えてください
参考回答:
-
伝送性能の最適化
-
圧縮と難読化
Uglifyjs または他の同様のツールを使用して、パッケージ化結果を圧縮および難読化すると、パッケージ サイズを効果的に削減できます。
-
木が揺れる
プロジェクトでは可能な限り ESM を使用してください。これにより、ツリー シェーキングの最適化が効果的に利用され、パッケージ サイズが削減されます。
-
共通モジュールの抽出
ブラウザのキャッシュを最大限に活用できるように、いくつかのパブリック コードを個別にパッケージ化します。他のコードを変更した後でも、パブリック コードは影響を受けず、ブラウザはキャッシュから直接パブリック コードを見つけることができます。
dll、splitChunks などの特定のメソッドが多数あります。
-
非同期読み込み
実行が遅れる可能性のある一部のモジュールについては、動的インポートを使用して非同期的にロードできるため、パッケージ化の結果では別のパッケージが形成されます。同時に、ページの更新時にロードする必要はありません。最初は解析されますが、ページ解析が完了した後、JS の実行中にそれらをロードします。
これにより、ページの応答性が大幅に向上し、単一ページのアプリケーションで特に役立ちます。
-
CDN
いくつかのよく知られたライブラリに CDN を使用すると、パッケージ化時間を節約できるだけでなく、ライブラリの読み込み速度も大幅に向上します。
-
gzip
現在、ブラウザは一般に gzip 形式をサポートしているため、静的ファイルは gzip を使用して圧縮できます。
-
環境適応
一部のパッケージ化結果には互換性コードが多く含まれていますが、これらのコードはブラウザの新しいバージョンでは意味がありません。したがって、ブラウザを複数のレベルに分割し、異なるレベルのブラウザに異なるパッケージング結果を与えることができます。
-
-
包装プロセスの最適化
-
解析なし
多くのサードパーティ ライブラリ自体はすでにパッケージ化されたコードです。この種のコードは解析する必要はありません。noParse 構成を使用して、これらのサードパーティ ライブラリを除外できます。
-
外観
CDN はいくつかのよく知られたサードパーティ ライブラリに使用でき、これらのライブラリは外部経由でパッケージ化されないように構成できます。
-
ローダーのスコープを制限する
ローダーを使用する場合、exclude を使用して不要なコンパイルを除外できます。たとえば、babel-loader はパッケージ化されたサードパーティのライブラリをダウングレードする必要がなく、除外できます。
-
ローダーキャッシュを有効にする
キャッシュされたローダーのコンパイル結果を使用すると、
cache-loader
ソース コードが変更されていない場合にコンパイルが繰り返されることを避けることができます。 -
マルチスレッドコンパイルを有効にする
thread-loader
マルチスレッド コンパイルを使用すると、コンパイル効率を向上させることができます。 -
ダイナミックリンクライブラリ
パッケージ化が必要な一部のサードパーティ ライブラリについては、dll を使用して個別にパッケージ化すると、DLLPlugin によって現在のプロジェクトに統合されるため、開発中にこれらのライブラリを頻繁にパッケージ化する必要がなくなります。
-
-
開発経験の最適化
-
糸くず
eslint や stylelint などのツールを使用して、チームのコード スタイルの一貫性を確保します。
-
HMR
ホットリプレースメントを使用して、ページの更新による状態損失を回避し、開発エクスペリエンスを向上させます。
-
-
-
では、splithunkspluginの利用シーンと利用方法について詳しくお話しましょう。(バイトダンス)
参考回答:
-
パブリックモジュール
たとえば、一部のマルチページ アプリケーションには複数のエントリが含まれるため、複数のチャンクが形成され、これらのチャンクでいくつかの共通モジュールが使用されます。パッケージ全体のサイズを削減するために、splithunksplugin を使用して共通モジュールを分離できます。
MinChunks は、下請けのために参照されるチャンクの数を指定するように構成できます。
-
並列ダウンロード
HTML5 は遅延と非同期をサポートしているため、複数の JS ファイルを同時にダウンロードして帯域幅を最大限に活用できます。パッケージ化結果が大きなファイルになる場合、これを利用することはできません。
Splithunks プラグインを使用してファイルを分割し、分割するパッケージのサイズを指定するように maxSize 属性を構成できます。
-
-
Webpack のビルド プロセスについて説明してください。(CVTE)
参考回答:
- 初期化パラメータ: 設定ファイルとシェルステートメントからパラメータを読み取ってマージし、最終パラメータを取得します。
- コンパイルの開始: 前の手順で取得したパラメーターを使用して Compiler オブジェクトを初期化し、構成されているすべてのプラグインをロードし、
run
オブジェクトのメソッドを実行してコンパイルを開始します。 - エントリの決定:設定に従って
entry
すべてのエントリ ファイルを検索します - モジュールのコンパイル: エントリ ファイルから開始して、
loader
モジュールを翻訳するように設定されているすべてのメソッドを呼び出し、翻訳されたコンテンツを AST に変換します。AST を分析して、モジュールが依存するモジュールを見つけて、すべてのエントリ ファイルが完成するまでこの手順を続けます。依存递归
ファイルはこの処理ステップの後にあります - モジュールのコンパイルを完了する: ステップ 4 を使用してすべてのモジュールを翻訳した後
loader
、各モジュールの最終的に翻訳されたコンテンツとモジュール間の関係が取得されます。依赖关系图
- 出力リソース: エントリとモジュール間の依存関係に従って、それらを複数のモジュールにアセンブルし
Chunk
、各チャンクを別個のファイルに変換して出力リストに追加します。このステップは、出力コンテンツを変更する最後の機会です。 - 出力完了: 出力内容決定後、設定に従って出力パスとファイル名を決定し、ファイル内容をファイルシステムに書き込みます
-
Webpackプラグインの実装原理を説明してください。(CVTE)
参考回答:
基本的に、Webpack プラグインは
apply
関数を備えたオブジェクトです。webpack はコンパイラ オブジェクトを作成した後、登録されたプラグインの apply 関数を実行し、コンパイラ オブジェクトをパラメータとして渡します。apply 関数では、開発者はコンパイラ オブジェクトを通じて複数のフック関数の実行を監視できます。異なるフック関数は、Webpack コンパイルの異なる段階に対応します。Webpack が特定の段階に達すると、これらのリスニング関数が呼び出され、コンパイル オブジェクトが渡されます。開発者はコンパイル オブジェクトを使用して Webpack に関するさまざまな情報を取得および変更し、それによってビルド プロセスに影響を与えることができます。
-
プロジェクト分析にプラグインを使用したことがありますか? (CVTE)
参考回答:
webpack-bundle-analyzer を使用してパッケージング結果を分析し、主にプロジェクトのパッケージング量を最適化するために使用しました
-
babel とは何ですか?またその機能は何ですか?
参考回答:
babel は JS コンパイラーであり、主に次世代の JS 言語コードをより互換性のあるコードにコンパイルするために使用されます。
実際には、それ自体ではあまり機能せず、JS コードを AST にコンパイルし、エコシステム内のさまざまなプラグインに依存して AST の構文と API を処理します。
-
npmモジュールのインストールメカニズムとは何ですか?
参考回答:
- npm は、モジュールがローカルの node_modules ディレクトリにインストールされているかどうかを確認し、すでにインストールされている場合は再インストールしません。
- npm は、キャッシュ内に同じモジュールがあるかどうかを確認し、存在する場合は、キャッシュからインストールを直接読み取ります。
- ローカルまたはキャッシュに存在しない場合、npm はレジストリで指定されたアドレスからインストール パッケージをダウンロードし、それをローカルの node_modules ディレクトリに書き込み、同時にキャッシュします。
フロントエンドエンジニアリングの面接での質問
おすすめ
転載: blog.csdn.net/qq_53461589/article/details/133025203
おすすめ
ランキング