SystemJS 0.20-ブラウザーモジュールとの組み合わせ

これは、ブラウザのパッケージマネージャーであるJSPMやNodeJSのような素晴らしいツールの主な開発者であるGuy Bedfordによるブログ投稿の翻訳です。そして、ESモジュールをロードするためのポリファイルであるes-module-loaderと呼ばれる彼自身の頭脳に基づいています。 私が理解しているように、著者はこのリリースでSystemJSをほとんど書き直しており、それについてhabrayuzersに読むことは興味深いでしょう。

SystemJS 0.20がリリースされたばかりです -これは完全に再設計され、仕様が修正されていますが、ESモジュールはすでにブラウザに搭載されています 。

SystemJSは当初、jspmプロジェクト用に2013年に開発されましたが、RequireJSは主要なモジュールローダーでした。 並行して、ES6は開発されましたが、ES6モジュールは依然として無形の夢のように思えました。 SystemJSのアイデアはシンプルで説得力がありました。モジュールがブラウザに来るので、ブラウザからいつでもモジュールをロードできるようにする必要があり、非常にシンプルな開発プロセスが得られます。

ESモジュールの出現により、RequireJSは時の試練に耐えられないことが明らかになりました。 ESモジュールローダーの初期の仕様に基づいて独自のローダーを作成することで、モジュールローダーの仕様の操作に関する具体的なフィードバックを得ることができ、最終的に安定したローダーを取得して後で動作させることが可能になりました。

ほぼ4年後、プロジェクトは毎月50万件弱のダウンロードを受け取り始めました。

これは常に不安定な仕様に従っており、互換性を損なう絶え間ない変更を意味していましたが、プロジェクトの目標はこれらすべての変更を追跡することでした。 また、仕様の開発はほとんどがゆっくりであるため、他のほとんどのプロジェクトよりも大幅な変更の頻度がはるかに低いと想定されていました。

基本的に、SystemJS 0.20は調整仕様の次のリリースを表します。

この投稿では、ブラウザモジュールのロード仕様の将来について期待できることを理解できるようにする最近の仕様変更の概要を提供します。SystemJSはまさにその真っthere中です。

仕様の調整

このハードワークの仕様作成者のおかげで、 <script type="module">とdynamic import()構文の道はほぼ明確です。

SystemJSは常にWhatWGブートローダーの仕様に従っていますが、実際はしばらくの間停滞しています。 <script type="module">およびdynamic import()見たものは、WhatWGブートローダーの成果ですが、仕様の小さなフェーズに由来します。 これらの機能は、WhatWGロードマップに常に存在し 、ブートローダー機能を徐々に改良したものでした。

これまでに確認した機能には次のものがあります。

• モジュール式スクリプト ：WhatWG HTML仕様で説明され、Safari PreviewおよびEdge Insiderに実装されています
  
  
• モジュラーワーカー ：現在実装されているWhatWG仕様で説明されています。
  
  
• 動的インポート構文 ：TC39仕様の第3ステージ、現在実装中

WhatWGブートローダー仕様のその他の機能、または現在議論されているものの、将来登場する可能性のある機能には、次のものがあります。

• メタデータのインポート ：現在のモジュールへのパスを取得する機能（NodeJSの__filenameなど）
  
  
• リゾルバーフック ：スクリプトを決定するためのブラウザーメカニズムをインターセプトする機能。 現在、インポート 'jquery'コンストラクトは、WhatWGモジュールロード仕様に準拠するモジュールスクリプトで失敗します。 フックは、ブラウザーに解決を指示する機能を追加できます（「lodash」）->「https://cdn.com/lodash/4.17.4/lodash.js」。 このアプローチの大きな利点の1つはキャッシュです。lodashをインポートするローカルapp.jsは、lodashの更新に関係なくキャッシュできます。
  
  
• レジストリAPI ：モジュールの名前空間のURLマップを解析および変更する機能を提供します。 レジストリで動的に作成されたモジュールを指定できます。 レジストリAPIは、依存関係のメタデータが利用可能な場合、作業環境のホットリロードを有効にすることもできます。
  
  
• インスタンス化フック ：これは、ブートプロセスをインターセプトし、指定されたURLでどのモジュールを返すかを示すことができるフックです。 また、ブートローダーのレガシーモジュールのサポート（AMDまたはCommonJSモジュールをロードする機能）も含まれています。

上記の関数に欠けているのは、フックの正規化、検索、受信、翻訳、およびインスタンス化です。 このオリジナルのキヤノンはもはやリサイクルも変更もされないことが明らかになりました。

SystemJSはこの道に非常に近いので、これらのフックを削除することは、互換性をSystem.fetch設計変更の1つですSystem.fetchまたはSystem.transateをキャッチする方法はなくなりSystem.transate 。 System[System.constructor.resolve]とSystem.instantiate[System.constructor.instantiate]代わりに、2つのフックのみが新しくなりました。

要するに、SystemJS 0.20は、仕様ベースのブラウザーでのリゾルバーフックとレジストリAPIの単純化された仮定に基づいています。 これらのAPIの詳細については、 https：//github.com/ModuleLoader/es-module-loaderでモジュールローダープロジェクトを調べてください 。これらの仕様ソリューションとトレードオフのすべてが注意深く詳細に説明されています 。

NodeJSモジュールとの互換性

NodeJS側は、モジュールパスの採用で大きな進歩を遂げました。 SystemJSモジュールの形式はこれらの領域とほぼ一貫していますが、1つの調整があります。これは、互換性に違反するリリースでの最大の変更の1つです。

この変更は、ESモジュールからCommonJSモジュールをインポートするときに名前付きエクスポートが許可されなくなることです。これはすべてhttps://github.com/nodejs/CTC/pull/60/files#diff-2b572743d67d8a47685ae4bcb9bec651R217で説明されています

つまりimport { name } from 'cjs.js （cjs.jsはCommonJSモジュール） import { name } from 'cjs.jsのimport { name } from 'cjs.jsはサポートされなくなります。代わりにimport cjs from 'cjs.js'; cjs.nameを記述する必要がありimport cjs from 'cjs.js'; cjs.name import cjs from 'cjs.js'; cjs.name 。 それは多くの場所でNodeJSとBabelのユーザーに影響を与える大きなギャップになるので、SystemJSは今このヒットを受けています。

Interopで__esModuleフラグを引き続きサポートし、このような状況で名前付きエクスポートを発生させることができます。

したがって、 cjs.jsモジュールcjs.js次のように記述されている場合：

 exports.__esModule = true; exports.name = function () { ... } 

これにより、 cjs.jsがCommonJSモジュールであっても、 import { name } from 'cjs.js'を取得できるようになりますが、長期的には結果として削除されます。

本番用ビルド

プロジェクトの規模が縮小したため、新しいSystemJSプロダクションビルドは、最適なロードとプロダクションパフォーマンスのために設計されました。

開発環境では、ローダーは不明なモジュールのロードの問題を処理します。 構成に問題があります-まだロードされていないパッケージの構成を取得するにはどうすればよいですか？ このため、SystemJSは、NodeJSに読み込まれるpackage.jsonファイルのように、解像度の一部としてブラウザーのファイルの構成を動的に読み込む機能を含む、本格的な構成管理システムを受け取りました。

これらの開発アメニティをすべて削除すると、生産ビルドがわずか5 KBに削減されます。 このボリュームは、 System.registerおよびSystem.registerDynamicロードを提供し、さらにベースURL、モジュールパス、マップ、コンテキストマップ、バンドル、および依存関係キャッシュのサポートの機能を含みます。

同形ブラウザモジュール-ポリフィルのようなアプローチ

SystemJSは、ブラウザーでサポートされるようになったモジュールのポリフィルを有効にすると同時に、マップ、コンテキストマップ、および依存関係キャッシュの基本機能を引き続きサポートすることを目指しています。

たとえば、ブラウザにESモジュールを提供し、ESモジュールをサポートしたい場合、
同時に、SystemJSローダーは、古い親友ベースのブラウザーで動作します。

System.registerをモジュール形式として使用するため、polyphilバージョンはサポートされているブラウザーでESモジュールの正確な実行セマンティクスをサポートできるため、このアプローチを同形ブラウザーモジュールとSystem.registerます。

SystemJS 0.20ビルドビルドに基づいて、 https：//github.com/guybedford/isomorphic-browser-modulesでデモが作成されました。これは、このESモジュールロードメカニズムがSafariテクノロジープレビューでどのように機能し、ネイティブモジュールがない場合にSystemJSに戻る方法を示していますサポートされています。

モジュール開発アプローチの改善

SystemJSは引き続きこの道を歩み、実稼働環境での読み込みを最適化し、ネイティブモジュールに囲まれたブラウザーでモジュールを操作します。 現時点でのSystemJSの弱点の1つは、開発サーバーから最適化されたプロダクションまでのプロジェクトにツールが不足していることです。

この分野では多くの興味深い作業が残っており、もちろん、ツールのエコシステムへのアイデアと貢献の余地は常にあります。

DotJSとの会議での最新の議論をご覧ください。ESモジュールをサポートするブラウザーのアセンブリ最適化手法について議論しています。

SystemJSの開発をサポートし、投資してくれたすべての人に感謝します。 何らかの形でプロジェクトをサポートしたい場合は、 寄付を含む仕事の余地が常にあります。