メインコンテンツまでスキップ

pnpm でのノードモジュールに関するオプション設定

· 1 分で読む
Zoltan Kochan

node_modules ディレクトリを生成する方法は多くあります。 ゆるい node_modules を作成する方法もありますが、ここでの目標は最も厳格なものを生成することです。

デフォルトの構築方法​

デフォルトでは、pnpm v5 は準厳格な node_modules を作成します。 準厳格な場合は、アプリケーションからはpackage.json に依存として追加されているパッケージのみを require できます。(いくつかの例外を除きます。) ただし、依存関係はどのパッケージにもアクセスすることができます。

デフォルトの設定は以下のようになります:

; すべてのパッケージを node_modules/.pnpm/node_modules に巻き上げる
hoist-pattern[]=*

; TypeScript でうまく扱えるように、すべての型定義をルートに巻き上げる
public-hoist-pattern[]=*types*

; すべての ESLint に関係するパッケージをルートに巻き上げる
public-hoist-pattern[]=*eslint*

プラグ・アンド・プレイ。 最も厳格な設定​

pnpm は v5.9 から Yarn の プラグ・アンド・プレイ をサポートしています。 プラグ・アンド・プレイでは、アプリケーションも、その依存も、宣言された依存にのみアクセスできるようになります。 これは、hoist=falseの設定よりもさらに厳密です。なぜなら、モノレポの内部では、アプリケーションはルートプロジェクトの依存関係にすらアクセスすることができないからです。

プラグ・アンド・プレイを使用するには、次の設定を使用してください。

node-linker=pnp
symlink=false

厳格で伝統的なモジュールディレクトリの構造​

まだプラグ・アンド・プレイを使用する準備ができていない場合でも、hoist を false に設定することにより、パッケージが自身の依存にのみアクセスできるようにすることが可能です。

hoist=false

しかし、いくつかの依存が、その依存にないパッケージへのアクセスを試みようとする場合は、2つの方法があります。

  1. pnpmfile.js を作成して、hook を使用して不足している依存をパッケージのマニフェストに加える。

  2. hoist-pattern 設定にパターンを追加する。 例えば、見つからないモジュールが babel-core の場合は、次の設定を .npmrc に追記します。

    hoist-pattern[]=babel-core

最も悪いケース - ルートへの巻き上げ​

一部のツールは、すべてを仮想ストアのルートに、一部のパッケージをルートに巻き上げる pnpm のデフォルト設定でも機能しない場合があります。 この場合、依存のすべて、または一部をモジュールディレクトリのルートに引き上げることができます。

node_modules のルートにすべてを巻き上げる場合:

shamefully-hoist=true

パターンにマッチしたパッケージのみを巻き上げる場合:

public-hoist-pattern[]=babel-*