2021年11月4日
ClojureScriptチーム
ClojureScriptの新しいリリースを発表できることを嬉しく思います。ClojureScriptの既存ユーザーの方は、以下のリリースノートをよくお読みください。
依存関係によっては既に読み込まれている可能性があるため、Google Closure Libraryの名前空間がグローバルにアクセスできるとはもはや想定すべきではありません。Google Closure Libraryの名前空間を適切に使用するには、常に明示的なrequireが必要です。
一部のClojureScriptライブラリは、cljs.coreがgoog.objectを読み込んだため、goog.object/getのように必要なrequireなしで直接そのような定義を参照しても安全であると想定しています。このパターンはマクロの記述において、ユーザーがrequireを省略できるようにするため有用です。しかし、これは現在アンチパターンであり、失敗します。
Googleは、goog.provideのようにグローバルにエクスポートしないgoog.module形式に様々な名前空間を徐々に変換しています。将来に備えるため、ClojureScriptはClosureのガイドラインに従って常にgoog.moduleを読み込みます。Closure Libraryはいつでも任意の名前空間をgoog.moduleに変換し、その名前空間のグローバル定義のサポートを単に削除する可能性があるためです。
最も一般的なケースへの移行を容易にするために、ClojureScriptには古い動作を復元する新しいコンパイラフラグ:global-goog-object&arrayが用意されています。
上記のガイダンスはClojureScriptライブラリには適用されないことに注意してください。その理由を理解するために、関連するいくつかの質問に簡単に答えます。
goog.moduleを使用しますか？いいえ。ClojureスタイルのREPL駆動開発は、元のGoogle Closure名前空間の規約によって最適にサポートされています。名前空間をネストされたJavaScriptオブジェクトとして表現することで、Clojureのvarに意味的に近い遅延バインド環境を効果的に得ることができ、高度に対話的な開発ワークフローが可能になります。
ESモジュールと同様に、goog.module形式はREPL駆動開発とは単に互換性がありません。どちらの場合も、モジュールは効果的に関数クロージャであり、正確な再定義は設計の一部ではありません。対話型開発の複雑さとトレードオフは、一般的なJavaScriptの「ホットリロード」ワークフローとClojure開発者が利用できる開発エクスペリエンスを比較すると容易に明らかになります。
ClojureScript 1.10.891の更新の完全なリストについては、変更ログを参照してください。