<p>数多くの Node.js ライブラリの作者として知られる Sindre Sorhus 氏が次のようなツイートをしていた。</p>
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Why is `import.meta.url` a string and not a `URL` instance?</p>&mdash; Sindre Sorhus 💙💛 (@sindresorhus) <a href="https://twitter.com/sindresorhus/status/1551202763383644161?ref_src=twsrc%5Etfw">July 24, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>これを見て私も理由が気になったので調査してみた。</p>
<h2>先にまとめ</h2>
<p>URL の仕様にそうすべきと書いてあるから。</p>
<h2>普通に考えると？</h2>
<p>まず最初に思いつくであろうものが「<code>import.meta.url</code>はECMAScriptの仕様だが、<code>URL</code>オブジェクトはHTMLの仕様に含まれるため、仕様間のそういった参照はできない」という理由である。</p>
<p>実際 Twitter 上ではそのように考えている人もいた。</p>
<p>しかし、それは誤りである。</p>
<p><a href="https://tc39.es/ecma262/#sec-meta-properties-runtime-semantics-evaluation">ECMAScriptの<code>import.meta</code>の Runtime Semantics</a> を見れば明らかだが、ECMAScript の仕様の範囲内では <code>import.meta</code> はオブジェクトであることくらいしか定められていない。どのようなプロパティが提供されるかは各ホストに委ねられている。</p>
<p>たとえば HTML や Node.js などの主要なホストでは、(ECMAScriptの立場から見れば偶然)同じ <code>import.meta.url</code> というプロパティが実装されているということになる。
つまり、<code>import.meta.url</code> は ECMAScript には含まれていない。</p>
<p>最近では Vite などのモジュールバンドラーが <code>import.meta</code> に独自のプロパティを実装しているが、それも ECMAScript の仕様としてはなんの問題もない。</p>
<p>もちろん、<a href="https://html.spec.whatwg.org/multipage/webappapis.html#hostgetimportmetaproperties">HTML の <code>import.meta.url</code> は HTML の仕様に定めらている。</a></p>
<h2>実際には</h2>
<p><a href="https://github.com/tc39/proposal-import-meta">https://github.com/tc39/proposal-import-meta</a> に起票された issue に答えが書いてあった。</p>
<p><div class="hatena-link"><iframe class="hatena-link-frame" src="https://hatenablog-parts.com/embed?url=https://github.com/tc39/proposal-import-meta/issues/13" style="border: none;"></iframe></div></p>
<p>この issue はズバリ「<code>import.meta.url</code> は文字列ではなく <code>URL</code> オブジェクトであるべきでは？」という趣旨のものだ。</p>
<p>それに対して Domenic Denicola 氏が <a href="https://url.spec.whatwg.org/#url-apis-elsewhere">WHATWG の URL の仕様を参照して</a>回答している。</p>
<p>参照された URL の仕様を読むと次のように書かれている。</p>
<blockquote>
<p>A standard that exposes URLs, should expose the URL as a string (by serializing an internal URL). A standard should not expose a URL using a URL object. URL objects are meant for URL manipulation.</p>
</blockquote>
<p>要約すると「<code>URL</code> オブジェクトは URL を操作するためのものなので、標準が URL を公開するときは <code>URL</code> オブジェクトではなく文字列として公開するべきである。」ということである。</p>
<p>つまり、<code>import.meta.url</code> が文字列として提供されている理由は、<strong>URL の仕様に「URL を提供するときは <code>URL</code> オブジェクトではなく文字列として提供するべき」と記述されているから</strong>ということになる。</p>
<h2>最後に</h2>
<p>なぜ URL の仕様にそのような記述があるのか、という根本的な理由はわからなかった。</p>
<p>仕様によれば</p>
<blockquote>
<p>URL objects are meant for URL manipulation.</p>
</blockquote>
<p>とのことなので、単純に用途と異なるからということなのだろうが、直感的には「別に <code>URL</code> オブジェクトとして提供されていてもいいんじゃなかろうか」とも思う。</p>
<p>より詳しい背景を知っている人がいたら教えてほしい。</p>
<h2>参考リンク</h2>
<ul>
<li>TC39
<ul>
<li><a href="https://github.com/tc39/proposal-import-meta">tc39/proposal-import-meta: import.meta proposal for JavaScript</a></li>
<li><a href="https://github.com/tc39/proposal-import-meta/issues/13">Issues · tc39/proposal-import-meta</a></li>
</ul>
</li>
<li>WHATWG
<ul>
<li><a href="https://url.spec.whatwg.org/">URL Standard</a></li>
<li><a href="https://html.spec.whatwg.org/">HTML Standard</a></li>
</ul>
</li>
</ul>
