1 つの汎用プロキシがすべてのパッケージソースに適するとは限りません。モダン Yarn はホスト名ごとのネットワーク設定に対応しており、選択したホストだけ既定とは別の経路を使えます。

たとえば、プロジェクト全体では 1 つの経路を使い、社内レジストリには別の経路を選べます。

httpsProxy: "http://203.0.113.10:8080"
networkSettings:
  "registry.example.internal":
    httpsProxy: "http://203.0.113.20:8080"

2 つのアドレスはプレースホルダーです。公開パッケージソース向けの汎用経路には、公開プロキシが許可されている場合、HTTP プロキシ一覧が候補を提供します。社内レジストリの上書きは承認済みのプロキシのままにしてください。設定は、モダン Yarn のリリースに適した .yarnrc.yml に記述します。この例は 2 つのプロキシを選んでいるのであり、社内ホストが直接接続すべきだと言っているわけではありません。

要求されたホスト名に一致させる

networkSettings のエントリはホスト名のパターンに適用され、パッケージスコープや任意の URL パスには適用されません。単一ホストの規則を意図しているなら、その規則を正確に保ってください。ワイルドカードが役立つのは、追加のホストに同じ設定を共有させたいと本当に意図している場合だけです。

パッケージスコープとネットワークのホスト名は別のセレクターです。スコープ付きパッケージは、他のパッケージとホストを共有するレジストリから取得されることがあり、リダイレクトされたアーティファクトはまったく別のホスト名から来ることもあります。

ダウンロード経路全体を追う

メタデータが一方のホストを使い、アーカイブのダウンロードがもう一方を使う場合、それぞれが異なるネットワーク設定に一致する可能性があります。規則を広げる前に、実際に失敗している URL を記録してください。「レジストリは動いた」という事実だけでは、後続のリクエストがどの経路を選んだかを示すものではありません。

Yarn のホスト別設定には CA やその他の TLS 設定も含められます。これらの判断は分けておいてください。プロキシのアドレスを選んでも、それだけで通信を検査する環境に必要な信頼が得られるわけではありません。

上書きを目に見える形にする

その Yarn リリースが対応するツールでプロジェクトの実効設定を確認し、そのうえで意図したリクエストを試してください。資格情報が含まれる場合は、設定のダンプ全体を共有しないでください。

この機能は、ホストごとに本当に異なる経路が必要な場合に有用です。すべてのリクエストが同じエンドポイントを使うべきなら、増え続ける同一のホスト名上書きリストより、単一の汎用設定のほうが保守しやすくなります。

関連記事