Three.js: 例のjsmモジュールをインポートすると、バンドラーはthree.jsソースコードを2回バンドルします

（ロールアップでテスト済み）

ロールアップでは確認できません。 次のプロジェクト設定のように実行している場合、すべてが期待どおりに機能します。

https://github.com/Mugen87/three-jsm

threeを外部依存関係として扱う場合：

export default {
    input: 'src/main.js',
    external: ['three'],
    output: [
        {
            format: 'umd',
            name: 'LIB',
            file: 'build/main.js'
        }
    ],
    plugins: [ resolve() ]
};

その場合、出力にはthree.jsのソースコードが含まれていてはなりませんが、すべてが含まれています。

ただし、OrbitControlsをインポートしない場合、出力にはmain.jsファイルのソースコードのみが含まれます。

OrbitControlsインポートをコメントアウトしてから、'three'を使用します）。

これは＃17220に関連しています-そこで提案された解決策の1つは、 package.jsonのmainフィールドをモジュールビルドパスに置き換えること

ここでの問題を明確にするために、 threeが外部としてマークされている間、 ../../../build/three.module.jsへのハードリファレンスをキャッチしないロールアップ構成の3つに依存する別のパッケージを構築します。ビルドに含まれます。 たとえば、次のファイルをビルドすると、誤ってOrbitControlsコードとthreejsコードがバンドルに含まれ、@ adrian-delgadoの投稿された構成でビルドされたときに3つの別のコピーがインポートされます。

// src/main.js
import * as THREE from 'three';
import { OrbitControls } from 'three/examples/jsm/controls/OrbitControls.js';

console.log(THREE, OrbitControls);

でパスしてもいることは注目に値するかもしれないエイドリアン・デルガド@ OrbitControls.jsに変更されたthree OrbitControlsはまだかないことが望ましい場合があると、少なくともにつながる可能性がある、あなたのバンドルに含まれますOrbitControlsコードは、依存するアプリケーションに2回含まれています。

これを長期的または最善の解決策として提案するつもりはありませんが、構成を変更してOrbitControls （および3つのフォルダー内のすべてのファイル）を外部としてマークすると、どちらの場合もこれが解決されます。

export default {
    // ...

    external: p => /^three/.test(p),

    // ...
};

これを長期的または最善の解決策として提案するつもりはありませんが、構成を変更してOrbitControls（および3つのフォルダー内のすべてのファイル）を外部としてマークすると、どちらの場合もこれが解決されます。

何らかの理由で、ロールアップがデフォルトで'three/examples/jsm/controls/OrbitControls.js'も外部として扱うことを期待していました。 したがって、提案されたソリューションは私のユースケースに適しています。

関連する＃17220は非常に関連性があります。 会話はおそらくそこで続くはずです。

では、これを行うとどうなりますか？

// src/main.js
import * as THREE from 'three/build/three.module.js';
import { OrbitControls } from 'three/examples/jsm/controls/OrbitControls.js';

console.log(THREE, OrbitControls);

それは機能しますが、3に依存する他のlibまたはコードの一部が「three」からインポートされてから再び壊れるため、実行可能ではありません。 Package.jsonは通常、環境に解決方法を指示します。「build / three.module」は、リークしてはならないディストリビューションの詳細です。 解決がスキップされると、名前空間の問題が発生します。

  external: p => /^three/.test(p),

@gkjohnsonユーザーが「3つの」インスタンスとOrbitControlsをバンドルに含めたい場合はどうなりますか？

このようにライブでモジュールを使用しようとすると、同様のことが発生することに関連しているかどうかはわかりません

import * as three from 'https://cdnjs.cloudflare.com/ajax/libs/three.js/108/three.module.js';
import { OrbitControls } from 'https://threejs.org/examples/jsm/controls/OrbitControls.js';

three.jsを2回ロードします。1回はCDNから、もう1回はthreejs.orgからロードします。

たぶんそれはモジュールが3つで使用されることになっている方法ではありませんが、106より前から行くだけで何千ものサイトと例があります

<script src="https://cdnjs.cloudflare.com/ajax/libs/three.js/105/three.min.js"></script>
<script src="https://threejs.org/examples/js/controls/OrbitControls.js"></script>

すべての例は、build（bundling）の代わりにライブでモジュールを使用することを示しているため、ある意味では、以前のようにthree.jsを使用する実際の方法を示していません。 言い換えれば、古い例は箱から出してすぐに機能しました。 新しい例はAFAIKではありません。 例が機能するためには、例からJavaScriptを抽出し、別の.jsファイルに入れてから、three.jsをローカルに（おそらくnpmを介して）置く必要があります。 例のすべてのパスを修正して、パッケージベースのパス（../.././buildなし）にし、最後にロールアップを使用します

これは、パスを変更するだけで十分だった非モジュールバージョンからのかなり大きな変更です。

@mrdoob

@ adrian-delgadoの元の構成では、three.jsが1回含まれ、オービットコントロールが1回含まれ、パッケージが外部としてマークされることはありません。 私が提案した構成では、生成されたバンドルのthree/build/three.module.jsとthree/examples/jsm/controls/OrbitControls.jsに外部依存関係があります。

@EliasHasle

ユーザーが「3つの」インスタンスとOrbitControlsをバンドルに含めたい場合はどうなりますか？

次に、 externalフィールドを除外する必要があります。その場合、3つの軌道コントロールの単一のコピーがバンドルに含まれます。 rollup-plugin-node-resolve （モジュール解決をサポートするためにロールアップに必要であり、上記の構成で使用されています）は、デフォルトでpackage.jsonのモジュールフィールド（ mainFieldsオプションを参照）を使用するため、軌道3つの参照を制御し、「3」は同じスクリプトに解決されます。 _ mainFieldsが["main", "module"]変更され、package.json_で「module」の代わりに「main」が使用される場合、3つのコピーが2つここに含まれ、これまでの方法で問題が発生します。前述のとおり。 ただし、そのフィールドを変更する必要があります。 ただし、「main」を使用する場合は、 rollup-plugin-commonjsも必要になる可能性があります。これは、rollupがデフォルトでrequireを使用するcommonjsファイルの処理方法を認識していないためです。

@greggman

残念ながら、この場合、モジュールの単純な交換がそれほど簡単に機能するとは思いません。 提案されたソリューションはいずれもこのケースに対処するものではなく、コアスクリプトと例を別々のホストからインポートするケースを支援するために使用できる公式なものは現時点ではないと思います。 私の知る限り、これを支援するために作業中ののはインポートマップだけです。 例と3つの両方が同じホストからインポートされた場合、3つのコピーが1つだけロードされます。

import * as three from 'https://cdnjs.cloudflare.com/ajax/libs/three.js/108/three.module.js';
import { OrbitControls } from 'https://cdnjs.cloudflare.com/ajax/libs/three.js/108/examples/jsm/controls/OrbitControls.js';

// or

import * as three from 'https://threejs.org/build/three.module.js';
import { OrbitControls } from 'https://threejs.org/examples/jsm/controls/OrbitControls.js';

ユースケースによっては、従来のスクリプトタグを引き続き使用することが望ましい場合がありますか？

@greggman

このようにライブでモジュールを使用しようとすると、同様のことが発生することに関連しているかどうかはわかりません

import * as three from 'https://cdnjs.cloudflare.com/ajax/libs/three.js/108/three.module.js';
import { OrbitControls } from 'https://threejs.org/examples/jsm/controls/OrbitControls.js';

ええ...そのようなモジュールは使用しないでください😁

ええ...そのようなモジュールは使用しないでください😁

同意しました。 ほぼ間違いなく、ドキュメントと例はほとんど経験の浅い開発者を対象としており、jsmの例がデフォルトであり、ビルダーなしでは機能せず、CDN経由でも機能しないという事実は一種の大きな変化です。

以前は、基本的に例のソースを表示し、コピーしてjsfiddle / codepenなどに貼り付け、スクリプトタグのパスを修正すると、実行されていました。 ただし、three.jsサイトに直接リンクして、バージョンがバンプされるたびにサンプルが壊れるのを確認しない限り、すべての例は実行されません。 （はい、モジュール以外の例が存在することは知っていますが、それらはhttps://threejs.org/examplesからリンクされているものではありません）

@gkjohnson

import * as three from 'https://cdnjs.cloudflare.com/ajax/libs/three.js/108/three.module.js';
import { OrbitControls } from 'https://cdnjs.cloudflare.com/ajax/libs/three.js/108/examples/jsm/controls/OrbitControls.js';

動作しません。OrbitControlsがCDNになく、OrbitContrls ../../../ bulild / three.js内のパスが正しく動作しません。

// また

import * as three from 'https://threejs.org/build/three.module.js';
import { OrbitControls } from 'https://threejs.org/examples/jsm/controls/OrbitControls.js'

また、three.jsが新しいバージョンをプッシュするたびに壊れてしまうため、機能しません

たぶん、examples / jsフォルダーをCDNと3つにプッシュして、サンプルコードのURLを修正するだけでも機能するようにしますか？ つまり、three.module.jsは次の場所にある必要があります

https://cdnjs.cloudflare.com/ajax/libs/three.js/108/build/three.module.js

buildがパスに追加されました

オプションについて言及すると、jsdelivrやunpkgなどの他のCDNはESモジュールをサポートしています。

• https://cdn.jsdelivr.net/npm/[email protected]/examples/jsm/loaders/GLTFLoader.js
• https://unpkg.com/[email protected]/examples/jsm/loaders/GLTFLoader.js

以前は、基本的に例のソースを表示し、jsfiddle / codepenなどにコピーして貼り付け、スクリプトタグのパスを修正すると、実行されていました...

良くも悪くも、それについて何か役に立つことをするには、インポートマップが必要だと思います。

これで、three.jsサイトに直接リンクしない限り、すべての例が実行されるわけではありません。

threejsサイトのライブスクリプトに直接リンクすることを誰にも勧めません...それは決して良い考えではありません。 上記のコメントごとに、バージョン管理された代替案があります。

理想的には、これらの質問に答えるドキュメントは、[モジュール経由でインポート]ページです。 そこでカバーすべきケースはありますか？ CDNについて言及するのは良い考えだと思います。

CDNに言及することは良い考えです。 また、Googleで最初にヒットしたcloudflare CDNは、モジュールには適していません（変更されない限り）

@greggman

以前は、基本的に例のソースを表示し、コピーしてjsfiddle / codepenなどに貼り付け、スクリプトタグのパスを修正すると、実行されていました。

私はあなたの味方です。 モジュールの最悪の部分は、例のコンソールからcameraまたはrendererアクセスできなくなったことです😟

• https://unpkg.com/[email protected]/examples/jsm/loaders/GLTFLoader.js

unpkgを使い始めてみませんか？

unpkgを使い始めてみませんか？

[モジュール経由でインポート]ページなどのドキュメントで使用を開始するのですか、それともプロジェクトで何らかの方法で使用するのですか？

モジュールの最悪の部分は、例のコンソールからカメラまたはレンダラーにアクセスできなくなったことです。

ええ、それはイライラします。 ローカルで開発するとき、私はこれ（または同様のもの）を例に投げ込んできました：

Object.assign( window, { camera, renderer, scene } );

それは開発ツール拡張機能で解決したいと思っていることだと思いますか？

調査が必要ですが、興味深いアイデアが1つあります...すべての例にインポートマップのポリフィルを追加する場合は、そこで使用されるインポートをnpmと互換性のある100％コピー/貼り付けにすることができると思います-およびバンドラーベースのワークフロー。 例えば：

<script defer src="es-module-shims.js"></script>
<script type="importmap-shim" src="importmap.dev.js"></script>

<!-- ... -->

<script type="module-shim">
  import { Scene, WebGLRenderer } from 'three';
  import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js';

  // ...
</script>

unpkgを使い始めてみませんか？

[モジュール経由でインポート]ページなどのドキュメントで使用を開始するのですか、それともプロジェクトで何らかの方法で使用するのですか？

https://threejs.org/build/を指す代わりにISSUE_TEMPLATEでそのリンクを使用しています。

そして、 @ greggmanはおそらくhttps://cdnjs.cloudflare.com/ajax/libs/three.js/108/からますか？

unpkgは、ここで説明している問題を解決するようです。

ええ、それはイライラします。 ローカルで開発するとき、私はこれ（または同様のもの）を例に投げ込んできました：

Object.assign( window, { camera, renderer, scene } );

うーん！ ハハ

それは開発ツール拡張機能で解決したいと思っていることだと思いますか？

はい！ 🤞

@greggman

このようにライブでモジュールを使用しようとすると、同様のことが発生することに関連しているかどうかはわかりません

import * as three from 'https://cdnjs.cloudflare.com/ajax/libs/three.js/108/three.module.js';
import { OrbitControls } from 'https://threejs.org/examples/jsm/controls/OrbitControls.js';

ええ...そのようなモジュールは使用しないでください😁

だから今日、私は自分がまさにそれをしていることに気づきました...😅それは確かに悪い習慣ですが、問題はほとんどのものが一種の仕事であるということですが、何かが壊れた場合、それを特定するのはかなり難しいです。

私の場合は、インポートされたthree.module.jsからdevとOBJLoaderからmaster 。 OBJLoader輸入three.module.jsからmasterので、 BufferGeometry持っていなかった新しいusageプロパティを、そしてWebGLRendererやりましたusage見つからなかったため、メッシュをレンダリングしません

これはかなり毛深いです...

慣れるべきものだと思います。 私はそれを手に入れたと思うので、私はそれがそうであるように大丈夫です。

ところで、私はthreejsfundamentalsをすべてesmベースになるように更新したので🤞

three.module.min.jsを持っているのは良いことのように思えますが（またはthree.min.module.js 😜）

+1

ES6モジュールとして3つのオービットコントロールをインポートしています。オービットコントロールはビルドフォルダー内の3つを参照しているため、パスを把握するのに時間がかかりました。

スーパーファンは3つをモジュールとして使用できますが、これについてもっと柔軟性があるといいのですが、他のモジュールにも当てはまると仮定して、軌道制御ファイルに移動していじり始めるつもりはありません。

また、three.min.module.jsの場合は+1😎

＃18239から移動して、three.jsを使用する別のパッケージでnpm linkを実行することで、同様の問題に巻き込まれ

この問題の解決に役立つ可能性のあるプラグイン3ミニファイアを開発しました。

私は同じ問題に直面しています。 私はthree.jsを使用してReactコンポーネントを作成しており、例からいくつかのモジュールをインポートしています。 ロールアップでバンドルされたら、バンドルを見ると、3つに対して1つのインポートステートメントがあり、次にThree.jsコードがあることがわかります。

コンポーネントでこのインポートステートメントを使用する場合： import * as THREE from "three/build/three.module"
物事は正しく機能しますが、Threeはバンドルに埋め込まれます。これは私が望まないことです。
3つのインポートステートメントが欲しいのですが。 import * as THREE from "three使用すると、バンドルには3つがモジュールとしてインポートされますが、例の1つを使用するとすぐに、three.jsがバンドルに追加されます（= 3つに対して1つのインポートステートメントがあります、そして3つのコード）、これは最終的に私のコードを壊します

@chabb

私はthree.jsを使用してReactコンポーネントを作成しており、例からいくつかのモジュールをインポートしています。 ロールアップでバンドルされたら、バンドルを見ると、3つに対して1つのインポートステートメントがあり、次にThree.jsコードがあることがわかります。

ここに投稿された解決策はあなたの問題を解決するはずです： https ：//github.com/mrdoob/three.js/issues/17482#issuecomment-530957570。

これらの問題の多くは、バンドラーで何が起こっているのかを完全に理解していない人々に起因していると思います（これは理解できます）が、これらの問題は3つに固有のものではありません。 ただし、誤って3つのコアを二重にインポートすると、他のライブラリよりも目立つ可能性があります。 lodash、reactコンポーネント、OrbitControlsなどの外部を意図した依存関係をバンドルすると、簡単に見落とされる可能性があります。

外部パッケージに依存することに関して、Rollupはこの動作を文書化し、ここにオプションを提供します。Webpackにも同様のオプションがあります。 この場合、サンプルファイルが代わりに「3」を参照していると、コアライブラリはバンドルされませんが、サンプルコードのバンドルが重複することになります。これはそれ自体の問題です。 そして、バンドラーがnpmリンクの落とし穴を解釈するのを助けるためにこのプロジェクトができることは何もないと思います。 私が見た唯一の問題のあるケースは、誤って構成されたバンドラーの結果ではないと感じているのは、codesandboxのケースだと思います。

バンドラーの場合、答えは、ドキュメント化、トラブルシューティングガイドの追加、またはモジュール経由のです。

examples/jsmパッケージがこのパターンを変更できるとしたら...

// <strong i="7">@file</strong> GLTFLoader.js

// Before
import { Mesh } from '../../build/three.module.js';

// After
import { Mesh } from 'three';

...これらの問題ははるかに簡単に解決できます。 残念ながら、複雑なビルド設定なしで、threejsWebサイト内のHTMLサンプルをどのように管理するかはわかりません。 threejs Webサイトのインポートマップポリフィルで解決できる可能性がありますが、よくわかりません。 ：/

サンプルファイルが代わりに「3」を参照している場合、コアライブラリはバンドルされませんが、サンプルコードのバンドルが重複して表示されます...

私はこれに完全には従いません。 それらは相対パスインポートなので？ それらをパッケージ相対にすることができます。

@donmccurdy

私は、examples / jsmパッケージがこのパターンを変更できれば、これらの問題ははるかに簡単に解決できるだろうという予感があります。

これで解決したように見えると思いますが、アプリケーションが破損しないため、コードが重複していることに気づきにくい場合があります。

私はこれに完全には従いません。 それらは相対パスインポートなので？ それらをパッケージ相対にすることができます。

不明な点がある場合は申し訳ありませんが、これを説明するのは少し難しいと思います。うまくいけば、これはもう少し明確になります。 ロールアップケースを使用します。

threeが外部としてマークされたパッケージをロールアップしたい上記の場合、three.jsが別のアプリケーションが依存できるピア依存関係になるライブラリを構築していると思います。

import * as THREE from 'three';
import { OrbitControls } from 'three/examples/jsm/controls/OrbitControls.js';
import { stuff } from './local/src/index.js';

// library code with exports...

ここでの目標は、上記のthree.jsインポートをライブラリに残し、バンドルで3つとOrbitControlsをピア依存関係としてロードすることです。したがって、アプリケーションがthree.jsとOrbitControlsも使用する場合は、どちらも2回インポートしないでください。

人々は、オプションexternal: [ 'three' ]がこの動作を実現することを期待していますが（私は確かにそうしました）、文字列がOrbitControlsインポートパスと一致しないため、そうではありません。 これにより、 OrbitControlsが意図せずにバンドルされ、したがって../../../build/three.module.jsもバンドルされます（文字列とも一致しないため）。 バンドルされているthree.jsコアファイルは、アプリケーションが壊れている、ライブラリバンドルがはるかに大きいなど、はるかに目立つため、人々は指摘していると思います。実際には、OrbitControlsファイルはバンドルされるべきではありませんでした。そもそも。_ここでロールアップを構成する正しい方法は、オプションをexternal: path => /^three/.test( path )に設定することです。

これは3つに固有のものではありません。 Rollupは、ドキュメントの例として使用していますが、 'lodash/merge'がライブラリコードにバンドルされているかどうかマテリアルUIは、インポートでネストされたファイル参照を推奨します。同様に、 external: ['@material-ui/core']を設定すると、バンドルから'@material-ui/core/Button'を除外できません。

これらのユースケースのサンプルコードを変更する価値はないと思います。それでも、バンドラーが適切に構成されている場合は存在しない重複コードが発生するためです。

ここで2つのケース：

（1）ユーザーはthreejsと例を1回含めたい、何かを2回取得したい

たとえば、アプリケーションの構築中。

（2）ユーザーはthreejsと例をゼロ回含めることを望んでおり、1回以上何かを取得します

たとえば、外部またはピアの依存関係として3つを使用してライブラリを構築しているとき。

私の知る限り、（1）と（2）の両方がまだ簡単に遭遇する問題ですか？ 上記のアプローチで（1）が解決する場合は、それだけでも役立ちます。 （2）についてはよくわかりません。 たぶん/^three/.test( path )トリックはモジュールを介した

@gkjohnsonこの説明をありがとう、それは私が私の考えを明確にするのを本当に助けました

私のロールアップ構成では、 externalこのように定義していました

[
        ...Object.keys(pkg.dependencies || {}),
        ...Object.keys(pkg.peerDependencies || {}),
        ...other_stuff
      ]

3つは外部依存関係として扱われるので、うまくいくと思いました。 しかし、あなたが言ったように、あなたは正規表現を使わなければなりません（私が理解している限り、それは例がやっているからだと思います
import from "../../../build/three.module.js"; ）。 だから私はやることになりました

external: p => {
      if ([
        ...Object.keys(pkg.dependencies || {}),
        ...Object.keys(pkg.peerDependencies || {}),
        'prop-types'
      ].indexOf(p) > -1) {
        return true;
      }
      return /^three/.test(p) ;
    }

少し関係のない質問ですが、 package.json宣言したすべての依存関係がバンドルの一部ではないと思いますか？ それは正しい仮定ですか？

@donmccurdy

私の知る限り、（1）と（2）の両方がまだ簡単に遭遇する問題ですか？

私の意見では、（2）はバンドラーを誤って構成した結果であり、バンドラーに関するいくつかの提案でドキュメントを更新することで対処できるかもしれません。 （1）問題（2）に悩まされているパッケージを使用した結果として発生する可能性がありますが、それ以外は（1）つまずきやすいと私は確信していません。 誰かがバンドラーをどのように構成したかを確認するための問題を示す実際のユースケースを見たいのですが、これを打つことができると私が知っている方法のリストは次のとおりです（これまでのところ）：

1. 'three/src/Three.js'または'three/build/three.min.js'から明示的にインポートします（これはドキュメントでは推奨されていません）。
2. 解決時にpackage.moduleフィールドではなくpackage.mainフィールドを使用するようにバンドラーを再構成します。 ただし、3つの大きなバンドラーRollup 、 Webpack 、およびParcelはすべて、デフォルトでmainよりもmoduleを優先します。 このユースケースは珍しいように感じますが、それは単なる仮定です。
3. npm linkを使用して、3つに依存するシンボリックリンクされたパッケージを含めます（これは、ロールアップのpreserveSymlinksオプションを使用して修正されます）
4. プラットフォームはモジュールよりもメインフィールドを優先codesandbox.ioで3つの例を使用してください。

人々が木の揺れのために1をしていることを私は知っていますが、4番は簡単につまずくことができる唯一のもののようです。 他の人たちは、彼らが私たちのコントロールの外にいる、または非常に珍しいと感じています。

@chabb

私が理解している限りでは、例がimport from "../../../build/three.module.js";実行しているためだと思います...

そうではありません。https ： /^threeは、文字列'three/examples/jsm/controls/OrbitControls.js'と一致するため機能します。これは、文字列'three'が一致しないのに対し、three.jsライブラリの一部であるため、外部にある必要があります。 同じことが他の依存関係でも発生する可能性があります。 他の未知の落とし穴を回避したり、裸のモジュール指定子を持つパッケージと照合したりするために、すべての依存関係に正規表現を使用することをお勧めします。

@gkjohnson詳細な説明をありがとう、それは私には理にかなっています。

結局、これではこのスレッドの問題は解決されないようですが、スレッドですでに数回言及しているので、最終的にインポートマップポリフィルをテストしました： https ： import * as THREE from 'three';はWebブラウザで機能します。

ブラウザだけがある程度の自信を示したら...
https://github.com/WICG/import-maps/issues/212#issuecomment -663564421

プロジェクトの1つにパスサブクラスを追加するときに同じ問題が発生しました

import { /* stuff */ } from 'three'
import { Pass } from 'three/examples/jsm/postprocessing/Pass.js'

そして、パスコードをモジュールにコピーすることを好んだので、後でブラウザーのthree.jsからインポートする必要がないように、回避策を見つけました。

const threeModulePath = path.resolve( __dirname, 'node_modules/three/build/three.module.js' );

export default {
    /* ..... */
    external: [ 'three' ],
    output: [
        {
            /* .... */
            globals : {
                'three': 'THREE',
                [ threeModulePath ]: 'THREE',
            }
        }
    ]
};

このように、それはブラウザで動作し、モジュールのインポートも同様に動作するはずです。

編集：

ローカルの3つのプロジェクト（以下の例を参照）からロードすると、このアプローチが破られ、追加の回避策が必要になります。

"dependencies" : {
    "three": "file:../three.js"
}

さて、私は先に進んで、ローカルリンクをサポートする新しいバージョンを作成しました：

const threeName = "three"; // Change with your three package name
const dependencies = require('./package.json').dependencies;
const splits = dependencies[threeName].split('file:');

const modulePath = (splits.length > 1) ?
    path.resolve(__dirname, splits[1], 'build/three.module.js'):                  // Resolve local path
    path.resolve(__dirname, 'node_modules', threeName, 'build/three.module.js');  // Resolve node_module path

const external = [
    threeName,
    modulePath,
]

const globals = {
    [threeName]: 'THREE',
    [modulePath]: 'THREE',
}

@Mcgodeこれは、上記のhttps://github.com/mrdoob/three.js/issues/17482#issuecomment-530957570で対処されています。 Rollupを使用していて、サンプルモジュールを使用するときにthree.jsを外部としてマークしたい場合は、提案されているように次のことを行う必要があります。

externals: p => /^three/.test(p),

設定をそれほど複雑にする理由はありません。 これにより、Pass.jsファイルとthree.jsモジュールの両方がexternelとしてマークされます。

@gkjohnson例ではなく、 three libのみを外部としてマークしたいので、私のユースケースはまったく同じではありません（例をビルドにバンドルしたい）。

外部として3つを使用してライブラリをビルドしていますが、ビルドの幅は3つではなく、サンプルをバンドルする必要があります。前述のように、例からモジュールをインポートすると、出力に3つのコードが含まれます。 webpackで達成することは可能ですか？

import {  } from "three";
import { Line2 } from "three/examples/jsm/lines/Line2";
import { LineGeometry } from "three/examples/jsm/lines/LineGeometry";

@ Mcgode @ recardinalそれは不可能だと思います。 同じことをしたかったので、例からコードをコピーして貼り付けました。 私の場合、インポートとエクスポートを「調整」する必要がありました。それだけでした。 明らかにこれは理想的ではありませんが、私のユースケースには十分でした。

WebpackとTHREEを外部として使用した同様のユースケースがあります。 次のインポートにより、three.module.jsがバンドルされた出力に含まれます。

import * as THREE from 'three';
import { ColladaLoader } from 'three/examples/jsm/loaders/ColladaLoader';
import { OBJLoader } from 'three/examples/jsm/loaders/OBJLoader';
import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader';

私はどこかでexamples / js / *がいつか削除されることを読みました。 その前にjsmの例が「うまくいく」といいのですが。