Webpackがモジュールをバンドルすると、インポートした（または必要な）モジュールの依存関係チェーンに従い、すべての依存関係を取得し、チェーンの最後までバンドルします。
その依存関係チェーンにロードする方法がわからないファイルがある場合、このタイプのエラーがスローされます。
これは、このタイプの依存関係をロードする方法を知っているローダーを追加することで解決できる場合があります。ただし、依存関係が非ネイティブモジュールである場合、Webpackはそれをロードできません。一部のローダーは、非ネイティブ部分をスタブアウトして除外することにより、非ネイティブ依存関係を持つモジュールをロードしてロードする方法を知っています。 fsで たとえば、モジュールでは、ブラウザがディスクからファイルを読み書きできる必要がないため、その部分を含める必要はありません。
これは疑問を投げかけます：あなたはブラウザにマングースモジュールのどの機能が必要ですか？マングースモジュール全体ではなく、その機能だけを含めることはできますか？
これができれば、2つの問題を解決できる可能性があります。
- プロジェクトに含めるマングースの部分には問題のあるサブ依存関係がないため、Webpackのバンドルの問題を解決できる可能性があります。
- 必要な部分のみが含まれるため、Webpackを使用してより小さなバンドルを作成し、クライアントへのbundle.jsペイロードがはるかに小さくなります。
例として、最近、クライアントでmongodbObjectIdジェネレーターを使用する必要がありました。 Webpackがimport mongodb from 'mongodb'に対応できないことを発見しました コンポーネントなので、依存関係を掘り下げて、mongodb mongodb-coreに依存します これはbsonに依存します ObjectIdがあります 必要な方法。
bsonのみをインポートする その依存関係チェーンのコンポーネントで、Webpackの問題を回避し、バンドルをはるかに小さくしました。
Npm 3を使用している場合は、bsonである可能性が高くなります。 node_modulesのルートにインストールされます すでにmongooseまたはmongodbを使用している場合は、import package.jsonに明示的な参照を入れずに 。これには明らかに、上位の依存関係がそれに依存して停止すると、ビルドが壊れて、npm installが必要になるというリスクが伴います。 それは独立して。このアプローチを使用する利点は、常に同じバージョンのbsonを使用することです。 上位の依存関係が使用していること、これは重要かもしれません。