Three.js: three.js用のGoogleクロージャーコンパイラ「externs」ファイル？

いいえ、three.jsには外部依存関係がないため、これまでのところ、このようなものは必要ありませんでした。

私は知っていますが、独自のプロジェクトでTHREE.jsをコンパイル可能な環境に統合することも役立ちます。

そのようなファイルはどのように見えますか？ あなたが共有したリンクですでに説明されている場合は申し訳ありませんが、ページが少し圧倒され（テキストが多すぎる）、読む/理解することができません。

@mrdoob 、あなたはそれらの例のいくつかを以下で見つけます：

http://code.google.com/p/closure-compiler/source/browse/#svn％2Ftrunk％2Fexterns

また

http://code.google.com/p/closure-compiler/source/browse/#svn％2Ftrunk％2Fcontrib％2Fexterns

また、以下も重要です。

http://code.google.com/closure/compiler/docs/js-for-compiler.html

コメント/ヘッダー？ それはコードを読みにくくするだろうと思います...

ええ、でもそれはコード全体ではなく、このexternファイルだけのものだと思います。 それは可能ですが、必須ではありません。

http://www.dotnetwise.com/Code/Externs/index.htmlで試してみました。 ただし、Three.jsでは完全には機能しません。 すべての定義が抽出されるわけではありません。

ブログエントリは次のとおりです。

http://blog.dotnetwise.com/2009/11/closure-compiler-externs-extractor.html

this.method = function(){}パターンをサポートしているようですが、プロトタイプはサポートしていません...

@ mrdoob 、

私が理解している限り、高度なオプティマイザーには使用されているクラスのみが含まれていますよね？ 理論的には機能するはずです...機能していませんか？

three.jsで高度な最適化を試みたわけではありませんが、コードを壊すために使用された他のことを覚えています。 一般に、それは「安全」ではありませんでした。デフォルトの単純な最適化では常に機能しますが、高度な場合は機能しないこともあります。

ライブラリとしてコンパイルするとコードが壊れますが、アプリケーション（メソッドが呼び出されるなど）としては機能するはずですよね？

@mrdoobは、コンパイルされた（最適化された）コードでライブラリを使用するには、ライブラリのすべてのクラスとメソッドを宣言するための「externs」ファイルが必要です。 それなしでは機能しません。 しかし、three.jsで動作する別のツールはありますか？ three.jsアプリケーションを難読化（醜く）するために必要です。 1つの候補はhttps://github.com/mishoo/UglifyJSです。 しかし、私はそれを試していません。

Googleクロージャーexternsは、コンパイルされたコードで使用するオブジェクト全体を記述するファイルです。
このファイルがないと、コンパイラは関数名からa（）やb（）のようなものを作成します。

たとえば、これはJQuery用です： http ：

externsがthree.js用であるならそれは素晴らしいでしょう。

私はそれでかっこいいですが、私はそれに取り組むことができません。 他の誰かがこれをステップアップする必要があります。

@ yurikor 、node.jsを使用する場合、node-browserifyとuglify-jsを一緒に使用できます。 そうすれば、何も構築する必要はありません。

@remoeアドバイスありがとうございます。 私はそれを試してみます。

この問題はしばらくの間非アクティブでしたが、誰かが将来この問題に取り組みたい場合に備えて、ここにいくつかの追加情報があります：

私のプロジェクトでは、プロジェクトをコンパイルするのに十分なthreejsエクスポートを含む単純なファイルを作成しましuglifyjsを使用します。

また、クロージャコンパイラがパブリックインターフェイスシンボルの名前を変更しないようにするために、数行のコードを追加する必要がありました（これらの4つの関数は私のライブラリの唯一のパブリック関数です）。 クロージャコンパイラは、 blah.xyzを介してアクセスされるすべてのプロパティの名前を変更しますが、 blah["xyz"]介してアクセスされるプロパティには影響を与えないことに注意してください。

最後に、このクラスをグローバルスコープにエクスポートする必要があることをクロージャコンパイラに通知するために、行window['ColladaLoader2'] = ColladaLoader2 （文字列の使用に注意）が必要でした。

しかし、本番環境ではクロージャーを使用しておらず、バグチェックだけを使用していますか？ わたし
externファイルを維持する価値があるかどうかわからない。 閉鎖を実行するだけ
積極的な最適化がなければ、externファイルは必要ありません
しかし、あなたはまだ私が信じている検証のほとんど、またはおそらくすべてを取得します
検証。 多分あなたは明確にすることができますか？

私の電話から送られました、私の文法と簡潔さのために申し訳ありません。
2013年2月12日午前5時19分、「RobertCarnecky」 [email protected]は次のように書いています。

この問題はしばらくの間非アクティブになっていますが、誰かがしたい場合に備えて
将来この問題に取り組むために、ここにいくつかの追加情報があります：

私のプロジェクトでは、プロジェクトをコンパイルするのに十分なだけのthreejsエクスポートを含む単純なファイルhttps://github.com/crobi/ColladaAnimationCompress/blob/master/threejs-exports.jsを作成しました。 来る
クロージャーを有効にしたので非常に便利な型注釈付き
すべてのタイプをチェックし、コード内のいくつかのバグを見つけるコンパイラ。 私が持っています
このファイルを手動で作成しました。 私は主にバグのためにクロージャコンパイラを使用しています
チェック、実際の縮小化には、それほど強力ではないが安全なものを使用します
uglifyjshttps ：//github.com/mishoo/UglifyJS。

また、クロージャコンパイラがパブリックインターフェイスの名前を変更しないようにするため
シンボル、コードを数行追加する必要がありました
クロージャーコンパイラは、blah.xyzを介してアクセスされるすべてのプロパティの名前を変更します。
ただし、blah ["xyz"]を介してアクセスされるプロパティには触れません。

最後に、 linehttps：//github.com/crobi/ColladaAnimationCompress/blob/366344d3aa5dbbc0a53c47a2c1759b86bb1e0fcd/ColladaLoader2.coffee#L3383 window ['ColladaLoader2']
= ColladaLoader2（文字列の使用に再度注意してください）は、
このクラスをグローバルスコープにエクスポートする必要があるクロージャコンパイラ。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/mrdoob/three.js/issues/341#issuecomment-13426131で表示してください。

私の知る限り、シンプルモードでは検証はまったく行われません。 ローカル変数の名前を変更し、不明なシンボルに遭遇した場合、それがグローバル変数であると想定して、そのままにします。

詳細モードは、強く型付けされた言語のコンパイラのように動作します（型情報が利用可能であると想定）：不明な関数またはプロパティについて警告し、間違った数の引数で関数を呼び出した場合、または文字列パラメータを使用した場合に警告します。数が予想されました。

例として、シンプルモードは次のコードを変換します

function fn() {
    var foo = {}; // local variable, safe to rename this
    foo.bar();    // undefined property, will crash here
}
fn();

警告なしで

function fn(){({}).bar()}fn();

これは明らかに({}).bar()クラッシュします。 詳細モードは次のコードを出力します

({}).a(); // fn() inlined, private member 'bar' renamed to 'a'

それでもクラッシュしますが、コンパイラも警告を出します

Property bar never defined on foo at line 3 character 0.

• 見つかったバグクロージャは、関数名にタイプミスがあったり、x、y、zコンポーネントに3つの別々の数字ではなく1つのTHREE.Vector3をMatrix4.makeTranslationに渡したタイプのバグTHREE.Vector3た。 。
• もし私が完全なテストカバレッジを持っていたら（私はそうではありません）、遅かれ早かれそれらのバグを見つけたでしょう。 ただし、すぐに現れない場合は、デバッグが難しい場合があります。
• threejsが新しいリリースごとに最新のエクスポートファイルを提供した場合（維持するための多大な努力）、クロージャコンパイラはAPIの変更に起因するすべての問題をキャッチします（ Matrix4.makeTranslation ）。
• クロージャコンパイラの設定は、Javaランタイムが必要なため、私には手間がかかりすぎます。 私のライブラリを構築するために必要な他のすべてのツールは、node / javascriptに基づいています。

現在、THREE.jsアプリケーションをクロージャーライブラリと統合するために、クロージャーライブラリexterns.jsファイルを作成しています。 基本的に私たちが見つけようとしているのは：
すべてのTHREE.jsクラスとそれらが実装するプロトタイプメソッドのリストはどこかにありますか？ リストは次のようになります。

THREE.Texture
THREE.Texture.constructor
THREE.Texture.clone
THREE.Texture.dispose
THREE.DataTexture.clone

（等々...）

Ps- Three.jsは素晴らしいですが、適切なjsDocsがあれば、このリストを簡単に抽出できます:)

ここにthree.jsエクスポートの部分的な実装があり

@crobi ：なぜドキュメントコメントを入れたのですか？ それはかなり時間がかかったようで、それが必要かどうかはわかりません...

@taoeffect ：コメントは主にクロージャーコンパイラの詳細モード用です。 強く型付けされたコードが好きです。

@crobi 、ああコメントは強制入力になりますか？ それはちょっとクールです、私はそれがそれをしたとは知りませんでした。

クロージャコンパイラを使用して型エラーをチェックする場合のみ。 typescriptに似ています。 どちらも、注釈付きのJavaScriptをプレーンなJavaScriptに前処理します。 したがって、これはコンパイル時のチェックのみです。

ここでのクロージャーの高度な最適化モードに関するコメントのほとんどは不正確です。

主な問題に対処するには、次のツールを使用して、任意のライブラリのクロージャーexternを自動的に生成できますhttp://www.dotnetwise.com/Code/Externs/

また、単に外部ライブラリとして使用するのではなく、コードへの入力としてthree.jsを使用する場合は、フラグを追加する必要があります。

--language_in=ECMASCRIPT5

あなたはこれについてブログ記事を書くべきです、多分パフォーマンスを取ります
重要な例とそれをGoogleクロージャーを通して実行するかどうかを確認する
優れた最適化を備えたコンパイラが違いを生みます。
-ベン

2014年1月13日月曜日12:31 PM、Rodrigo Formigone <
[email protected]>は次のように書いています：

また、コードへの入力として、代わりにthree.jsを使用することにした場合
外部ライブラリとして使用するだけで、フラグを追加する必要があります

--language_in = ECMASCRIPT5

—
このメールに直接返信するか、Gi tHubhttps：//github.com/mrdoob/three.js/issues/341#issuecomment-32191167で表示してください
。

よろしくお願いします、
ベンヒューストン
音声：613-762-4113 Skype：ben.exocortex Twitter：@exocortexcom
http：//Clara.io-プロフェッショナルグレードのWebGLベースの3Dコンテンツ作成

私はそのような投稿を書くかもしれないと思います。 ただし、明確にするために、Three.jsをクロージャー（externsファイルの有無にかかわらず）で実行する理由は、必ずしもパフォーマンスの最適化のためだけではありません。 クロージャは主に、JavaScriptで保守可能なコード（特に非常に大きなコードベース）を記述できるようにすることを目的としています。 目標は、JavaScriptを「回避」する（GWTまたは他の同様のツールを使用する）のではなく、開発者がJavaScriptを「飼いならす」（ネイティブJSを作成する）のを支援することです。 単にClosureプロジェクトの一部としてThree.jsをコンパイルしようとすると、Three.jsがその標準の一部に準拠していない可能性があるため、コンパイラーが怒鳴る可能性があります（JSDocでは不十分かもしれません）。 --language_inコンパイラフラグを使用すると、現時点でそれが解決されますが、いくつかの警告が表示されます。 単に独自のJSコードをコンパイルしたいが、Three.jsを外部ライブラリとして参照する（したがって、Three.jsのすべてのコードベースを変更せず、最適化しない）場合は、上記のexternsファイルが必要になります。 externsファイルがないと、ClosureはTHREE。*がどこにも宣言されていないなどのコンパイルエラーをスローします。

クロージャプロジェクトでThree.jsを使用する方法と理由を説明するブログ投稿を書くことはできませんが、これが私が見たGoogleクロージャツールに関する最高の紹介プレゼンテーションです:( Google I / O 2011から） https://www.youtube.com/watch?v=M3uWx-fhjUc （長いビデオであることは知っていますが、コンパイラの目的と、さまざまなコンパイルモードが実際に何をするのかが明確になっています。また、説明もあります。 externsファイルが必要な理由）。

こんにちは、私はthree.jsを使用してアプリケーションを開発することを楽しみにしているので、ADVANCED_OPTIMIZATIONSオプションのサポートを望んでいます。

埋め込みアプリケーションがThree.js関数の一部のみを使用する場合、デッドコードの削除は強力に機能します。

現在、three.jsでは、使用目的が「Just require three.min.js！」に限定されているため、すべての関数を開発する必要があります。この古典的なアプローチは理解しやすいですが、このアプローチで記述されたコードの場合、JavaScriptミニマライザーでコードを減らすことができます。サイズは、変数名の縮小（短い変数名には効果的ではありません）、スペースの削除（インデントスペース、タブ、改行にのみ効果的）、およびその他の安価なトリックによってのみ有効です。

「クロージャコンパイラスタイル」コードにADVANCED_OPTIMIZATIONSオプションを使用することで、大部分が大きなライブラリに重みを付ける「不要なコード」全体を削除できます。 Closureライブラリのような

three.jsはすでにオブジェクト指向スタイルで記述されているので、コード全体を「クロージャーコンパイラスタイル」のコードに更新することは（技術的に）難しくないと思います。 私が心配していること...

• クロージャコンパイラスタイルでは、関数ごとに注釈が必要です。 現在、それらのどれもありません。 これまでに開発されたすべての関数に注釈を追加するのにどのくらい時間がかかりますか？
• クロージャコンパイラには厳密な型定義が必要です。 nullや未定義の場合でも、適切に作業する必要があります。 「null-allowed」パラメーター、「undefined-allowed」パラメーターなどを持つ関数では、大変な作業になる可能性があります。
• ADVANCED_OPTIMIZATIONSによってコンパイルされた「フルバージョンのライブラリ」の準備を楽しみにしている場合は、適切なexternsファイルを準備する必要があります。

Hai Schedul Xor、

これは良い考えです。 どのように、小さなスニペットを共有できますか
これはthree.jsに追加する必要がありますか？

に関しては、

ラムスンダールマダヴァン

4時23分PMの火、2014年6月24日には、Schedul Xorの[email protected]
書きました：

こんにちは、three.jsを使用してアプリケーションを開発するのを楽しみにしています。
したがって、ADVANCED_OPTIMIZATIONSオプションのサポートが必要です。

デッドコードの削除は、埋め込みアプリケーションがのみを使用する場合に強力に機能します
Three.js関数の一部。

現在、three.jsではすべての関数を開発する必要があります。
使用目的は「three.min.jsが必要です！」に限定されています。このクラシック
アプローチは理解しやすいですが、このアプローチによって書かれたコードの場合、
JavaScriptミニマライザーは、変数名を縮小することによってのみコードサイズを削減できます
（短い変数名には無効）、スペースの削除（有効のみ
インデントスペース、タブ、改行用）およびその他の安価なトリック。

「クロージャコンパイラスタイル」のADVANCED_OPTIMIZATIONSオプションを使用する
コード、それは主に重みである「不要なコード」全体を削除することができます
大規模なライブラリ。 クロージャーライブラリのようなライブラリ
https://developers.google.com/closure/library/は大きくなりましたが、
ライブラリのユーザーと開発者は、それを知っているので気にしません
ほとんどのコードはコンパイル段階で削除されます。

three.jsはすでにオブジェクト指向スタイルで書かれているので、
コード全体を「クロージャーコンパイラ」に更新することは（技術的に）難しくありません
スタイル付き」コード。私が心配していること...

• クロージャコンパイラスタイルでは、関数ごとに注釈が必要です。
  現在、それらのどれもありません。 注釈を追加するのにどのくらい時間がかかりますか
  これまでに開発されたすべての機能に？
• クロージャコンパイラには厳密な型定義が必要です。 nullでも
  未定義、あなたはそれらのために適切に働くべきです。 それは大変な作業かもしれません
  「null-allowed」パラメータ、「undefined-allowed」を持つ関数
  パラメーター、 ...
• 楽しみにしている場合は、適切なexternsファイルを準備する必要があります
  によってコンパイルされた「フルバージョンのライブラリ」を準備するために
  ADVANCED_OPTIMIZATIONS。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/mrdoob/three.js/issues/341#issuecomment-46957189 。

@ schedule-xor私たちは間違いなくそれについて助けが必要です...コードの注釈は本当に必要ですか、それともexternsで十分ですか？

やあ、

私はこのコミュニティに不慣れです、私はこれらに貢献することに興味があります
変化します。

に関しては、

ラムスンダールマダヴァン

19:23で火、2014年6月24日には、Mr.doob [email protected]は書きました：

@ schedule-xorhttps ：//github.com/schedul-xor私たちは間違いなく助けが必要です
それで...コードの注釈は本当に必要ですか、それともそれで十分ですか
externs？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/mrdoob/three.js/issues/341#issuecomment-46973166 。

高度な最適化には特定のコーディングスタイルが必要であることに注意してください。そうしないと、コードが破損します。 たとえば、three.jsはuniforms["diffuse"]とuniforms.diffuse混合しますが、これはクロージャーの高度な最適化では許可されていません。 ＃3222も参照してください。

どこにでも厳密な型注釈を追加することは膨大な量の作業であり、多くのコメント行を追加します（私のプロジェクトでは、行数が2倍に増加しました）。

他のWebフレームワーク/言語用のexternsファイルがあると便利です。

チュートリアルによると、externは、名前を変更したくない変数を保護するために使用されます。 これは、クロージャコンパイラスタイルのプロジェクトで使用している（クロージャコンパイラスタイルではない）サードパーティライブラリを、積極的な変数の名前変更から保護する場合に使用します。

externsファイルだけが提供されている場合でも、コンパイラがデッドコードをカットしようとするかどうかはわかりません。 すべての関数にアノテーションを書き込むよりも、externsファイルのみを書き込む方がはるかに簡単です...

私の意見では、タイプ定義ファイルとソースコードが異なると、後でexternsファイルを同期するのが難しくなるため、各関数にアノテーションを書き込む方がexternsを書き込むよりも優れています。 各関数の修正にexternsファイルの更新が必要な場合、それがどれほど煩わしいか想像できるかもしれません。 どちらの選択（externsまたは/ ** * /関数へのコメント）には注釈が必要であり、ほとんどの場合、より簡単な方法が優先されます。

three.jsは大規模なプロジェクトであるため、最初にどこで作業する必要があるのか​​疑問に思っています。 簡単にできることから始めたほうがいいでしょう。

ファイルヘッダーを入れて、各関数の関数定義スタイルを変更してみませんか？

THREE.Material = function(){
  :
};
THREE.Material.prototype = {
    constructor: THREE.Material,
    setValues: function ( values1, value2 ) {}
    getValues: function () { return this.a; }
    :
};

↓

goog.provide('THREE.Material'); ← Write goog.provide('package.classname') at the first line

← three empty lines before <strong i="10">@constructor</strong>

/**
 * <strong i="11">@constructor</strong> ← Add <strong i="12">@constructor</strong> annotation to constructor
 */
THREE.Material = function(){
  :
};

← two empty lines before function definition
/**
 * <strong i="13">@param</strong> {!Array.<!string>} values1 Values1 explanation ← values1 is an array of strings. values1 can't be null, and elements inside values1 can't be null.
 * <strong i="14">@param</strong> {!number} value2 Value2 explanation ← value2 is a number.
 */
THREE.Material.prototype.setValue = function(values1, value2){
  goog.asserts.assertArray(values1);
  goog.asserts.assertNumber(value2);
  :
};


/**
 * <strong i="15">@return</strong> {!number} ← This function returns a non-null number.
 */
THREE.Material.prototype.getValue = function(){
  return this.a;
};

すべてのパラメーター型を厳密にし、値型をnull以外に戻す方が簡単です。 これにより、ADVANCED_OPTIMIZATIONSコンパイルエラーの受け渡しがはるかに簡単になります。

うーん、コードにたくさんのコメントがあることにまだ満足していません。 代わりに、すべてをTypeScriptのようなものに移植する方が良いのではないかと思うことがあります（Microsoftが所有しているのは残念です）。

Typescriptは、クロージャーよりも強く型付けされたjavascriptの方がはるかに快適です。 これは、適度なサイズのcolladaローダーを最初にクロージャー準拠のjavascriptに、次にtypescriptに書き直した後の私の経験です。 どちらのアプローチも、コンパイル時にバグを見つけるのに役立ちました。 Closureは、私のコードのいくつかの非常に優れた最適化（インライン化、デッドコードの削除）を実行し、null許容型をサポートしています。 一方、大量のコメントは気が散り、IDEサポート（コード補完用）はtypescriptほど良くありませんでした。 さらに、ECMAScript6のようなclassキーワードにより、typescriptでのクラスの記述がはるかに簡単になります。

しかし、それは個人的な意見です。 さらに重要なことは、高度なコンパイルモードでのクロージャを正式にサポートする前に、すべてのプロパティアクセスが一貫していることを確認する必要があるという事実をもう一度強調したいと思います。 externsファイルがあると役に立ちません。積極的に名前を変更/インライン化/削除する必要があるため、エクスポートされない内部オブジェクトに対してプロパティアクセスを一貫させる必要があります。 すべてのクラスとすべての変数に注釈を付けると、一貫性のないプロパティアクセスが検出されますが、three.jsコードベース全体に対してこれを行うには数週間かかります（プロジェクトに注釈を付けるのにかかった時間を推定すると）。

最後に、three.jsのような大きなプロジェクトを他の言語/フレームワーク/コーディングスタイルに移植することは、詳細に議論されるべきものです。

OK、three.jsは膨大であることに同意します。そのため、各関数にアノテーションを追加するには数週間かかる場合があります。 クロージャよりも優れたAltJSが存在する可能性があります。 これについては（他の何かに移植することを楽しみにしている場合）、より深く議論する必要があります。

すみません、待ちきれません。 現在のコミットをフォークして、移植を開始します。

やあ、

この注釈の追加を自動化することは可能ですか？その場合、追加できます
build.pyに追加し、クロージャーの高度な最適化を有効にする直前に追加します。

に関しては、

ラムスンダールマダヴァン

6:05の水、2014年6月25日には、Schedul Xorの[email protected]
書きました：

OK、three.jsが巨大であることに同意するので、それぞれに注釈を追加します
機能には数週間かかる場合があります。 より良いAltJSが存在する可能性があります
閉鎖。 これについて話し合う必要があります（移植を楽しみにしている場合）
他の何か）より深く。

すみません、待ちきれません。 現在のコミットをフォークして、移植を開始します。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/mrdoob/three.js/issues/341#issuecomment-47047966 。

@ ramsundhar20 、私の意見では、

Three.jsには現在、1354個の関数が定義された163個のJavaScriptファイルが含まれています。 はい、それは巨大ですが、それは遠すぎる目標ではありません。

//このトピックが場違いだと怖い...

@ schedule-xor繰り返しますが、私は関数ごとにコメントを付けるのが好きではありません：/

@mrdoob OK、わかりました。

あなたの方針を尊重して、私は私のフォークにのみ機能ごとにコメントを追加したいと思います。 また、プルリクエストは一切行いません。 代わりに、元のthree.jsの変更をクロージャスタイルのフォークに移植します。 どうぞよろしくお願いいたします。

いいですね ：）

ありがとうございました！ 作業を開始します。

クロージャコンパイラで使用するベースのthree.jsexternsファイルは少なくともありますか？ これは、Three.jsソースコードに追加のグーグルスタイルのアノテーションを付ける必要はありません。これは、three.jsを使用する外部app.jsからのリンクを十分にコンパイル可能/難読化するためだけですか？

また、three.js用の高品質で完全なexternファイルにも非常に興味があります。 これが1つですが、完全ではありません。

https://github.com/cljsjs/packages/blob/master/three/resources/cljsjs/three/common/three.ext.js

一つの方法は、これから始めて、使用するものを手動で追加することだと思います。

はい、私の投票を数えます。 高度なモードでコンパイル可能な、100％型指定されたthreejs、または少なくともexternsファイルに最適です。

型推論が改善され、必要なクラッターが少なくなりました。 スコープとエイリアスが適切に配置されていれば、コードはクロージャーライブラリのように詳細に読み取る必要はありません。 クリーンなコードの場合、タイプされたインラインドキュメントを書くことになります。 それらは本当にすべての利点を上回るのに十分悪いですか？

高度なモード+ JS圧縮+タイプベースの最適化である超アグレッシブな設定は、デッドコードを削除するだけでなく、最適化コンパイラが実行できるすべての優れた機能を実行できます。

名前付き定数/列挙型は数字に置き換えられます。 また、コンパイラは定数をトレースし、他の定数を使用して計算を実行し、最後に必要な場所に単純な数値を挿入できます。 もちろん、依存フロー制御はデッドコード除去の対象になります。 結果のアプリケーションにアクティブな呼び出しサイトが1つしかない関数と、圧縮された形式が定義よりも小さくなってしまう関数は、インライン化されます。 名前空間は削除されます。 保護されていない名前はすべて最小限に縮小されます。

JavaScriptではルックアップは比較的高価です。 名前の変更、定数畳み込み、インライン化の組み合わせにより、多くのルックアップと多数の関数呼び出しが削除されます。 さらに、適切なヘッダー（クロージャーライブラリに1つあります）があれば、標準化されたすべてのWebGL定数をレンダラーにベイクできます。

その結果、より小さく、より速く、自己文書化され、自動的にカスタマイズ可能なライブラリが得られます。 コンパイラはまた、より積極的な設定の下でより多くのバグをキャッチします-それはおそらくコードレビューを容易にするでしょう。 最後に大事なことを言い忘れましたが、難読化の効果があります。クライアントコードをカスタマイズされたライブラリと一緒にまとめると、externsファイルによって保存されたシンボルを明らかにするコードよりもはるかに優れた知的財産の盗難に対する保護が提供されます。

上記のブランチが見つかりません。 誰かがまだ型付きバージョンに取り組んでいますか？

@mrdoobメインラインに関する心の変化への希望はありますか？

喜んでお手伝いさせていただきます。

@mrdoobメインラインに関する心の変化への希望はありますか？

現在、私はWebGLRendererリファクタリングに焦点を合わせています😇

定数を変更することができますconstではなくvarために良いサポートしているすべてのWebGLのブラウザhttps://kangax.github.io/compat-table/es6/（const->基本）とJSエンジンはconst最適化を開始しています固定フィールド最適化を使用してグローバル定数を高速化

ただし、興味深いことに、 var代わりにしか機能しないため、私が話しているケースのごく一部にしか適用できません。定数の場合でも同様です。 さらに、JITコンパイラーは定義上急いでいるため、オフラインツールによって実行されるプログラム全体の最適化と当然競合することはできません。 すべてのJSエンジンはコードの構造を尊重する必要があり、コンソールを開いて挿入したプログラムを見つけたり、特定の関数を置き換えたりできると期待されるため、コードを任意にリファクタリングすることはできません。

クロージャーコンパイラのサポートに戻る：私はいくつかの読み取りと実験を行いました。 これが私が見つけたものです：

• 詳細モードを実行するために注釈は必要ありません。
• 注釈を徐々に追加して、最適化レベルを上げることができます。
• ローダーが機能し続けるには注意が必要ですが、それはかなり簡単です。

基本的に3つの異なるユースケースがあります。

1. モデルは、アプリケーションおよびライブラリと一緒に圧縮できます。
2. アプリケーションとライブラリは圧縮されています。 モデルは実行時にロードされます。
3. ライブラリは基本モードでコンパイルされており、詳細モードのアプリはそれを使用したいと考えています。

3つ目は、Three.jsのすべてにexternsファイルが必要であり、IMOのメリットが少なすぎるために多くの作業が必要です。 だから私は最初の2つだけを議論します-とにかく、これらは好ましいものです：

コンパイラが見たとき

anObject['aProperty']

プロパティ名には影響しません（文字列は変更されません）。

anObject.aProperty

一方、 anObjectがコンパイルされるアプリケーションの外部にあることがわかっていない限り、コンパイラは一貫してプロパティの名前を変更できます。 コンパイラは、組み込みまたは明示的に提供された_externs_からこれを認識します。

レシピは次のとおりです。

• ローダーがドット表記を使用してプロパティに一貫してアクセスするようにします。
• 入力を入力し、JSON専用のexternsファイルを書き込み
• そのexternsファイルを使用してコンパイルするだけで、ユースケース2を機能させることができます。
• ユースケース1では、externsファイルを使用せず、代わりにJSONのオブジェクトキーから引用符を削除します。

{
    "camera": {
        "object": {
    // ...

単になります

{
    camera: {
        object: {
    // ...

とても簡単ですね。

ユースケース1は、JSON形式で外部バイナリデータ（生またはwebgl-loaderまたはo3dgcを介して圧縮）を許可する場合にさらに魅力的になります。もちろん、技術的にはクロージャーサポートと完全に直交する別の機能です。

externsファイルは、ファイル形式を文書化した古くなったWikiページを置き換えることもできます:-)。

私はこの問題がかなり長い間閉じられていることを知っています。 しかし、最近、クロージャコンパイラプロジェクト内でthree.jsを使用して同じ問題が発生し、このページにたどり着きました。 .d.ts（typescript宣言ファイル）をクロージャーコンパイラファイルに変換するツールを作成しました。 ツールと優れた記述のDefinitelyTyped / threejs記述子ファイルを使用すると、完全に機能します。
ツール： https ：

お役に立てれば...

@eredoは私を完全に助けてくれました。 私が試した他のすべてのジェネレーターには、three.jsライブラリーのかなりの数のメソッド定義がありませんでした。 ありがとう！

@eredo @Corkleまたは他の誰か、 tsd2cce使い方を教えていただけますか？ 最初の引数は明らかに.d.ts定義ファイルですが、2番目の引数は何ですか？ この問題が発生しています。 https://github.com/eredo/tsd2cce/issues/6

実際、2月のr73 d.tsを使用してもtsd2cceで問題なく動作することがわかりましたが、r73は私には古すぎます。

これを行う適切な方法は、tsickleを使用してd.tsファイルから生成することです。

やあみんな、

後世と皆の利益のために、私はGoogle ClosureCompilerのADVANCED_OPTIMIZATIONSと他のいくつかの調整でライブラリをさらに縮小する私自身の試みについてここに報告することにしました。

高度な最適化をオンにしたThree.min.jsを可能にするextern.jsを作成しました。 完璧から遠いです。

それを作成するために、私はこのスレッドの以前の例に基づいてextern.jsから始めました。 そのexternファイルに含まれていないマングルされたプロパティのために、この方法でコンパイルされたときにライブラリが壊れていました。 クロージャーコンパイラーの--property_renaming_reportオプションを使用して、マングルされたプロパティの完全なリストを取得しました。 これらすべてのプロパティをextern.jsに追加した後、プロパティはマングルされなくなり、出力はSIMPLE_OPTIMIZATIONSと同じになりました。 そこから、extern.jsのセクションを選択的/手動でコメントアウトし、ライブラリが縮小された形式で機能していることを確認しました。

この推測とチェックを自動化して、できるだけ多くのプロパティ名を安全に壊す完璧なextern.jsを取得したいと思います。 THREE.JSの単体テストを使用して、どのマングルされたpropnameが失敗したテストになるかをプログラムで判断することを考えましたが、現在、たとえばphantomjsを使用してコマンドラインから単体テストを実行することはできないようです。 （おそらくWebGLが原因です）？

いずれにせよ、これはより小さな縮小ライブラリへの「進歩」であり、SPAjavascript全体のサイズを抑えるのに役立ちます。

externs.js

package.jsonbuild-closureコマンドを更新しました

また、build-closureコマンドで確認できるように、文字列置換コマンドを使用して、ライブラリからすべてのconsole.warnメッセージとconsole.errorメッセージを削除しました。 これにより、コードの特定のセクションをコメントアウトすることで、これまでに縮小されたlibを約20％縮小しましたが、改善の余地があります。

@mrdoobここで私のメソッドのようなことを行うと、最終的には、そのコンパイラに固有のアノテーションでコードを乱雑にすることなくADVANCED_OPTIMIZATIONSを可能にするextern.jsを提供できます。これは、主な関心事のようです。

@ medmr1すごい！ three.jsライブラリを使用してアプリを1つにまとめてコンパイルしてみましたか？ これにより、理想的にはexternsファイルが不要になります。

いいえ、閉鎖の範囲内ですべてを構築しようとはしていません。 それは問題なく機能するかもしれませんが、プログラムで参照されるいくつかのプロパティのマングリングに関してはまだ問題があると思いますか？ var thing = ShaderLib[ shaderType + "BumpMapFrag"]ようなIEのものしかし、おそらく私は自分自身に多くのトラブルを救うだろうか？

はい、 var thing = ShaderLib[ shaderType + "BumpMapFrag"]ようなものは、高度な最適化で壊れます。 プロパティ参照は静的に分析可能である必要があります。 あなたは次のようなことをすることができます：

function(shaderType) {
  if (shaderType == "a") {
    return ShaderLib.aBumpMapFrag;
  }
  if (shaderType == "b") {
    return ShaderLib.bBumpMapFrag;
  }
...

ほとんどの人はClosureCompilerでアプリをコンパイルせず、公開された縮小バージョンのみを使用するため、正しいexternsファイルを作成することはプロジェクト全体にとって間違いなくより有益です。

externの代わりに、
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#export -export-sometype