Top-level awaitとDual Package Hazard

Node.js Advent Calendar 2019の21日目の記事です。

2019/12/25追記

もともと「Top-level awaitによるESモジュールの非同期化とDual Package Hazard」というタイトルにしていましたが、表現に勇み足な部分があり、ご指摘をいただいたので、少し修正しました。

「TLAによってNode.jsのESMが非同期になった」という表現はおそらく正確ではありません。ESMに関する2017年のNode.jsのドキュメントでは、特に理由は触れずに「ESMのロードは非同期で、それはブラウザの挙動と合致する」と記述されています。ここでいう「ブラウザの挙動」とは、WHATWG Loaderで定められた仕様を指すと考えられます。ECMAScriptの仕様としては、少なくとも2019まではESMが非同期であるとの記述はなさそうなので、ブラウザの仕様に合わせて非同期にしたのかな、という印象を受けます。

ただし、GitHub上での議論を見る限り、ESMのロードを同期的に行えないことに関しては、かなり早い時点（2016年1月）からTLAが要因として指摘されています。また、現在require(esm)の議論のために立っているissueの中でも、今のところほぼTLAをどう扱うか、という議論に終始しています。したがって、少なくとも「TLAがNode.jsにおいてESMの同期的なロードを困難（または不可能）にしている」ということは言ってよいと考えています。

追記おわり。

tl;dr

• Top-level await（TLA）によりESモジュール（ESM）は同期的にロードできない
• このためrequire(esm)できず、Dual Package Hazardが引き起こされる

はじめに

こんにちは。カブクでフロントエンドエンジニアをしている今村です。

この記事はNode.jsのDual Package Hazardに関するものです。そもそもDual Package Hazardとはなんぞやという話は yosuke_furukawaさんが書いてくださったのでここでは割愛しますが、一言で説明するなら、CommonJS（CJS）からもESMからも利用可能なnpmパッケージにはらむ危険性を指します。

以降は読者がDual Package Hazardについての基本的な知識を持っている前提で話をします。

Dual Package Hazardの原因

Dual Package Hazardの原因は、パッケージがCJSのrequire()とESMのimportの両方でロードできるようにするために、別々のエントリーポイントを用意しなければならず、かつそれらのエントリーポイントが同一環境で両方とも使われてしまうことにあります。

CJSとESMの相互運用

CJSとESMは相互に次のいずれかの手段でロード可能です。

CJS -> ESM

• dynamic import（import()）

ESM -> CJS

• default import（named import は不可）
• module.createRequire()により得られるrequire()を使う

もし、CJSがESMをrequire()（require(esm））できていたら、Dual Package Hazardは起こらなかったでしょう。この場合、Dual PackageがCJSとESMのそれぞれのエントリーポイントを用意することは変わりませんが、ESMに対応済みの環境ではそのパッケージがrequire()されようとimportされようと常にESMが使われ、そうでない環境では常にCJSが使われるようにします。そうなれば、1つの環境で同じパッケージのCJS版とESM版の両方が存在してしまう事態は回避できます。

実際のところ、「ESMに対応済みの環境ではそのパッケージがrequire()されようとimportされようと常にESMが使われ、そうでない環境では常にCJSが使われるように」すること自体は、たとえば次のようなpackage.jsonを記述すると可能です（exportsの仕様についてはこちらを参照）。

{
  "main": "./main.cjs",
  "exports": "./main.mjs"
}

しかし、このパッケージをESM対応済みのNode.js環境においてCJSからrequire()すると、Error [ERR_REQUIRE_ESM]: Must use import to load ES Moduleというエラーで失敗してしまいます。

Why not require(esm)?

ではなぜ、require(esm)できないのでしょうか？

CJSは動的、ESMは静的という性質があるので、静的なものから動的なものをロードするのに制約が生じるのは理解できます。制約とはこの場合、ESMからCJSをロードするときはnamed importが（少なくとも現時点では）使えないとことを指します。named importするには対象のモジュールが何をexportしているかが静的に解析できる必要があるためです。

しかし、動的なCJSが静的なESMをロードする際に、require()にが使えないという制約は何によるのでしょうか？

実はCJSとESMには動的か静的かという違い以外にも本質的な違いがあり、require(esm)できない原因はその違いにあります。それは、CJSが同期的にロード可能なのに対し、ESMは同期的にロードできないという点です。といっても、ECMAScript 2019の時点では、このことはECMAScriptの仕様としては記述されていません（私が読んだ限り。間違っていたら教えてください🙏）。Node.jsにおいてESMの同期的なロードを阻害しているのは、TC39でステージ3のTop-level await（TLA）です。

TLAによるESMのロードアルゴリズムの変化

TLAが導入されるとESMのロードが同期的に行えなくなるのは、直感的にもなんとなく理解できると思われますが、ここでは少し詳細に踏み込んで説明しましょう。

参考:

• tc39/proposal-top-level-await
• Top-level await – v8

TLA以前のESMのロードアルゴリズム

ESMではモジュールがその依存グラフの中で、post-order (帰りがけ順)と呼ばれる順序でロードされていきます。この順序では、依存先は依存元より先にロードされ、また依存先はimport文の記述順にロードされていきます。

Wikipediaにあった図（下）を借りて説明すると、A, B, C…を個別のESMと見立てたとき（AがDよりも左にあることは、Fの中でAのimport文がDのimport文より前に書かれていることに対応します）、点線の矢印に沿って進んでいき、矢印がESMの右側の黒丸とぶつかったときにそのモジュールがロードされます。この例では、A, C, E, D, B, H, I, G, Fという順序でロードされることになります。

たとえば、この図のC, D, Eを次のように実装したとします。

// c.mjs
console.log('C');

// d.mjs
import './c.mjs';
import './e.mjs';

console.log('D');

// e.mjs
console.log('E');

この状態でd.mjsを実行すると、

"C" -> "E" -> "D"

という順序で出力されます。

TLA以後のESMのロードアルゴリズム

TLAに対応すると、TLA存在下でモジュールロードの順番が変化します。
c.mjsを次のように書き換えたとします。

// c.mjs
console.log('C1');
// 1秒待機
await new Promise(resolve => setTimeout(resolve, 1000));
console.log('C2');

この場合、出力は

"C1" -> "E" -> (1秒待機) -> "C2" -> "D"

という順序になります。”E”が”C2″よりも先に出力されることに注目してください。

JavaScriptエンジンはTLAに遭遇するとそのモジュールのロードを一時停止し、次のモジュール（e.mjs）のロードに移ります。ただし、TLAのあるモジュールに依存しているモジュール（d.mjs）の本文は、TLAのあるモジュールのロードが完了するまで実行されることはありません。

このようなアルゴリズムにより、モジュールの非同期なロードを可能にしつつ、そのモジュールに依存するモジュールが実行されるときまでには、すべての依存先モジュールのロードが完了している状態を作り出せるのです。

TLA以後のESMのロードアルゴリズム（旧）

ちなみに、TLAの提案当初はこのアルゴリズムはここまで賢くなく、TLAがあるとその場でモジュールのロードが止まり、次のモジュールのロードに移ることはありませんでした。上の例で言うと、

"C1" -> （1秒待機） -> "C2" -> "E" -> "D"

のような出力結果になります。

これだけなら順番が変わっただけに見えますが、もしe.mjsにも1秒待機するようなTLAがあったらどうでしょうか？過去のアルゴリズムでは複数のTLAが順番に処理されてすべてのロードに2秒かかってしまいますが、現在のアルゴリズムなら複数の TLA が並行に走り、ロードにかかる時間はおおむね1秒のままです。

かつて 「TLAはfootgun（追加により弊害がもたらされるような機能）である」と述べたRich Harrisがその後それを撤回したのは、このアルゴリズムの改良があったためです。

動的かつ同期的なロードを要求するrequire()はTLAを含むモジュールをロードできない

TLA導入以後も、依存グラフにTLAが存在するかどうかにかかわらず、ESMでimport foo from 'foo';のような同期的な風味（？）のimport文がそのままでいられるのは、ESMが静的であることに基づいた上記のようなロードアルゴリズムがあるからです。

一方、動的なCJSがコードの中で唐突にrequire(esm)を実行し、同期的にESMをロードすることを要求してきたとしても、Node.jsはそれに応えることができません。

当然ながら、TLAがCJSで利用可能になってしまうと、CJSもrequire()で同期的にロードできなくなってしまいます。したがって、TLAはCJSでは利用できないことになっています。

TLAはやはりfootgunだったのか

このあたりの事情を知ったとき、やはりTLAは（少なくともNode.jsにとっては）footgunだったのではないかという気持ちに少しなりました。

TC39 の TLA のリポジトリを見ると、TLAの必要性について丁寧に説明されており、それを読むと「なるほどなあ」とは思います。しかしそれでも、Dual Package Hazardを前にすると、「TLA さえなければ…」という気持ちがほんのり湧き上がってくるのを抑えられません。

TLA のない世界線では、人々は幸福そうにrequire(esm)しながら、平和に暮らしていたことでしょう。一部の血の気の多い開発者たちは、「top-levelでawaitできないなんて、どうかしてるよ！」なんて悪態をついたかもしれませんが、それでもHazardと呼ばれるほどの事態にはいたらず、楽しくコードを書いていたでしょう。

しかし、現実はこうです。

この殺伐とした世界の中で、私たちはDual Package Hazardに脅かされるたびに、TLAへの憎悪を募らせることになるでしょう。また、今後TLAを書くたびに、それがもたらした代償の大きさを思い出して胸を痛めるのでしょう。

とはいえ、 require(esm)の可能性を模索するissueなど、まだ議論は続いており、将来的にはrequire(esm)が可能になるかもしれません。あるいは、require(esm)以外の何らかの方法で、Dual Package Hazardが解決される可能性もあります。TLAはあるがDual Package Hazardはない、最高の未来を期待して、今は耐え忍びましょう。

謝辞

「require(esm)できればDual Package Hazardは起きないのに、なぜできないのか」という質問は、私が社内の勉強会でNode.jsのESMサポートについて発表した際に同僚から受けたものでした。また、それに対する回答は、その勉強会のあった日にnodejs/helpにissueを立てて得られたものでした。課題を与えてくれた同僚と、親切に答えてくれたNode.jsコミュニティに感謝します。

おわりに

We are hiring!