Three.js: ES6JSMライブラリと一緒にJSライブラリのサポートを継続する

私が正しく理解していれば、計画は「/build/three.module.js」に加えて「/build/three.js」を含めることです。

はい。 ただし、このアプローチが理にかなっているかどうかは疑問です。 examples/jsが削除されても、 three.jsとthree.min.jsが引き続き役立つユースケースはごくわずかです。

three.jsとthree.min.jsを削除すると、 npmパッケージのmainエントリポイントを変更できるため、実際には有益です。＃19575を参照してください。

簡単にできるのであれば、ビルドプロセスの一部としてES6バンドラースクリプトを介して/ examples / jsを自動的に生成することにより、/ examples/jsのサポートを継続することは理にかなっていると思います。

アイデアは、 examples/jsmをクラスなどの最新のJavaScript言語機能に移行することです。 examples/jsは古いブラウザでも機能するはずなので、コード変換機能を使用して新しい（例）ビルドを構成する必要があります。 その上、重複したコードベース（ examples/jsとexamples/jsm ）を保持しますが、これは私の見解では悪いアプローチです。 メンテナンスがより複雑になります。

必要に応じて、ユーザーがES6からES5への変換を行う必要があると思います。 コードの縮小やその他のビルド関連のタスクについても同じです。

私はあなたが正しいと信じています。 私が正しく理解していれば、計画は「 /build/three.module.js 」に加えて「 /build/three.js 」を含めることです。

真

/examplesフォルダーからの塗りつぶしの問題は、$＃ /build/three.jsを使用した場合は/examples/jsのファイルを使用し、 /build/three.module.jsを使用した場合は/examples/jsmのファイルを使用する必要があることです。 /build/three.module.js 、別名ロードメソッドの一貫性を保ちます。

なんで？ モジュールインポートを使用すると、メインのTHREEオブジェクトはプレーンなjsオブジェクトTHREE = {}ではなく、封印された（拡張できない）内部ブラウ​​ザのモジュールオブジェクトであるため、 /examples/jsからのファイル$ THREEオブジェクトに新しいプロパティを書き込もうとする＃$は失敗します。

したがって、 import * as THREE from '/build/three.module.jsとTHREE.WhateverExample = function() ...を混在させることはできません

考えられる方法の1つは、インポートされたlibの名前をTHREE以外に変更し、例を書き込むためのプレーンなjs THREEグローバルオブジェクトを再作成することです...

これは通常、

従来のJSには

これはグローバルスペースの命名を意味し、ロードされたファイルに名前を変更できないため、次のようなエラーが発生する可能性があります...
一方、モジュールを使用すると、ユーザーはインポート中に名前を付けることができ、結果の名前を選択するのはライブラリの作成者ではなくなります...

元：

<script>
// a script you can't modify already use the name THREE
var THREE = document.getElementById('div-nb-3')
</script>

<script type="module">
import * as foo from '/build/three.module.js'

THREE.appendChild( new foo.WebGLRenderer().domElement )
</script>

@ Mugen87あなたは100％正しいです。 / examples / jsを破棄する場合、アドオンモジュールのいずれとも本質的に互換性がないため、 three.jsとthree.min.jsを破棄することもできます。 それらのユースケースはニッチであり、これは混乱を引き起こすことがほぼ保証されています。

@devingfx確かに、モジュールには利点があり、潜在的なグローバル名の競合を排除します。 長年の使用で、THREEグローバル変数と競合することは一度もありませんでした。これはありそうもないシナリオだと思いますが、あなたの主張は技術的に正しいです。

これは私の見解では悪いアプローチです。 メンテナンスがより複雑になります。

必要に応じて、ユーザーがES6からES5への変換を行う必要があると思います。 コードの縮小やその他のビルド関連のタスクについても同じです。

@ Mugen87モジュールに加えてグローバル変数を使用する従来のjsインクルードを維持するのは本当にひどいですか？ 多くのライブラリは両方をサポートしており、私が知る限り、従来のJSバージョンは、モジュールバージョンの対応するライブラリと同じくらい一般的に使用されています。 どちらにも長所と短所があり、その一部は好みに応じて要約されます。 モジュール以外のコンテキストでライブラリを使用するオプションを開発者に提供するのは良くありませんか？

three.module.jsと/examples/ jsmからthree.min.js、three.js、/ examples / jsを自動的に生成するために必要なコード変換機能の作成/テストを、喜んで行います。 トランスパイルワークフローが洗練された後は、最小限のメンテナンスが必要になる場合がありますが、！=2つの並列バージョンを維持します。 ほとんどの場合、コードはモジュールファイルで更新する必要があるだけであり、たまにしかトランスパイルの失敗を修正する必要があります。

従来のグローバル構文に依存するプロジェクトが十分にあり、モジュールのトランスパイルを自動化するための作業を行う予定です。 少なくとも、package.jsonにコマンドを含めて、モジュールをthree.min.js、three.js、および/ examples/jsに変換する「legacy-build」と呼ぶことができると思います。これらは元のコマンドと同様に動作します。今すぐファイル。 これらのファイルは、リポジトリにコミットしたり、デフォルトで作成したりする必要はありません。 また、レガシーサポート用であると警告することもできますが、動作が保証されているわけではありません。代わりにモジュールを使用することをお勧めします...

現実的には、それらをリポジトリに保持し、ビルド時にトランスパイルを介して自動的に生成する方が理にかなっていると思います。

package.json内のコマンドで、モジュールを生成する「legacy-build」と呼びます

合理的なようです。 最近、バベルは合併していませんか？ だからこれはそのままでできるのではないかと思います

編集：明確にするために、上記のビルドを希望するユーザー以外の人が実行する新しいコマンドを言わないようにする

モジュールに加えてグローバル変数を使用する従来のjsインクルードを維持するのは本当にひどいですか？

これを維持することの複雑さは過小評価されていると思います。 残念ながら、プロジェクトでの例の設定方法はそれほど単純ではないと思います。

例としてGLTFLoaderを見てみましょう。 現在、すべてのGLTFLoaderは単一のファイルに含まれているため、HTMLファイルの先頭に簡単に含めることができます。 モジュールの利点の1つは、大きなファイルの一部を個別のファイルに分割して、GLTFLoaderが依存関係としてインポートできることです。 GLTFLoaderが4つの外部ファイルに依存し、そのうちのいくつかが共有されている場合、ビルドされたグローバルスクリプトにはどのように含める必要がありますか？ ビルドされたグローバルスクリプトのユーザーは、これらのサンプルjsファイルをすべて個別に含める必要がありますか？ または、一緒にバンドルしても問題がなく、そうでないファイルのリストを手動で維持する必要があるいくつかのファイルが一緒にバンドルされますか？

本当に設定され忘れられているのは、すべてのサンプルjsファイルを単一のモノリシックblobにバンドルすることだけだと思いますが、これは合理的ではないと思います。 これらのソリューションのいずれかを使用すると、他のリリースやドキュメントのオーバーヘッドも発生すると思います。

おそらくそれを行うためのより良い方法がありますが、下位互換性または少なくとも既存のjsファイルとの一貫した構造を保持するロールアップビルドを作成しようとしたときに、これらは私が遭遇した問題です。

私が正しく理解していれば、計画は「/build/three.module.js」に加えて「/build/three.js」を含めることです。

はい。 ただし、このアプローチが理にかなっているかどうかは疑問です。
examples / jsが削除されても、three.jsとthree.min.jsが引き続き役立つユースケースはごくわずかです。

@ Mugen87 @mrdoob

マイケル、
実際、「three.min.js」を少なくともあと2年間保持することは、必須です。
私のすべてのサンプルがそれに基づいているからではありません。
しかし、何千ものファイルとグーグルのトップドッグがそれに基づいているからです！
例： https ：//www.google.com/search？source = hp＆q = webgl + benchmark

一方、私の観点からは、「three.min.js」はより迅速な開発とテストを意味します。
オフラインで動作し、ローカルホストは必要ないことは言うまでもありません。
すべてのファイルをどこかのフォルダに入れ、Firefoxを使用してHTMLファイルをダブルクリックするだけです。
私はいつも開発のためにそれを愛していました！

リカルドもこれらすべてについて考える必要があります。
乾杯

three.jsとthree.min.jsの削除は、 examples/jsがなくなったときに話し合い、計画できるものです。 examples/jsからファイルをインポートできなくなったときに、それらの重要性が失われたことを強調することが重要でした。

これを維持することの複雑さは過小評価されていると思います。 残念ながら、プロジェクトでの例の設定方法はそれほど単純ではないと思います。

私はあなたが持ち出すポイントが本当に好きです。 バンドルにはまったく予期しない複雑さがあり、ネストされたモジュールの例は良い例です。 あなたのポイントでは、その時が来たら、ネストされたモジュールのバンドルをどのように処理するかについて賢明な決定を下すことができると思います。 バンドラースクリプトが設定されて状況を忘れると言っているのではなく、単にメンテナンスが少なくなるということです。

メンテナンスが難しい時期が来たらいつでも落とせますが、まだ問題がないので値引きするのはばかげていると思います。 / examples/jsmとexamples/jsの間に1対1のパリティが残っている間に、今すぐ実装するのが最も簡単です。 / example / jsmモジュール階層を大幅に再編成することはおそらくないでしょう。そうすることで、バンドラーを段階的に更新できると思います。 私は先に進んで、これのための仕事の証明に取り組み始めます（それはすでに追加されているので、バベルで？）私の口が彼らが言うように私のお金を入れます。

Mugenの指摘によれば、これはthree.jsとthree.min.js $との関連性を維持しながら、それらを維持するのに役立ちます。 また、モジュールベースではないTHREE実装と互換性のあるアップデートを探している可能性のある何百ものサイトにも役立つ可能性があります。 モジュールを使用するための3つのプロジェクトのリファクタリングは、自分が何をしているのかを知っている場合でも、非常に広範囲に及ぶ可能性があります。

他の協力者について話すことはできませんが、このトピックについては考えを変えるつもりはありません。 ここで説明し、コミットしたように、2020年の12月のリリースでexamples/jsを削除することに投票します＃18749。

ここで説明し、コミットしたように、2020年の12月のリリースでexamples / jsを削除することに投票します＃18749。

何の問題もありません。
「three.min.js」がさらに数年間利用可能である限り...

無限の入力をありがとう、私はそのスレッドを読み通しましたが、それは決定の説明ではなく、より多くの発表のように見えます。 私の想定では、開発の簡素化がこの方向に進む主な理由ですが、他に何かありますか？

/ examples / jsスタイルのインクルードを生成するために実行できる変換スクリプトがあることは、ここでは問題ない妥協点になるはずです。 ここで必要なメンテナンス/複雑さの量を大幅に減らす必要があります。 それがpackage.json内の単なるコマンドであり、自分で実行する必要があり、ファイルがデフォルトで生成されなかったとしても、私は大丈夫です。 とにかくトランスパイルする必要がある開発者や他の開発者にとっては利点があります。 むしろ、コラボレーションを改善するためにメインリポジトリに何かを保持できる場合は、トランスパイル/バンドルワークフローを個別に作成する必要はありません。 :)

私はそのスレッドを読み通しましたが、決定の説明ではなく、より多くの発表のように見えます。

残念ながら、設計変更の実現が何年にもわたって複数の議論でゆっくりと進行するため、または単に同じ主題に関する複数のスレッドが何度も作成されるため（このように）、すべての有効な引数を単一のスレッドに固定できるとは限りません。 ）。 共同作業者はノイズとセグメンテーションを最小限に抑えようとしますが、常に可能であるとは限りません。

私の想定では、開発の簡素化がこの方向に進む主な理由ですが、他に何かありますか？

私が目にする最大のものは、冗長なコードを最小限に抑え、再利用可能な実装を実現するサブモジュールを使用およびインポートする機能です。

たとえば、ほとんどのローダーは、ある種のデータ解析構造/クラスを作成する必要があります。これは、 example/jsファイルを再利用できるように、各ローダーが自給自足である必要があるためです。 ただし、非モジュラー制限を完全に削除すると、 DataParserクラスの単一インスタンスを作成し、その標準実装をすべてのローダーにインポートできるため、開発がすぐに簡単になり、冗長コードが削除されます。すべてのローダー。

ええ、良い点です。 レガシーコードが壊れないようにするためだけに、 Passクラス（すべてのFXパスの基本クラス）をEffectComposerに埋め込むなどのダーティハックをすでに行う必要があります。

非常に良い点がありました。

人々を軌道に乗せて最新の状態に保つことは、（そして私自身の経験から）難しい問題のように聞こえます。 これに少し考えてみようと思います。

実際、「three.min.js」を少なくともあと2年間保持することは、必須です。

Babelを使用してES5ビルドを生成することは常に可能です。 それに関して私たちが答える必要がある質問は、これに対する責任が私たちにあるのか、three.jsを使用する開発者にあるのかということです。

サンプルファイルのES5バージョンを作成するのは開発者の責任であるとすでに決定しているので、ビルドファイルに対しても同じことを行うのはおそらく理にかなっています。 私の考えでは、ライブラリ全体でこれを行うのは、間隔を空けるのではなく、1つのリリースで行うのも理にかなっていますが、three.min.jsをもう少し長く保つことも問題ありません。

しかし、何千ものファイルとグーグルのトップドッグがそれに基づいているからです！
例：google.com/search?source=hp&q=webgl+benchmark

これはその検索から私に出てきたトップサイトであり、彼らはR53を使用しているので、この変更が彼らにそれほど悪影響を与えるとは思わない： https ://www.wirple.com/bmark/

ご覧のとおり、旧バージョンのthree.jsは引き続き正常に機能します。 モジュールに移行した後、ES5ファイルを削除する前に、Babelを使用せずにES5ビルドを希望するすべての人に最後のバージョンを使用するように指示できます。 彼らはそのリリースのリポジトリ全体をチェックアウトし、そのバージョンのドキュメントも使用できます。

@looeeeあなたはいくつかの良い点に触れます。 上記のように、ここでES5 three.min.jsとthree.jsを同時に非推奨にすることが理にかなっていることに同意します。 おそらくそれはそれ自身の別個の議論であるべきですか？

いずれにせよ、古い学校のES5スタイルの/js/exampleファイルを生成するために使用できるメインリポジトリにbabelスクリプトを含めることについて合意に達したいと思います。 これは、誰かがこのサポートを提供する責任があるかどうかについては決して関係ありません。 私のように、この機能を必要とする貢献者がいます。 とにかくトランスパイルする必要がある開発者や他の開発者にとっては利点があります。 むしろ、コラボレーションを改善するためにメインリポジトリに何かを保持できる場合は、トランスパイル/バンドルワークフローを個別に作成する必要はありません。

メインリポジトリに1つのファイルを許可して、babelES6からES5へのトランスパイラースクリプトを一緒に処理できるようにすることは、かなりの妥協案だと思います。 本当に問題がありますか？ 寄稿者がメインリポジトリで一緒に必要な機能に取り組むことを許可しますか？

これを行うためのヘルプやリソースを共同作業者に求めているのではなく、これを必要とする人々がメインリポジトリで一緒に作業できるようにすることを求めているだけです。 私がこれについてPRを行い、それが機能する場合、あなたは本当にそれを拒否することに投票しますか？

私がこれのためにPRをして、それがうまくいくなら

つまり、これが開始されるのを見てうれしいです

あなたは本当にそれを拒否することに投票しますか？

リンティングパスに失敗した場合、すべての賭けはオフになります😂

本当に問題がありますか？

はい。リポジトリは非推奨のコーディングパターンを促進するべきではないためです。

はい。リポジトリは非推奨のコーディングパターンを促進するべきではないためです。

three.js + three.min.jsを解任していなければ（ITTのコンセンサスはそれらも解任する必要があることを認めています）、自分で手動で実行する必要のあるbabelスクリプトがある場合は、まだ正式に廃止されていません。熱烈な支持はほとんどありません。 代わりにモジュールを使用するように人々に確実に勧め、babelスクリプトとそれに関するファイルを生成するように警告する必要があることに同意します。 非推奨のコーディングパターンを促進している理由でモジュールを使用できない状況で、寄稿者が一緒にbabelスクリプトで作業できるようにすることに同意しません。 主な理由は、モジュールの使用が実行不可能/非現実的である状況がまだあるためです。 ドキュメントはこの必要性を認めています。 一緒に作業する必要がある人のために、1つのファイルを安全に追加できると思います。

ここでES53.min.jsとthree.jsを同時に非推奨にすることが理にかなっていることに同意します。

つまり、examples / js、three.min.js、three.jsを同時に廃止する必要があります。つまり、複数のリリースに分散するのではなく、1つのリリースですべてのES5コードを削除する必要があります。

@ Mugen87

はい。リポジトリは非推奨のコーディングパターンを促進するべきではないためです。

Windows10でもDOSゲームを実行できます。
そして、それはマイクロソフトが「非推奨のコーディングパターン」を推進しているという意味ではありません。

このプロジェクトで維持されているjsモジュールの例を明確にするために、ノード、npm、またはビルドフレームワークを使用する必要はありません。

実稼働対応のアプリケーションを構築するということは、コードをバンドルすることを意味することを忘れないでください:)

利用可能なRollupのようなバンドルツールに感謝しますが、いくつかの質問を検討する必要があると思います。

• 開発者が本番環境でTHREEを使用したい場合は、これらのバンドルツールの1つも使用する必要があると想定するのは公正ですか？
• examplesフォルダー内のES5/UMDモジュールの更新に依存する他のライブラリのサポートを終了することは公正ですか？

これについての私の個人的な気持ち：

このライブラリは10年前のものです。 ES5/UMDで記述されたexamplesフォルダー内のモジュールに依存する巨大なエコシステムがあります。 エコシステム全体のサポートをやめるのは公平ではないと思います。

モジュールのバンドルパターンがなくてもES6を使用できることを人々は忘れていると思います。 私は毎日ES6を使用していますが、フロントエンドアプリケーションでモジュールバンドルパターンを使用していません。 私は、ビルドツールが必然的に非常にカスタムになり、モジュールのバンドルパターンを組み込むことができないエンタープライズショップで働いてきました。

私たちは何をすべき？

各リリースの後に、特定のディストリビューション用にES6モジュールをES5/UMDモジュールにコンパイルしてみましょう。

はい。リポジトリは非推奨のコーディングパターンを促進するべきではないためです。

人生のほとんどすべてにおいて、古いパターン、技術、およびツールを使用したソリューションは、依然として優れた品質である可能性があります。

例えとして-私の自由な時間には、ポイントチゼルで石を彫ることを楽しんでいます。 道具や技術は動力工具とは異なりますが、最終的には彫刻は高品質のままです。 私はポイントチゼルを使うのが好きで、自分や他の人が満足するものを作るのに必要なスキルを持っているので、個人的にポイントチゼルを使うことを好みました。

ES5/UMDモジュールについても同じように感じます。 私は本当に高品質のコードベースを支持するパターン、テクニック、ツールを見つけることができ、その個人的な好みを行使し続けたいと思っています。

各リリースの後に、特定のディストリビューション用にES6モジュールをES5/UMDモジュールにコンパイルしてみましょう。

私はlooeeeが言ったことに同意します。

仮定するのは公正ですか[...]

何？ 私たちが好むアプローチについて話しているのですが、「仮定」は後で起こります。 他の人にモジュールの使用を奨励することを好むようですが、（一部の人々はまだ古いTHREEを望んでいると仮定して）本当にそれを望んでいる人のための経路を提供します。

各リリースの後に、特定のディストリビューション用にES6モジュールをES5/UMDモジュールにコンパイルしてみましょう。

これは誰でも行うことができます。 そのコストは、three.jsメンテナが負担する必要はありません。 @gkjohnsonが上で言ったことを繰り返しますが、 examples/jsとexamples/jsmの両方のディレクトリを維持するためのコストは高くなります。 これを無期限に行うことはできません。ES6モジュールが2つのアプローチの中でより近代的であることは明らかです。 次のコストを考慮してください。

• 自動化の作成と維持
• 自動化が壊れたときのリリースエラーのデバッグ
• すべてのプルリクエストが、生成されたファイルではなく、ソースファイルを更新することを確認します
• 両方のワークフローの使用方法を説明するドキュメントを維持する
• CJSとES6の両方のワークフローを使用しようとしているユーザーからのバグレポートとサポートの質問に答える

その最後のアイテムはおそらく最大です。 このリポジトリですべてのコピーが2つ利用可能である限り、両方とも完全にサポートされていると見なされます。 私たちは定期的に、2つのワークフローを混同したり、ES6モジュールローダーをCJSコアライブラリで使用しようとしたりするユーザーを支援することに時間を費やしていますが、これは複雑な方法で失敗します。

問題を簡単に言い換えることができます。すべての例（重要ですが、three.jsライブラリのオプション部分）は、現在、モジュール構文をまったく使用していません。 UMDでも、CommonJSでも、ES6モジュールでもありません。 THREEグローバル名前空間にパッチを適用するだけです。 代わりにES6インポート/エクスポート構文を使用してそれを更新したいと思います。この変更が計画されているという多くの早期警告がありました。

ES5/UMDで記述されたexamplesフォルダー内のモジュールに依存する巨大なエコシステムがあります。 エコシステム全体のサポートをやめるのは公平ではないと思います。

three.jsエコシステムのすべてがグローバルなTHREE.*名前空間に依存しているため、インポート/エクスポート構文を使用したり、ES5にトランスパイルしたりするために更新できなかったと言うのは公平ではないと思います。バンドラーを使用します。 ここにはいくつかの回避策があります。ユーザーと協力して、ユーザーに適したオプションを見つけるお手伝いをさせていただきます。

examples/jsディレクトリとexamples/jsmディレクトリの両方を維持するためのコストは高くなります。

これについてもう少し掘り下げたいと思います。 私はフロントエンドアプリケーション用に多くのカスタムツールとビルド自動化スクリプトを作成しましたが、できる限りのお手伝いをさせていただきます。

自動化の作成と維持
自動化が壊れたときのリリースエラーのデバッグ

維持税についてもう少し理解するのを手伝ってください。これは3つのコードベースに固有のものですか？ 私の経験では、このタイプのコードは通常、最も寿命が長く、最小限のメンテナンスで済みます。 これらは、一度作成したスクリプトであり、長期間にわたって再度表示することはありません。

すべてのプルリクエストが、生成されたファイルではなく、ソースファイルを更新することを確認します

おそらく、小さなスクリプトまたはテストがリリースワークフローでこれに役立つ可能性があります。

両方のワークフローの使用方法を説明するドキュメントを維持する

また、グローバル名前空間のドキュメントを削除することにも投票します。 2つのワークフローのドキュメントをサポートするのはばかげていると思います。 これは悪いことではありません。 さまざまなコンテキストのコードをバンドルするほとんどのライブラリ、UMD / ES6モジュールには、1セットのドキュメントしかありません。

CJSとES6の両方のワークフローを使用しようとしているユーザーからのバグレポートとサポートの質問に答えます。

このようなものに関連する問題の量は、THREEの人気の大きさに比例していると思います。 あなたと私は、StackOverflowでこれらのタイプの問題を常に見ています。 2つのワークフローを区別できないユーザーは、ライブラリに触発された新しいプログラマーである可能性が高く、プログラミングの基本を一般的に学ぼうとしているだけです。

目標が2つのワークフロー間の混乱に特に関連する問題の量を減らすことである場合、ES5コードを削除することはおそらくそれを助けるでしょう-しかし、全体的な問題の量が変わるとは思えません。 新しいプログラマーは、ライブラリに関連している場合もそうでない場合もある次の質問に常に立ち往生します。

全体的に問題の量を減らす方法は？

本当の目標が問題の量を全体的に減らすことである場合、おそらくより厳格な問題ポリシーがそれを助けることができます。 すでにHelp (please use the forum)のようなタグを使用して、これで素晴らしい仕事をしているのを見ますが、おそらくこれらのタイプのものがもっと必要です。

より一般的には、3人の寄稿者が現在総量に圧倒されていると感じているかどうかを話し合い、調査することをいとわないいくつかのタイプの問題を調査するのが最善かもしれません。

カップルのアイデア：

• これを書いている時点で、 suggestionsとenhancementsには（271）の未解決の問題があります。 これらのラベルは多くのノイズを生成するようです。 たぶん、PRの準備をする/実際の提案として合格したチェックだけを取ります。 Insta-他のすべてを閉じて、 Discussion (please use the forum)としてマークします。

• これを書いている時点で、 loadersには（61）の未解決の問題があります。 このラベルも多くのノイズを発生させるようです。 suggestionsとenhancementsに関連するこのラベル、または不十分な形式のバグレポートに多くの問題があります。 たぶん、整形式のバグレポートとPRの準備ができている/提案のために渡されたチェックだけを取ります。 インスタ-他のすべてを閉じて、それに応じてマークを付けます。

three.jsエコシステムのすべてがグローバルTHREE。*名前空間に依存しているため、インポート/エクスポート構文を使用したり、ES5にトランスパイルしたり、バンドラー。

私は何でも更新できることに同意しますが、持続可能な方法でこれらのユーザーをサポートし続けるために少しの作業を行う方法を見つけることができれば、@Bug-Reaperに同意します。

むしろ、コラボレーションを改善するためにメインリポジトリに何かを保持できる場合は、トランスパイル/バンドルワークフローを個別に作成する必要はありません。

これらのユーザーをまとめて、アプリケーション/ライブラリのアップグレード、システムの構築、およびドキュメントの作成にかかる時間を大幅に節約できます。

これについてもう少し掘り下げたいと思います。 私はフロントエンドアプリケーション用に多くのカスタムツールとビルド自動化スクリプトを作成しましたが、できる限りのお手伝いをさせていただきます。

良い。

全体的に問題の量を減らす方法は？

これを軌道に乗せてください。 別のスレッドでさらに議論できてうれしいです。 それは私の以前のコメントにいくらか関連しています。

私は@Bug-Reaperの発言に同意します：

むしろ、私たち全員がトランスパイル/バンドルワークフローを作成していないことを望みます[...]

私たちは皆これに同意すると思います。

賛否両論を共有してくれてありがとう。 情報に基づいた決定を行っていることを確認するために、これらを共有することは常に良いことです。

これは私が今年いくつかの頭脳サイクルを費やしてきたことであり、ブラウザベンダーに優先順位について尋ねたことさえあるので、事前に計画を立てることができました。

ES6モジュールは将来のものであることに同意しますが、インポートマップなしでES6モジュールを使用して開発すると、大きな頭痛の種となり、フローが完全に中断する可能性があります。 examples/jsを廃止することを決定したとき、インポートマップの牽引力が高まることを期待していましたが、現在、ブラウザーの優先事項ではないようです。

このため、ブラウザがインポートマップを実装するまで、 examples/jsフォルダの非推奨を一時停止することにしました。 最初の立方体をレンダリングするために、初心者にポリフィルやバンドラーについて学ぶように強制するのは嫌です。

@Bug-Reaperと同じ結論に達しました。 今日は、 examples/jsmファイルからexamples/jsを作成するスクリプトの作成を検討しています。

@mrdoob

ブラウザがインポートマップを実装するまで、examples/jsフォルダの非推奨を一時停止することにしました。
@Bug-Reaperと同じ結論に達しました。 今日は、examples/jsmファイルからexamples/jsをビルドするスクリプトの作成を検討しています。

賢明な決断。
👍

@mrdoobもちろん私はあなたの決定を受け入れますが、それは逃した機会だと思います。 遅かれ早かれ、開発者はグローバルスクリプトから離れる必要があります。 そして、私はImport Mapsがここで大きな違いを生むとは思わない。 ユーザーをより優れた将来性のあるワークフローに「強制」する代わりに、グローバルスクリプトを引き続き使用できるようにします。 2020年。

そして、私はImport Mapsがここで大きな違いを生むとは思わない。

先日、誰かがこれをしているのを見ました：

<script src="js/three.js"></script>
<script src="https://cdn.rawgit.com/mrdoob/three.js/master/examples/js/loaders/GLTFLoader.js"></script>
<script type="module" src="js/main.js"></script>

そして、 main.jsの中で、彼らはこれを行っていました：

import {OrbitControls} from "https://threejsfundamentals.org/threejs/resources/threejs/r119/examples/jsm/controls/OrbitControls.js";

そして、実際に機能しました...😐

ユーザーが正しいことをすることを期待することはできません。ユーザーは学習し、何かがうまくいくまで物事を試みています。 課題は、彼らが気付かないうちに正しいことをするのに役立つデザインを見つけることです。

マップをインポートしないES6モジュールの問題は、ユーザーが自分のプロジェクトのOrbitControls.jsを/jsフォルダーにコピーして、以前のようにインポートできないことです。 OrbitControls.jsは../../build/three.module.js $を探すため、機能しません。

マップのインポートでは、 OrbitControls.jsはthreeからインポートするだけです。 ユーザーはファイルを好きな場所にコピーしてから、インポートマップのパスを調整できます。

マップをインポートすると、「昔」のようにファイルを簡単にインポートできるようになります。 以前ほど簡単ではありませんが、少なくともユーザーはファイルをインポートするときに順序を気にする必要はありません。 何かに勝つ何かを失う。

マップをインポートすると、インポートが構成可能になり、柔軟性が向上することに同意しました。 ただし、ユーザーはインポートマップを調整する必要があります（したがって、実際に何であるかを理解する必要があります）。

「JSファイルをフォルダーにコピーする」全体が邪悪なアンチパターンだと思うので、新しいユーザーや初心者にCDNインポートを使用するように勧めることでこれを防ぐことができると期待していました（これは開発者にとってもオプションです。何らかの理由でビルドを使用したい）。 適切なアプリは、とにかくビルドツールを使用する必要があります。

私は実際にはアンチパターンとは見なしていません。

それは私がウェブサイトを作ることを学んだ方法です。 .cssファイルを/cssフォルダーに配置し、次に画像を/imgに配置し、 .jsファイルを/jsに配置します。

過去数か月間、私はES6モジュール/ CDNアプローチを使用していくつかの実験を行ってきましたが、ライブラリが私のプロジェクトとは異なるドメインからのものであるとは思えません。

ファイルをコピーしないときに失う大きなことの1つは、ファイルを編集できることです。 examples/js内のファイルは、常にその上に構築できる例であると想定されていました。 プロジェクトでOrbitControls.jsをコピーしても、必要な処理が正確に行われなかった場合は、ローカルファイルであるため、変更するだけで済みます。

これは私が私のプロジェクトをセットアップするために使用した方法です：

<script src="js/libs/three.js"></script>
<script src="js/libs/three/OBJLoader.js"></script>
<script src="js/libs/three/OrbitControls.js"></script>
<script>
    console.log( THREE, THREE.OBJLoader, THREE.OrbitControls );
</script>

インポートマップを使用すると、次のようになります。

<script type="importmap">
{
  "imports": {
    "three": "js/libs/three.module.js",
    "OBJLoader": "js/libs/three/OBJLoader.js",
    "OrbitControls": "js/libs/three/OrbitControls.js"
  }
}
</script>
<script type="module">
    import * as THREE from 'three';
    import { OBJLoader } from 'OBJLoader';
    import { OrbitControls } from 'OrbitControls';

    console.log( THREE, OBJLoader, OrbitControls );
</script>

以前ほどきれいではありませんが、インポートの依存関係/順序を処理し、バンドラーを必要としません。

それでも、バンドルベースの開発を行う人々にはまだ機能します。 実際、アドオンは../../build/three.module.js $ではなくthreeからインポートされるようになったため、より良い結果が得られます。

そして、実際に機能しました...😐

FWIWこれは、実際にはごく一部のケースでのみ機能するようです。 それが機能しない場合、それは非常に紛らわしい方法で失敗し、ビルドプロセスでも発生することを認めたことに関連していくつかの問題が提起されました。 おそらく、初心者が同じファイルを使用するための複数の方法を提供することを心配している場合は、エラーが発生しやすく、混乱を招きます。

接線方向かもしれませんが、コンソールの警告を介してページにthree.jsのコピーが2つ含まれていることを通知する価値があるかもしれません（同じバージョンであっても）。これらを混在させないように注意しないと、問題が発生する可能性があります。 〜Reactは同様の理由でこれを行うと思います〜Reactは実際にはこれをエラーの考えられる原因として指摘しているだけかもしれません。 それは、学習するときに人々をこれらのモダリティの混合から遠ざけるのに最も役立つ可能性があります。

@Bug-Reaperと同じ結論に達しました。 今日は、examples/jsmファイルからexamples/jsをビルドするスクリプトの作成を検討しています。

これが新しい計画である場合は、すべてのモジュールファイルをES6ファイルにビルドする＃15526 /＃15543（現在はプロジェクトから削除されています）の復活を喜んでお手伝いします。 いくつかの例が非常に多くのファイル（たとえば、シェーダーノード）に分散していて、いくつかのモジュールを複数のファイルに分割することに関心がある場合は、ロールアップスクリプトをアップグレードして、変換するファイルの明示的なリストを取得する価値があります。と出力。 出力されるファイル間の依存関係も自動的に作成できるはずです。

ファイルをコピーしないときに失う大きなことの1つは、ファイルを編集できることです。

私は同意しますが、私たちが至る所でクラスに参加できるなら、私は次のようなものを望んでいます：

import orbitalcontrols from  orbitalcontrolsURL

class mycontrols extends orbitalcontrols {
// do the edits I care about
}

そして後で

let controls = new myorbitalcontrols

ファイルをコピーしないときに失う大きなことの1つは、ファイルを編集できることです。

私は同意しますが、私たちが至る所でクラスに参加できるなら、私は次のようなものを望んでいます：

orbitalcontrolsURLからorbitalcontrolsをインポートします

クラスmycontrolsはorbitalcontrolsを拡張します{
//気になる編集を行います
}

そして後で

コントロール=新しいmyorbitalcontrolsをしましょう

親の「クラス」が単純なjs関数であっても、すでにそれを行うことができます。

実際に機能しているコード（デバッガーのクイックテストで）：

Promise.all([
    import('https://unpkg.com/three/build/three.module.js')
        .then( mod=> [mod.Camera, mod.WebGLRenderer] ),
    import('https://unpkg.com/three/examples/jsm/controls/OrbitControls.js')
        .then( mod=> mod.OrbitControls )
])
.then( ([
    [ Camera, WebGLRenderer ],
    OrbitControls
])=> new ( class extends OrbitControls {} )( new Camera, (new WebGLRenderer).domElement )
)
.then( console.log )

...またはより単純な構文：

(async function() {

let { Camera, WebGLRenderer } = await import('https://unpkg.com/three/build/three.module.js')
,   { OrbitControls } = await import('https://unpkg.com/three/examples/jsm/controls/OrbitControls.js')

class Con extends OrbitControls { }

let my = new Con( new Camera, (new WebGLRenderer).domElement )
console.log( my )

})()

そのaynom関数と非同期/待機の約束を心配することは別として、クール

class mycontrols extend orbitalcontrols {
 // do the edits I care about
 }

理想的には、これは、変更を加えるときに元のファイルを編集するようにユーザーに指示するのではなく、宣伝する必要のあるパターンです。 ただし、例は拡張性を念頭に置いて作成されていないため、達成できることには大きな制限があります。 私の経験では、元の例全体を拡張クラスのコンストラクターにコピーして機能させる必要があるため、 extendを使用しても意味がありません。

たとえば、 OrbitControlsに対して最も一般的に要求される変更は、パンを制限することです。 これは、そのスレッドからの@Mugen87のフィドルに示されているように簡単に実行できます。

つまり、 minPanとmaxPanのベクトルを追加し、 controls.updateメソッドでcontrols.targetをクランプします。

OrbitControlsを拡張して、これを実行しました。 拡張クラスを作成することができ、それは正常に機能します。 ただし、変更を加えると問題が明らかになります。 updateメソッドを単純に拡張することはできません。

class OrbitControlsPanLimit extends OrbitControls {
    constructor(object, domElement) {
        super(object, domElement);
    }

    update() {
        super.update();
        console.log('Custom update function');
    }
}

この拡張クラスは機能しますが（グリッチ）、この新しいOrbitControlsPanLimit.updateメソッドは無視されます。 元のOrbitControls.updateメソッドは引き続き使用されます。

コンストラクターで再定義することにより、上書きできます。

class OrbitControlsPanLimit extends OrbitControls {
    constructor(object, domElement) {
        super(object, domElement);

        this.update = () => {
            console.log('Custom update function');
        }
    }
}

ここでsuper.update()を使用できないため、元の更新方​​法全体をコピーするしかありません。 ただし、そのメソッドは、すべてのメソッド間で共有されるOrbitControls内からのこのようなものの多くに依存しています。

    //
    // internals
    //

    var scope = this;

    var changeEvent = { type: 'change' };
    var startEvent = { type: 'start' };
    var endEvent = { type: 'end' };

    var STATE = {
        NONE: - 1,
        ROTATE: 0,
        DOLLY: 1,
        PAN: 2,
        TOUCH_ROTATE: 3,
        TOUCH_PAN: 4,
        TOUCH_DOLLY_PAN: 5,
        TOUCH_DOLLY_ROTATE: 6
    };

    var state = STATE.NONE;

    var EPS = 0.000001;

    // current position in spherical coordinates
    var spherical = new THREE.Spherical();
    var sphericalDelta = new THREE.Spherical();

    var scale = 1;
    var panOffset = new THREE.Vector3();
    var zoomChanged = false;

    var rotateStart = new THREE.Vector2();
    var rotateEnd = new THREE.Vector2();
    var rotateDelta = new THREE.Vector2();

    var panStart = new THREE.Vector2();
    var panEnd = new THREE.Vector2();
    var panDelta = new THREE.Vector2();

    var dollyStart = new THREE.Vector2();
    var dollyEnd = new THREE.Vector2();
    var dollyDelta = new THREE.Vector2();

最終的には、元のOrbitControlsのほぼ全体をOrbitControlsPanLimitコンストラクターにコピーする必要があり、クラスを拡張する目的が失われます。 コントロールを拡張性を念頭に置いてクラスとして記述しない限り、それを拡張することは実行可能ではないと思います。

チャイムをしてくれてありがとう@looeee 。 私は自分の努力の中で簡単な解決策を逃したのではないかと思っていましたが、あなたがそれについて言及したので、それは私が自分自身に立ち上がったところです。

理想的には、これは、変更を加えるときに元のファイルを編集するようにユーザーに指示するのではなく、宣伝する必要のあるパターンです。

注意してください、それは継承対構成の議論に向かって密接に踏み込んでいます。

理想的には、図書館はパターンを宣伝するべきではありません。 それはその機能とそれがあなたの問題を解決することをどのように目指しているかを宣伝するべきです。

また、開発者のワークフロー、スタック、ビルドシステム、ユースケースを想定するべきではありません。 優れたライブラリは、そのコミュニティの多くの複雑なニーズに可能な限り対応しています。

今日の新しいものは明日古いものであり、パターンは行き来します。 その場合の唯一の不変は、可能な限り多くの下位互換性を維持するために、途中で多くのユースケースを強力にサポートするソフトウェアです。

Windows10でもDOSゲームを実行できます。

継承と構成の議論

いいえ、お願いします。 この「議論」の解決策は、仕事に最適なツールを使用することです。 継承、構成、機能、テスト駆動の場所があります...あなたはそれに名前を付けます。

他の開発者（使用、再利用、変更）がどのようにthree.jsを使用するかについて話しているので、jsブラウザー機能の外に出ることなく、すぐに理解して使用できるパターンを宣伝することは有効です。

宣伝することは、別のスタイルを使用できないことを意味するものではありません。

可能な限り下位互換性

はいといいえ。

それはその機能とそれがあなたの問題を解決することをどのように目指しているかを宣伝するべきです

明確にするために、問題/機能セットは何ですか？

また、開発者のワークフロー、スタック、ビルドシステム、ユースケースを想定するべきではありません

私はほとんど同意します。 threejsのユースケースは現在ブラウザです。 いくつかのローダーがあるという警告は、私が聞いたことから、いくつかのノードアプリケーションに役立ちます。

その場合の唯一の定数は、途中の多くのユースケースに優れたサポートを提供するソフトウェアです。

変化は唯一の定数です。 開発者は好きなツールを使用し、時には他のことをやってみることがあります。

余談として：

それはその機能とそれがあなたの問題を解決することをどのように目指しているかを宣伝するべきです

どちらが先に来ましたか？ 機能、パターン、または問題？
確かにパターンは問題を解決するのに役立ち、それから機能になりました
...それとも、問題を引き起こしたのは機能であり、それを解決するためのパターンを見つけましたか？

どちらが先に来ましたか？ 機能、パターン、または問題？

どちらが先に来ましたか？ 鶏か卵か？
何人かの人々はオンドリを言います...

すべての周りの素晴らしい議論、すべての入力をみんなに感謝します。

ES6のサンプルモジュールをトランスパイルするタスクに最適なバンドラー（ロールアップ、バベル、パーセル、ウェブパックなど）について、皆さんがどう思うかを知りたいと思います。 @gigabloxがここでの経験について言及していると思いますし、他の人もそうしていると思います。

現在のリポジトリには、すでにbabel、rollup、およびいくつかの関連プラグインが含まれています。 私は先に進んで、今夜ハッキングを開始しました。共有する非常に大まかなロールアップ構成スクリプトがあります。

// jsm-transpiler.js
export default [
  {
    input: './examples/jsm/controls/OrbitControls.js',
    output: {
      banner:"//warning this file was generated automatically",
      file: './examples/js/controls/OrbitControls.js',
      name:'OC',
      footer:'THREE["OrbitControls"]=OC.OrbitControls',
      format: 'umd'
    }
  }
];

このロールアップ構成スクリプトは、実際にOrbitControlsモジュールを非モジュール.jsファイルインクルードに変換し、THREE.OribitControlsに適切なコンストラクターを割り当てます。 それはうまくいきました、それはクールです:)！ また、THREE.jsの40k行を出力ファイルにバンドルしましたが、それほどクールではありません。 また、OrbitControlsコンストラクターをTHREEに転送するのに役立つ、OCと呼ばれる中間グローバル変数を宣言することにより、グローバル変数スペースを怠惰に汚染しています。

ロールアップには、私たちの多くの問題に対処できると思ういくつかの本当にクールな機能があるようです。 特に、正しいネストされたモジュールが含まれる/除外されることを確認するためのマッピングおよびその他のコントロール。 ヘッダー/フッター/イントロ/出力プロパティを介して、トランスパイルされたペイロードの前後にコードを挿入する機能。

だまされたロールアップ構成スクリプトを使用して、必要なことを達成できると慎重に楽観視しています。 しかし、多くのバンドラーの違いを調査/理解している人がここに参加できれば素晴らしいと思います。 モジュールがより素晴らしくなり、いくつかのトランスパイルコードが他のコードよりも優れているので、モジュールを処理するにはかなり堅牢なものが必要になります。

これが私の見解です：
https://github.com/mrdoob/three.js/pull/20529

これは、すべてのJSMモジュールを約30秒でJSグローバル名前空間モジュールに変換するpocカスタムビルドスクリプトです。 この方法でかなり成功しました。 より多くのテストが必要ですが、hello worldでGLTFLoaderのようなより複雑なモジュールのいくつかを試しましたが、それは問題ありませんでした。

経験豊富な正規表現ウィザードのヘルプを使用して、PRで詳細を読むことができるいくつかのエッジケースをまとめることができます。

Chromeのインポートマップの出荷意向：
https://groups.google.com/a/chromium.org/g/blink-dev/c/rVX_dJAJ-eI