Import Maps - Guy Bedfords氏のESNEXT 2020での講演より

原文(投稿日：2020/08/30)へのリンク

動的モジュールローダsystem.jsのコアコントリビュータであり作成者であるGuy Bedford氏は、インポートマップによって可能になるワークフローについて説明した。今年のESNEXTでの彼の講演で、Bedford氏はインポートマップの提案の背景にある動機を紹介しながら歴史的な見方をとり、この機能を最新バージョンのnodeで使用されているパッケージエントリポイントと関連付けた。

Bedford氏は、よく知られていないが、JavaScriptのインポートマップには広範な歴史があることを聴衆に思い出させることから始めた。2009年、ファイルおよびモジュールローダrequire.jsは、ブラウザにマッピングシステムを導入した最初のプロジェクトの1つだった。require.jsは次のように設定できます:

require.config({
  baseUrl: '/',
  paths: {
    'jquery': 'lib/jquery',
    'bootstrap': 'lib/bootstrap'
  }
])

require(['jquery'], function($){
  ...
})

前のコードは、構成されたpathsとbaseUrlで解決される場所から、jqueryパッケージの動的な遅延読み込みを起こす。したがって、require.jsは、今日のブラウザで標準となっている動的インポートと同様の機能を提供した。

2012年に、jamパッケージマネージャは、依存関係を名前で遅延ロードするrequire関数を公開した。Bedford氏は、今日提唱されているアイデアは当時行われていたことの大部分を再現しているため、このプロジェクトには何の牽引力もなかったと嘆いた。2012年にリリースされたbower.jsonファイルを備えたBowerパッケージマネージャも追いついた。2013年にsystem.jsとjspmがリリースされ、require.jsを将来のモジュールとブリッジする方法に焦点を当て、モジュールのマッピングメカニズムも提供した。system.jsでは、ブラウザで実行可能なネイティブモジュールを使用して、循環参照、ライブバインディング、および有効なワークフローを機能していた。

最終的に2018年に、インポートマップのWICG仕様が誕生した。インポートマップはChromeブラウザによって実装され、フラグの背後で使用できた。2019年、Snowpackは開発ワークフローでJavaScriptのインポートマップをネイティブに作成した最初のプロジェクトの1つだった。

Bedford氏は次の年を見てみました。この機能がすべてのブラウザでサポートされると想定して、Bedford氏は<script type="importmap">タグを使用してブラウザに読み込まれるインポートマップ構成ファイルを想定した:

{
  "import": {
    "@babel/core": "lib/babel-core.js",
    "assert": "lib/assert.js",
    "component": "lib/component.js",
    "react": "lib/react.js",
    "react-dom": "lib/react-dom.js",
  }
}

ファイルは手動またはツールによって処理できる。理想的な開発ワークフローでは、開発者はモジュールを名前でインポートでき、指定子を維持する必要はない。

Bedford氏は、export package.jsonプロパティがインポートマップとうまく機能していることを確認している。このフィールドは、Node 14でESモジュールパッケージのエントリポイントを説明するために使用される:

{
  "main": "./main.js",
  "exports": {
    ".": "./main.js",
    "./feature": "./src/submodule.js"
  }
}

前に示したexports構成では、"exports"で定義されたサブパスのみがコンシューマによってインポートできる:

import feature from 'es-module-package/submodule';
// Loads ./node_modules/es-module-package/src/submodule.js

他のサブパスはエラーになるが:

import feature from 'es-module-package/private-module.js';
// Throws ERR_PACKAGE_PATH_NOT_EXPORTED

これにより、開発者は内部モジュール構造から分離されたnodeモジュールの外部インターフェイスを作成できる。この情報は、最適化の目的で、およびインポートマップを自動的に生成するために、IDEで解析および使用できる。Bedford氏は、パッケージのエントリポイント、サブパスのインポート、およびインポートマップがツリーの揺れよりも良い結果につながると主張した:

個別の機能のエクスポートを使用することは、実際にはパッケージのオーサリングとパッケージを使うベストプラクティスです。新しいJavaScriptパッケージを作成する場合は、すべてを1つの大きなファイルにまとめて使用せず、ツリーの揺れに基づいて使用されていないコードを魔法のように削除するのではなく、実際には機能を個別のモジュールとしてインポートする方がはるかに優れています。
コンパイラとバンドルが常に副作用の発生を確実に検出できるとは限らないため、これは優れています[実際に安全に使用されているよりも多くのコードが含まれている可能性があります]。

Bedford氏の講演はオンラインで利用でき、コードサンプルと追加の技術詳細が多く含まれている。ESNEXTは、今後5年間にJavaScriptにもたらされる大きな変化に対処する新しい会議（Covid-19により2020年7月にリモートで実施）である。