記事ディレクトリ

ウェブパックウォッチ
webpack-dev-server
Webpack 設定: devServer
ホットモジュール交換 (HMR)
- フレームワーク HMR
- HMRの原理
プロキシー
- 基本的な使い方
履歴Apiフォールバック

この事前の Webpack 構成は不可欠です。ただし、開発エクスペリエンスは良好ではなく、手動でパッケージ化するには npm run build が必要でした。

ファイルが変更されたときに、コンパイルと表示が自動的に完了することを期待しています。
自動コンパイルを完了するために、webpack にはいくつかのオプションのメソッドが用意されています。

webpack監視モード；
webpack-dev-server (一般的に使用されます);
webpack-dev-ミドルウェア；

ウェブパックウォッチ

webpack は監視モードを提供します。
このモードでは、webpack 依存関係グラフ内のすべてのファイルは、そのうちの 1 つが更新されている限り、コードが再コンパイルされます。npm
run build コマンドを手動で実行する必要はありません。
注: 自動的にコンパイルおよびパッケージ化されるだけなので、ブラウザでリアルタイムに表示するには、ライブサーバーと連携して HTML を開く必要があります。

時計の電源を入れるにはどうすればよいですか? ふたつのやり方：

方法 1: エクスポートされた構成ファイルに、つまり webpack.config.js を追加します。watch: true;
方法 2: Webpack を開始するコマンドに--watchロゴを追加します。

スクリプト内のスクリプトは実際に npm run を使用して、コマンドラインで次のコマンドを実行できるようにするため、npm スクリプトにフラグを追加できます。同じことがここの webpack にも当てはまります。コマンドラインでの実行は基本的に webpack-cli に依存します (--watch 属性の設定も cli によって設定ファイルに追加されます)。

{
    
    
  "scripts": {
    
    
    "build": "webpack --watch"
  },
}

webpack-dev-server

live-server を使用せずにライブリロード (リアルタイムリロード) を実装したい場合は、webpack-dev-server を使用できます。
Express サーバーが起動するため、ブラウザが開くと、一般的な Web サイトを開くのと同じように、まずindex.html がダウンロードされ、次にindex.html から他のファイルがダウンロードされます。

実際、webpack-dev-server はコンパイル後に出力ファイルを書き込みません。代わりにバンドルファイルをメモリ内に保持します

インストール：npm i webpack-dev-server -D

使用方法:webpack serve起動するだけです。通常は npm スクリプトでも使用します。paste
"serve": "webpack serve --config webpack.config.js"
&height=142&id=u3e7b03df&name=image.png&originHeight=222&originWidth=1055&originalType=binary&ratio=1&rotation=0&showTitle=false&size=42403&status=error&style=none&taskId=ud0771a41-16ac -4 b79- bfad-aaff037763f&title=&width=675.2)

webpack-dev-server サービスがファイルを検索するパスは次のとおりです。

http://[devServer.host]:[devServer.port]/[output.publicPath]/[output.filename]

output: {
    
    
  filename: "js/bundle.js",
  path: path.resolve(__dirname, "./dist"),
  publicPath: "hhh"
}

デフォルトのホストとポートは localhost:8080 です。出力が上記のように設定されている場合、JS をリクエストするための URL は次のようになります。

http://127.0.0.1:8080/hhh/js/bundle.js

Webpack 設定: devServer

ローカル開発サーバーを構成したい場合は、devServerwepback 構成オブジェクトの最上位オプションで構成できます。もちろん、それらの多くはデフォルトですでに構成されています。

さらに、パッケージ製品の使用環境を識別するための最上位のオプションターゲットを追加できます。target: "web"|"node"

静的

devServer では多くのプロパティを構成できますが、contentBase もその 1 つです。
contentBase: webpack によってパッケージ化されていないファイルがどのディレクトリにあるかを開発サーバーがブラウザーに通知し、ブラウザーがパッケージ化されたパッケージにファイルをダウンロードする代わりに、そのディレクトリに直接アクセスしてファイルを取得できるようにすることを示します。
たとえば、favourite.ico では、運用環境はパッケージ化されたフォルダーにコピーする必要がありますが、開発段階はコピーする必要がないため、ブラウザがアイコンをロードしやすくするために、contentBase として ./public を指定できます。
一部の追加ファイルは非常に大きいため、パッケージ化する必要がなく、開発とパッケージ化の効率が向上します。
ただし、廃止されました。
画像.png
devServer によって構成できるすべてのオプションはプロンプト情報にマークされており、もちろん多くのオプションにはデフォルト構成があります。

static上記の contentBase と同じ効果を実現したい場合は、オプションを使用して静的ファイルディレクトリを指定する必要があります。ディレクトリ内のファイルは、パッケージ化されたエクスポートディレクトリに追加されるのと同じです。

module.exports = {
    
    
  devServer: {
    
    
    static: "./img"
  }
}

<img src="./1.png" alt="">

ブラウザを開いて表示すると、画像 1.png がローカルの img フォルダーにリンクされており、パッケージ化されていないことがわかります。
画像.png

ホスト

host はホストアドレスを設定します。

デフォルト値はローカルホストです。
他の場所からアクセスできるようにしたい場合は、0.0.0.0 に設定できます。

localhost と 0.0.0.0 の違い:

localhost: 基本的にはドメイン名で、通常は 127.0.0.1 に解決されます。
127.0.0.1: ループバックアドレス (ループバックアドレス)。これは、ホストによって送信されたパケットが自分自身によって直接受信されることを意味します。

通常のデータベースパケットの送信パスは、アプリケーション層 - トランスポート層 - ネットワーク層 - データリンク層 - 物理層ですが、ループバックアドレスはネットワーク層
で直接取得され、データリンク層と物理層には届きません。
他の人が同じネットワークセグメント内のホストでローカルサーバーを起動した場合、127.0.0.1 を介して他の人のサーバーにアクセスすることはできません。リクエストはネットワークカードによってまったく送信されないため、127.0.0.1 がローカルホストと呼ばれるのはこのためです。

0.0.0.0: IPV4 上のすべてのアドレスをリッスンし、ポートに応じてさまざまなアプリケーションを見つけます。
たとえば、同じネットワークセグメント内のホストで 0.0.0.0 のサービスを開いた場合、他のユーザーは 0.0 を介してサーバーにアクセスできます。 .0.0 。これはブロードキャストアドレスであるため、リクエストはネットワークセグメント内のすべてのホストに送信されます。

ポート、オープン、圧縮

port: リスニングポートを設定します。デフォルトは 8080
open: ブラウザを開くかどうか:

デフォルト値は false で、true に設定するとブラウザが開きます。
Google Chrome と同様の値に設定することもできます。

compress 静的ファイルの gzip 圧縮を有効にするかどうか:

注: 一部のポートはブラウザのブラックリストに含まれています (例: 6666)。これらのポートは設定できません。

ホットモジュール交換 (HMR)

HMRとは何ですか?

HMR の正式名は Hot Module Replacement で、モジュールの活性交換と訳されます。
モジュールのホットリプレースとは、アプリケーションの実行中に、ページ全体を更新せずにモジュールを置換、追加、削除することを指します。

HMR は、次の方法により開発速度を向上させます。

ページ全体をリロードしないでください。これにより、アプリケーションの一部の状態が失われるのを防ぐことができます。
変更が必要なコンテンツのみを更新して、開発時間を節約します。
CSS と JS のソースコードを変更すると、ブラウザ内ですぐに更新されます。これは、ブラウザの開発ツールでスタイルを直接変更するのと同じです。

HMRの使い方は？
デフォルトでは、webpack-dev-server はすでに HMR をサポートしており、デフォルトでオンになっています。HMR**devServer: { hot: true }**
がオンになっていない場合、ソースコードを変更すると、; を使用してページ全体が自動的に更新されますlive reloading。

画像.png
WDS ：webpack開発サーバー

しかし、特定のモジュールのコードを変更すると、ページ全体が依然として更新されることがわかります。
これは、HMR を実行するためにどのモジュールを更新するかを指定する必要があるためです。

if (module.hot) {
    
    
  module.hot.accept("./js/element.js", () => {
    
    
    console.log("element模块发生更新了");
  })
}

フレームワーク HMR

質問があります: 他のプロジェクトを開発するとき、多くの場合、module.hot.accpet 関連の API を手動で記述する必要がありますか?
たとえば、Vue および React プロジェクトの開発において、コンポーネントを変更し、ホットアップデートを実行したいと考えていますが、このときどのように操作すればよいでしょうか?

実際、コミュニティにはこれらに対する非常に成熟したソリューションがすでにあります:
たとえば、vue 開発では、vue コンポーネントの HMR をサポートし、すぐに使用できるエクスペリエンスを提供する vue-loader を使用します
。開発には React Hot Loader があり、リアルタイムで反応コンポーネントを調整します (現在、React は正式に非推奨になっており、代わりに React-refresh を使用してください)

HMRの原理

では、HMR の原理は何でしょうか? 1 つのモジュール内のコンテンツのみを更新するにはどうすればよいでしょうか?

webpack-dev-server は、静的リソースを提供するサービス (express) とソケットサービス (net.Socket) の 2 つのサービスを作成します。
Express サーバーは、静的リソースサービスを直接提供する役割を果たします (パッケージ化されたリソースはブラウザによって直接要求され、解析されます)。

HMR ソケットサーバーは長いソケット接続です。

長い接続の最大の利点の 1 つは、接続の確立後に 2 者が通信できることです (サーバーはクライアントにファイルを直接送信できます)。
サーバーが対応するモジュールの変更を検出すると、.json (マニフェストファイル) と .js ファイル (更新チャンク) の 2 つのファイルが生成されます。
長い接続を通じて、これら 2 つのファイルをクライアント (ブラウザ) に直接送信できます。
ブラウザは 2 つの新しいファイルを取得した後、HMR ランタイムメカニズムを通じて 2 つのファイルをロードし、変更されたモジュールを更新します。

プロキシー

プロキシは開発において非常に一般的な構成オプションであり、その目的は、クロスドメインアクセスの問題を解決するためにプロキシを設定することです。

たとえば、API リクエストの 1 つは http://192.163.0.66/12345 ですが、ローカル起動サーバーのドメイン名は http://localhost:8080 です。このとき、ネットワークリクエストを送信すると、クロスドメインの問題が発生します。 ;
次に、最初にプロキシサーバーにリクエストを送信します。プロキシサーバーと API サーバーにはクロスドメインの問題がないため、クロスドメインの問題を解決できます。
Webpack によって起動されるプロキシサーバーは Express です

クロスドメイン

基本的な使い方

要求されたターゲットサーバーアドレスを置き換えるプレースホルダーをdevServer に設定します。
たとえば、ローカル Webpack によって開始されたサービスソースはでhttp://localhost/8080、ターゲットソースをリクエストするとしますhttp://192.163.0.66:12345。API はです/get。

fetch("http://192.163.0.66:12345")
  .then(response => response.json())
  .then(result => console.log(result))

ポート番号が異なるため、これはドメイン間で必ず発生するはずです。このとき、プロキシを使用する必要があります。具体的な方法は、ターゲットソースをプレースホルダーに置き換えることです。

fetch("/api/get") // ‘/api’ 为占位符
	.then(response => response.json())
  .then(result => console.log(result))

しかし、問題が発生しました。まだデータをリクエストできません。プレースホルダーは削除されないため、実際にサーバーデータを要求する URL に追加されます。
webpack devServer proxy.png

パス書き換え

現在のリクエストアーキテクチャは、ブラウザリクエスト --> プロキシサーバーリクエスト --> 実サーバーです。リクエストヘッダーの URL を確認すると、クロスドメインはありませんでしたが、プロキシサーバーから実サーバーに送信されたリクエストにもプレースホルダー/API がありましたが、実際には実サーバーに対応するリソースがないため
、http://localhost/8080/api/get404 を返します。
この時、必ずプロキシサーバーのリクエストURLの書き換えとプレースホルダーの削除が必要です。****pathRewrite: { "^/api-hy": "" }**

変更原点

changeOrigin は、プロキシリクエストのヘッダーのホスト属性を変更し、ターゲットに対応するターゲットリクエストソースに変更できます。
プロキシサーバーは実サーバーにリクエストを送信します。これは、サーバーには同一生成元ポリシーがないため、どのリクエストソースでも自由にリクエストを送信できるためです。たとえば、webpack によって開始されたプロキシサーバーは、実サーバーへのリクエストの送信元になりますhttp://localhost:3000。
ただし、実サーバーにはクローラ防止などの制限がある場合があり、検証リクエストヘッダのURLは実サーバーのソースと一致している必要があります。次に、changeOrigin を true に設定して変更できます。上の図に示すように。

一般的な構成

まとめ：

target: プロキシ先のターゲットアドレスを示します。
pathRewrite: パスを書き換えます。
secure: デフォルトでは、https に転送するサーバーは受信されません。これをサポートしたい場合は、false に設定できます。
changeOrigin: プロキシによって要求されたヘッダー内のホストアドレスを更新するかどうかを示します。

devServer: {
    
    
    proxy: {
    
    
      "/api-hy": {
    
     // 占位符
        target: "http://192.163.0.66/12345",
        pathRewrite: {
    
    
          "^/api-hy": ""
      	},
        secure: false,
        changeOrigin: true
      }
    }
  }
}

履歴Apiフォールバック

HistoryApiFallback は開発において非常に一般的な属性で、その主な機能は、ルートジャンプ後に SPA ページがページを更新する
ときに 404 を返すエラーを解決することです。
更新とは、アドレスバーにある URL を使用してサーバーにリクエストを送信することですが、現在のルートは SPA ページのフロントエンドに設定されており、サーバーの URL に対応するリソースは 404 になるためです。

HistoryApiFallback には 2 つの値があります。

ブール値: デフォルトは false

true に設定すると、更新中に 404 エラーが返されたときに、index.html のコンテンツが自動的に返されます。

オブジェクトタイプの値により、rewrites 属性を構成できます。

パスに一致するように from を設定し、どのページにジャンプするかを決定できます。

実際、devServer のhistoryApiFallback 関数は connect-history-api-fallback ライブラリを通じて実装されています。connect -history-api-fallbackドキュメント
を参照できます。

Webpack はローカル開発サーバーを構築します