sosukesuzuki

数多くの Node.js ライブラリの作者として知られる Sindre Sorhus 氏が次のようなツイートをしていた。
<blockquote class="twitter-tweet">Why is `import.meta.url` a string and not a `URL` instance?&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>
これを見て私も理由が気になったので調査してみた。
<h2>先にまとめ</h2>
URL の仕様にそうすべきと書いてあるから。
<h2>普通に考えると？</h2>
まず最初に思いつくであろうものが「<code>import.meta.url</code>はECMAScriptの仕様だが、<code>URL</code>オブジェクトはHTMLの仕様に含まれるため、仕様間のそういった参照はできない」という理由である。
実際 Twitter 上ではそのように考えている人もいた。
しかし、それは誤りである。
<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> はオブジェクトであることくらいしか定められていない。どのようなプロパティが提供されるかは各ホストに委ねられている。
たとえば HTML や Node.js などの主要なホストでは、(ECMAScriptの立場から見れば偶然)同じ <code>import.meta.url</code> というプロパティが実装されているということになる。
つまり、<code>import.meta.url</code> は ECMAScript には含まれていない。
最近では Vite などのモジュールバンドラーが <code>import.meta</code> に独自のプロパティを実装しているが、それも ECMAScript の仕様としてはなんの問題もない。
もちろん、<a href="https://html.spec.whatwg.org/multipage/webappapis.html#hostgetimportmetaproperties">HTML の <code>import.meta.url</code> は HTML の仕様に定めらている。</a>
<h2>実際には</h2>
<a href="https://github.com/tc39/proposal-import-meta">https://github.com/tc39/proposal-import-meta</a> に起票された issue に答えが書いてあった。
<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>
この issue はズバリ「<code>import.meta.url</code> は文字列ではなく <code>URL</code> オブジェクトであるべきでは？」という趣旨のものだ。
それに対して Domenic Denicola 氏が <a href="https://url.spec.whatwg.org/#url-apis-elsewhere">WHATWG の URL の仕様を参照して</a>回答している。
参照された URL の仕様を読むと次のように書かれている。
<blockquote>
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.
</blockquote>
要約すると「<code>URL</code> オブジェクトは URL を操作するためのものなので、標準が URL を公開するときは <code>URL</code> オブジェクトではなく文字列として公開するべきである。」ということである。
つまり、<code>import.meta.url</code> が文字列として提供されている理由は、URL の仕様に「URL を提供するときは <code>URL</code> オブジェクトではなく文字列として提供するべき」と記述されているからということになる。
<h2>最後に</h2>
なぜ URL の仕様にそのような記述があるのか、という根本的な理由はわからなかった。
仕様によれば
<blockquote>
URL objects are meant for URL manipulation.
</blockquote>
とのことなので、単純に用途と異なるからということなのだろうが、直感的には「別に <code>URL</code> オブジェクトとして提供されていてもいいんじゃなかろうか」とも思う。
より詳しい背景を知っている人がいたら教えてほしい。
<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>

この記事では2021年01月24日~27日に開催された TC39 meeting 88th で議題に上がったプロポーザルについて紹介します。
<h2>For Stage 4</h2>
For Stage 4 の提案はありませんでした。
<h2>For Stage 3</h2>
<h3><a href="https://github.com/tc39/proposal-array-from-async/">Array.fromAsync</a></h3>
Stage 3 にはなりませんでした。
<code>Array.fromAsync</code> は次のようにして非同期イテラブルから配列を生成するスタティックメソッドを追加するプロポーザルです。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">async function * asyncGen (n) {
 for (let i = 0; i &#x3C; n; i++)
 yield i * 2;
}
const arr = await Array.fromAsync(asyncGen(4));
</code></pre></div>
<a href="https://github.com/tc39/proposal-array-from-async/issues/19">https://github.com/tc39/proposal-array-from-async/issues/19</a> で指摘された問題のため、Stage 3 にはなりませんでした。
<h2>For Stage 2</h2>
<h3><a href="https://github.com/tc39/proposal-class-brand-check">Class brand checks</a></h3>
Stage 2 にはなりませんでした
Class brand checks は brand check のための新しい構文を導入するプロポーザルです。
brand check は TC39 内で使われる用語で、<a href="https://github.com/tc39/how-we-work/blob/master/terminology.md#brand-check">https://github.com/tc39/how-we-work/blob/master/terminology.md#brand-check</a> で説明されています。
brand check とは、雑に言えば「ある値があるデータ型であることを検証すること」です。たとえば <code>Array.isArray</code> は brand check です(<a href="https://zenn.dev/sosukesuzuki/articles/e0516a3d4c424e"><code>instanceof</code> は厳密ではない</a>ため brand check ではありません)。
以前 brand check の方法の一つである <a href="https://github.com/tc39/proposal-private-fields-in-in">Ergonomic brand checks for private fields</a> についての記事を書いたので興味のある方はそちらもご覧ください。
<div class="hatena-link"><iframe class="hatena-link-frame" src="https://hatenablog-parts.com/embed?url=https://cybozu.github.io/frontend-expert/posts/ergonomic-brand-checks-for-private-fields" style="border: none;"></iframe></div>
Class branc check プロポーザルでは <code>class.hasInstance(x)</code> という新しい Meta Property を追加します。これはクラスの中でのみ使うことができ、引数として渡された値が今いるクラスのインスタンスかどうかをチェックします。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">class Foo {
 static isFoo(o) {
 return class.hasInstance(o);
 }
}

const foo = new Foo();
console.log(Foo.isFoo(foo)); // true

const obj = {};
console.log(Foo.isFoo(obj)); // false
</code></pre></div>
<h2>For Stage 1</h2>
<h3><a href="https://github.com/rbuckton/proposal-enum">enum</a></h3>
Stage 1 にはなりませんでした。
enum は列挙型を実現するためのプロポーザルです。このプロポーザルは 4 年ほど前から存在していましたがまた動き出したようです。
enum プロポーザルでは次のような構文を導入します。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">enum SyntaxKind {
 A,
 B,
 C
}
</code></pre></div>
他のプログラミング言語の enum と構文上は似ています。
しかし細部の仕様について検討すべき事項が多く、今回のミーティングでは Stage 1 に到達することはありませんでした。<a href="https://docs.google.com/presentation/d/14WtGmdWjEYXIXZVWJWpERF98D90_BytceAu7b7DKr5Q/edit#slide=id.g10effb28f4f_0_273">このスライド</a>に詳しくまとまっているので興味のある方はご覧ください。
<h3><a href="https://github.com/tc39/proposal-reversible-string-split">Reversible string split</a></h3>
Stage 1 になりました。
Reversible string split は可逆(Reversible)の文字列分割のための方法を導入するプロポーザルです。
JavaScript では <code>String.prototype.split</code> を使って文字列を分割できます。
<div class="hatena-link"><iframe class="hatena-link-frame" src="https://hatenablog-parts.com/embed?url=https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/String/split" style="border: none;"></iframe></div>
<div class="remark-highlight"><pre class="language-js"><code class="language-js">const splitted = "A,B,C,D,E".split(",");
console.log(splitted); // [ 'A', 'B', 'C', 'D', 'E' ]
</code></pre></div>
<code>String.prototype.split</code> は第2引数として非負の整数を渡すことで、分割する数を制限できます。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">const splitted1 = "A,B,C,D,E".split(",", 1);
console.log(splitted1); // [ 'A' ]

const splitted2 = "A,B,C,D,E".split(",", 2);
console.log(splitted2); // [ 'A', 'B' ]

const splitted3 = "A,B,C,D,E".split(",", 3);
console.log(splitted3); // [ 'A', 'B', 'C' ]
</code></pre></div>
JavaScript 以外のいくつかの言語(Perl、PHP、Ruby、Go、Rust、Java など)では第2引数を受け取った <code>String.prototype.split</code> に相当する機能は、次のように文字列の分割を行います。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">const splitted2 = "A,B,C,D,E".split(",", 2);
console.log(splitted2); // [ 'A', 'B,C,D,E' ]
</code></pre></div>
N-1 回分割され、残りの部分が戻り値の配列の末尾に含まれています(戻り値の配列の要素数が N)。
Reversible string split プロポーザルでは、このような振る舞いを持つ新しいメソッド <code>String.prototype.splitN</code> を導入します。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">const splitted2 = "A,B,C,D,E".splitN(",", 2);
console.log(splitted2); // [ 'A', 'B,C,D,E' ]
</code></pre></div>
このような文字列分割メソッドを使うと、次のようにして分割する前の文字列を取得できます。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">const value = "A,B,C,D,E";
const separator = ",";
const n = 2;
console.log((value.splitN(separator, n).join(separator)) === value); // true
</code></pre></div>
提案の名前に含まれている Reversible というのはこのような可逆性のことを指しているようです。
<h2>Updates</h2>
<h3><a href="https://github.com/tc39/proposal-symbols-as-weakmap-keys">Symbols as WeakMap keys</a></h3>
Symbols as WeakMap keys は Symbol を WeakMap のキーとして使えるようにするためのプロポーザルです。
現在では一部情報が古くなっていますが以前このプロポーザルについて解説する記事を書いたので興味がある方はそちらもご覧ください。
<div class="hatena-link"><iframe class="hatena-link-frame" src="https://hatenablog-parts.com/embed?url=https://sosukesuzuki.dev/posts/symbols-as-weakmap-keys" style="border: none;"></iframe></div>
以前から Symbols as WeakMap keys プロポーザルのモチベーションや基本的な振る舞いについては概ね合意がとれていました。しかし、Well-knwon Symbols やグローバルシンボルレジストリに登録された Symbol (Eternal Symbol と呼ばれている)についてはどのように扱うべきかという点で TC39 メンバー内でも意見が分かれていました。
今回のミーティングで Symbols as WeakMap keys チャンピョングループは、Eternal Symbol を WeakMap のキーとして使おうとするとエラーが throw されるという振る舞いを選択したことを発表しました。それにともなって、<code>WeakMap.isValidKey(x)</code>、<code>WeakSet.isValidValue(x)</code>、<code>WeakRef.isValidTarget(x)</code>、<code>FinalizationRegistry.isValidTarget(x)</code> などのいくつかのスタティックメソッドが追加される可能性があります。
しかし議事録によればまだ TC39 メンバーの中で意見が分かれているため仕様の決定には時間がかかりそうです。
<h2>参考リンク</h2>
<ul>
<li>TC39
<ul>
<li><a href="https://github.com/tc39/agendas/blob/main/2022/01.md">agendas/01.md at main · tc39/agendas</a></li>
<li><a href="https://github.com/tc39/notes/blob/main/meetings/2022-01/jan-24.md">notes/jan-24.md at main · tc39/notes</a></li>
<li><a href="https://github.com/tc39/notes/blob/main/meetings/2022-01/jan-25.md">notes/jan-25.md at main · tc39/notes</a></li>
<li><a href="https://github.com/tc39/notes/blob/main/meetings/2022-01/jan-26.md">notes/jan-26.md at main · tc39/notes</a></li>
<li><a href="https://github.com/tc39/proposal-array-from-async/">Proposal Array.fromAsync</a></li>
<li><a href="https://github.com/tc39/proposal-symbols-as-weakmap-keys">Proposal Symbols as WeakMap keys</a></li>
<li><a href="https://github.com/tc39/proposal-class-brand-check">Proposal <code>class.hasInstance()</code></a></li>
<li><a href="https://github.com/rbuckton/proposal-enum">Proposal enum</a></li>
<li><a href="https://github.com/tc39/proposal-reversible-string-split">Proposal Reversible string split</a></li>
</ul>
</li>
<li>Babel
<ul>
<li><a href="https://github.com/babel/proposals/issues/80">Jan 2022 · Issue #80 · babel/proposals</a></li>
</ul>
</li>
</ul>

2021年7月に行われた TC39 ミーティングで <a href="https://github.com/tc39/proposal-private-fields-in-in">Ergonomic brand checks for Private Fields</a> というプロポーザルが Stage 4 になりました。
このプロポーザルは、ES2022 に含まれる予定です。また、<a href="https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-rc/#private-field-presence-checks">TypeScript 4.5 にも含まれる予定です</a>。
この記事では、Ergonomic brand checks for Private Fields について解説します。
<h2>概要</h2>
Ergonomic brand checks for Private Fields は、<code>in</code> 演算子を使ったプライベートフィールドの有無の判定を可能にするプロポーザルです。
<h3>現在の <code>in</code> 演算子</h3>
<code>in</code> 演算子は、オブジェクトが特定の名前のプロパティを持っているかどうかを判定するための二項演算子です。
左辺にプロパティの名前、右辺にオブジェクトを受け取ります。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">const obj = { prop1: 1 };
console.log("prop1" in obj); // true
</code></pre></div>
<h3>新しい <code>in</code> 演算子</h3>
Ergonomic brand checks for Private Fields では、この <code>in</code> 演算子を拡張し、左辺に Private Identifier を取れるようになります。
Private Identifier は <code>#foo</code> のような形をした特別な識別子で、クラスのプライベートフィールドを表現するのに使われます。
たとえば、次のコードではクラス <code>Foo</code> は、<code>#prop1</code> というプライベートフィールドを持ちます。
このとき <code>#prop1</code> は Private Identifier です。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">class Foo {
 #prop1;
}
</code></pre></div>
拡張された <code>in</code> 演算子では、次のようにしてオブジェクトにプライベートフィールドが含まれるかどうかをチェックできます。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">#prop1 in obj
</code></pre></div>
しかし、プライベートフィールドはプライベートなので上記のコードはそのフィールドを持つクラスの中でのみ使うことができます。
つまり、次のようにクラスの外でプライベートフィールドに対して <code>in</code> を使うとエラーになります。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">class Foo {
 #prop1;
}
console.log(#prop1 in new Foo());
// Uncaught SyntaxError: Private field '#prop1' must be declared in an enclosing class
</code></pre></div>
しかし、次のようなコードはエラーになりません。メソッド <code>foo</code> はクラス <code>Foo</code> の中にあるので、Private Identifier である <code>#foo</code> を <code>in</code> 演算子の左辺として使うことができます。
そして、この <code>foo</code> の中で <code>this</code> は <code>Foo</code> のインスタンスであり、それには当然 <code>#prop1</code> というプライベートプロパティが存在するので、<code>#prop1 in this</code> の結果は <code>true</code> になります。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">class Foo {
 #prop1;
 foo() {
 return #prop1 in this;
 }
}
console.log(new Foo().foo()); // true
</code></pre></div>
<h2>モチベーション</h2>
存在しないプライベートフィールドにアクセスすると、実行時エラーが発生します。
その挙動と try / catch を組み合わせて、次のようにしてオブジェクトのクラスを判定できます。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">class Foo {
 #brand;
 static isFoo(obj) {
 try {
 obj.#brand;
 return true;
 } catch {
 return false;
 }
 }
}
</code></pre></div>
<code>obj.#brand</code> にアクセスしたとき、<code>obj</code> が Foo のインスタンスでない場合、実行時エラーが発生し <code>catch</code> に入り <code>false</code> が返されます。
このようにして、あるオブジェクトが<code>Foo</code>のインスタンスであるかを検証するスタティックメソッドを作れます。
ですが、このパターンは冗長です。<code>in</code> 演算子を使えばもっと短く書けます。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">class Foo {
 #brand;
 static isFoo(obj) {
 return #brand in obj;
 }
}
</code></pre></div>
これが、このプロポーザルの主なモチベーションです。
<a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/instanceof"><code>instanceof</code> 演算子</a>も基本的にはこの目的のために使えます。しかし <code>instanceof</code> 演算子はプロトタイプに依存するので、プロトタイプを書き換えることでその挙動を変更できます。
次の例では、 <code>obj</code> は <code>Foo</code> のインスタンスではありませんが、後からプロトタイプを書き換えているので <code>obj instanceof Foo</code> は <code>true</code> になっています。
<div class="remark-highlight"><pre class="language-js"><code class="language-js">class Foo {}
const foo = new Foo();
const obj = {};
Object.setPrototypeOf(obj, foo);
console.log(obj instanceof Foo); // true
</code></pre></div>
また、<a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Symbol/hasInstance">Symbol.hasInstance</a> を使って <code>instanceof</code> の挙動を変更することも可能です。
なので、より安全にオブジェクトのもとになったクラスを検証したい場合は <code>in</code> 演算子を使うと良いでしょう。
<h2>参考リンク</h2>
<ul>
<li><a href="https://tc39.es/ecma262/#prod-RelationalExpression">https://tc39.es/ecma262/#prod-RelationalExpression</a></li>
<li><a href="https://tc39.es/ecma262/#prod-PrivateIdentifier">https://tc39.es/ecma262/#prod-PrivateIdentifier</a></li>
<li><a href="https://github.com/tc39/proposal-private-fields-in-in">https://github.com/tc39/proposal-private-fields-in-in</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/in">https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/in</a></li>
</ul>

こんにちは、サイボウズフロントエンドエキスパートチームの<a href="https://twitter.com/__sosukesuzuki">@__sosukesuzuki</a>です。
サイボウズには<a href="https://blog.cybozu.io/">Cybozu Inside Out</a>という技術ブログがあります。
それとは別に、この度フロントエンドエキスパートチームとしてウェブサイトを開設することにしました。
この記事では、このウェブサイトを開設することになった経緯と目的、使用した技術について説明します。
<h2>経緯</h2>
フロントエンドエキスパートチームでは、チームでのコミュニケーションの促進を主な目的としてハッカソンを開催することがあります。
(チームでのハッカソンについては<a href="https://blog.cybozu.io/entry/2021/02/25/133039">Cybozu Inside Out に投稿されている記事</a>をご覧ください)
そのようなハッカソンで、フリーテーマの回がありました。
そこで、<a href="https://twitter.com/__sakito__">Sakito</a>さんと<a href="https://twitter.com/b4h0_c4t">BaHo</a>さんと<a href="https://twitter.com/__sosukesuzuki">sosukesuzuki</a>(私)のチームでは、フロントエンドエキスパートチームのウェブサイトを作ってみることにしました。
ハッカソンの期間内に完成することはありませんでしたが、チームとしてウェブサイトを持っていた方が良いということで合意が得られたので、ハッカソン終了後も開発を継続することにしました。
<h2>目的</h2>
フロントエンドエキスパートチームの活動を多くの人に知ってもらうためです。
フロントエンドエキスパートチームでは、日頃から様々なフロントエンド技術の啓蒙活動を行っています。
それらの多くはクローズドな場所で行われています。しかし基本的にその内容はサイボウズ特有のものではなく、一般的に有用な情報です。
そこで、フロントエンドエキスパートチームとしてウェブサイトを開設し、公開できる有用な情報は公開することにしました。
このウェブサイトを通して、フロントエンドエキスパートチームに興味を持ってくれたら嬉しいです。
<h2>技術</h2>
次の要件を満たす技術として、<a href="https://github.com/vercel/next.js">Next.js</a> を採用しました。
<ul>
<li>環境構築が簡単である
<ul>
<li>もともとハッカソンで開発していたので、環境構築に多くの時間を割けないという事情がありました。</li>
</ul>
</li>
<li>SSG の機能を備えている
<ul>
<li>すべてのコンテンツは静的なものと決まっていたので、SSG ができると嬉しい</li>
</ul>
</li>
<li>TypeScript との相性が良い</li>
</ul>
記事は Markdown として管理して Next.js の <code>getStaticProps</code> のタイミングで <a href="https://github.com/remarkjs/remark">remark</a> を使って HTML に変換しています。
また、ブログの機能を持つので、feed の生成と記事ごとの OGP 画像の生成をのためのスクリプトをそれぞれ用意しました。feed 生成スクリプトは、記事データの Markdown からメタデータを取得し、XML ファイルを書き出します。
OGP 画像生成スクリプトは、記事データの Markdown からタイトルを取得し、<a href="https://github.com/puppeteer/puppeteer">Puppeteer</a> で画像を生成します。
ホスティングには GitHub Pages を使っています。GitHub で管理している HTML をホストする先としてはやはり楽です。
実装はすべて <a href="https://github.com/cybozu/frontend-expert">https://github.com/cybozu/frontend-expert</a> で公開しています。
<h2>おわりに</h2>
これから、不定期ではありますが、当サイトにてフロントエンドに関連する情報を発信していく予定です。ぜひ読んでみてくださいね。