セキュリティキャンプ24の探査機自作ゼミ参加者である標準偏差さんと、同ゼミの講師であるsksatのTwitter上でのやり取りが、ABIという概念について理解・説明するものとして大変良かったので、本人たちの許可を得た上でブログ記事としてまとめる。ていうか、call命令でスタックだけ使って引数やりとりするのはCISCアーキテクチャ特有だったりする…？ https://t.co/UJhG6ifH9m— 標準偏差 (@HomeKijitora) October 22, 2024 一連のやり取りは、標準偏差さんが「call命令でスタックメモリのみを使って引数を渡すのはCISCアーキテクチャ特有なのか？」という疑問をツイートし、sksatが「それはアーキテクチャがRISCであるかCISCであるかとは関係ない」と回答したことから始まった。以下は主に、sksatの一連のツイートの内容をまとめたものである。ABIという概念そもそも、「関数」というものはソフトウェア（というか各言語）の概念であり、CPUアーキテクチャの側の概念ではない。したがって、「関数の引数」という概念をどのように表現するのかというのも、CPUアーキテクチャ側の関心事ではなく、もっと上のレイヤのソフトウェアの関心事である。たとえば、関数の引数を特定のレジスタに入れるのか、スタックメモリに入れるのか、というのはCPUアーキテクチャの側からすればどうでも良い。もしも自分でコンパイラを自作するなら、関数の引数をどのように表現するのかを自分で決めることもできる。たとえば、第１引数をレジスタに、第２引数をスタックに入れるみたいな変なことをしても問題はない。しかし、呼び出し側と呼び出される側が同じ約束を守っている必要がある。つまり、関数を呼び出す側が、第１引数をレジスタAに、第２引数をスタックに入れるなら、呼び出される関数側は、第１引数をレジスタAから、第２引数をスタックから取り出す必要がある。こういう約束のことをABI(Application Binary Interface)という。関数を呼び出す側と呼び出される側でABIが異なっている場合、意図したとおりには動かない。たとえば、呼び出す側が第１引数をレジスタAに、第２引数をスタックに入れて関数を呼び出したとして、もし呼び出される関数側が第１引数をスタックから、第２引数をレジスタAから取り出した場合、意図したとおりには動かない（第１引数と第２引数を取り違えてしまう）。なので、多くの人々が守ってくれる約束（ABI）が広く共有されていると、色々なバイナリをくっつけることができるようになる。たとえば、異なる言語のコンパイラが同じABIに従っていれば、別の言語の関数を呼び出すことができる。そして、人類は長いことC言語というプログラミング言語を使って様々な資産を作り上げてきた。今でも、普通にアプリケーションを書いたらほぼ必ずlibcに依存することになる。つまり、Cの関数を呼んだり、Cの関数から呼ばれたり、ということは今でも当たり前にありうる。そのためABIは、言語やコンパイラに依らず統一されていてほしい。OSとABIこのように、みんなが同じABIを守っていると、異なる言語（コンパイラ）の間での関数呼び出しができて便利である。しかし、一般的に異なるOS間での関数呼び出しが行われることはあまりないため、OSごとにABIが違っていても困らないケースが多い。したがって、CPUアーキテクチャとABIの組み合わせは一つだけというわけではない。たとえば、CPUアーキテクチャはx86-64であってもABIはMicrosoft x64 ABIであったりSystem V ABIであったりすることがある。関数の引数をどのように表現するのかここで、関数の引数を表すのにレジスタとスタックをどのように使うのか、という話題に戻る。以前はいくつかの観点で今とは状況が異なっていた。たとえば、コンパイラ最適化が十分ではなかった、今ほどCPUやメモリが高速ではなかった、汎用レジスタの数が今よりも少なかった、など。このような状況のもとでは、すべての引数をスタックに入れる方が実装がシンプルで良い、というときもあった。しかし、CPUのレジスタに対する操作というのは高速で、メモリに対するアクセスは（相対的に）とても遅い。さらに、ほとんどの関数は引数の数が少ないという経験則がある。そこで、最初のいくつかの引数をレジスタに、それを超過したらスタックに入れるようになっていった。おわりにこの記事では、標準偏差さんとsksatによる一連のツイートの内容をまとめた。内容は彼らのツイートに基づいているが、この記事の文責はすべて筆者( Sosuke Suzuki )にある。

標準偏差さんとsksatのツイートから学ぶABI(Application Binary Interface)

2024年10月19日に開催されたVueFes Japan 2024で、「次世代フロントエンドクロストーク」というイベントに出演した。このイベントは、Vueの作者であるEvan You、Oxcの作者であるBoshenの二人の海外ゲストに対して、BiomeのCore Contributorであるunvalleyさん、ESLint周りのエコシステムで活躍されているota-meshiさん、そしてPrettierのメンテナーである筆者(sosuke suzuki)が各々の立場から色々とコメントを挟みつつ、今後のフロントエンドツールチェインについて話していく、というものだった。通訳とモデレータはKiakingさんが行っていた。まず雑に感想としては、全体的には貴重な経験[1]だったし、楽しかったと思う。あとKiakingさんが通訳とモデレータという難しい二つの役割を完璧に果たしていて素直にびっくりしてしまった。すごすぎた。ということで全体的には楽しかったしポジティブなのだが、消化不良感がないとは言えない。登壇時の写真、@kazuponさんが撮影したものを許可を得て掲載していますもっと聞きたかったことこのイベントは、割と聴衆のことを意識した設計になっていたと思っていて、登壇者としてはやや物足りなかった。次世代Webカンファレンスなどのように聴衆おいてけぼりで話しまくって良いやつとは勝手がだいぶ違う（当然）。本当はもっとEvanやBoshenに通訳つきで聞きたいことがあった。ということで、まだ記憶があるうちに、聞こうと思っていたことを書いてみようと思う。リモートキャッシュについてまず、リモートキャッシュについて。VercelはTurborepoを持っていて、Turborepoの目玉機能の一つはリモートキャッシュだと思っている。あんまり経験はないけど、大規模プロジェクトだとリモートキャッシュは効くんじゃないかと思っていて、Turborepoがそれをやりたいというのはまあそうだよね、と思っている。 一方で、これはホスティングプラットフォームを持っているVercelだから気軽にできるんじゃないかと思っていて、VoidZeroはそのへんなにか考えてるんですか？というのを聞きたかった。oxcのlinterのメンテナンスについて次に、oxcのlinterの開発方針について。ESLintは、いつからか忘れたけど、新しいルールは新しいECMAScriptの言語機能に関するものだけ受け入れていて、基本的にはコアには新しいルールを追加しない方針になっている。代わりにESLintエコシステムが勝手にやってね～ということだと思う。実際eslint-plugin-unicornとかeslint-plugin-importとかは、JavaScriptに関する機能がほとんどだけど、プラグインとして実現されている。これはOSSのメンテナーという有限リソースの扱い方の問題だと思っている。oxcも、今はまだユーザーが少ないからいいかもしれないけど、ユーザーが増えていったらメンテナンスのコストが増えていくはずで、そうなったときに、そういうエコシステムの構築をどういうふうにやっていきたいとかなにか考えあるんですか？というのを聞きたかった。Rustについて次に、Rustについて。Rust以外にも、C/C++、Zig、Goなど、実行速度が速いプログラミング言語っていくつかあると思うけど、なんでRustなんですか？って聞きたかったけど、これはまあ納得できるから聞かなくて良かったかもしれない。Boshenがどう思っているのかは知らないが、モダンなビルドシステムやパッケージマネージャがほしくなったらまずC/C++は多分しんどくて、oxcみたいに自分でメモリアロケータを書きたいという人たちだったらGoも多分しんどくて[2]、その上で安全なプログラミングとかユーザーが多いとかを考えるとZigがダメで[2:1]、そしたらRustかなあとは思う。Romeについて次に、Romeについて。フロントエンド大統一ツールチェインと聞くと、Romeのことを思い出すけど、RomeとVoidZeroは何が違って、なんで成功できると思っていますか？と聞きたかった。話を聞いていく中で、Viteとoxcという基盤、そしてそれらのコア開発者を抱えているっていうのが一番の違いかな、とは思った。webpackやBabelについて次に、webpackやBabelについて。今多くの人たちはまだwebpackやBabelを使っているはずで、そういう人たちの一部はこれからもwebpackやBabelを使い続けていくのだと思う。それを考えると、webpackやBabelの方をドラスティックに改善していくことは考えられないかな？ということを聞きたかった。けど、どこかでめっちゃ大きな変更を入れたらPython2/3みたいにコミュニティの分断が起こるだけで、それってViteを新しく作るのと何が違うの？って言われると、何も違わないどころか悪化するのかもしれない。おわりと、こんな感じのことを聞きたかった。一部は自分で答えが出ているけど、彼らの言葉で答えを聞きたかったなーとは少し思う。とはいえ、冒頭にもいったとおり登壇も、VueFes Japan 2024全体もとても楽しかったです。関係者の皆さま、本当にお疲れ様でした。このブログを読んでいる皆さんの中に、ふと左を向いたら1mもないくらいの範囲に登壇中のEvan Youがいたという経験をしたことがある人はいるだろか、なんとおれはある。 ↩︎あんまり知らないからてきとう言ってる。しんどくなかったらごめん。 ↩︎ ↩︎

VueFes Japan 2024の「次世代フロントエンドクロストーク」の感想ともっと聞きたかったこと

この記事では、以下のトピックについて解説します。Intl.DurationFormatの概要Intl.DurationFormatの最大値を規定する仕様JavaScriptCoreにおけるIntl.DurationFormatの最大値の実装Intl.DurationFormatの概要Intl.DurationFormatは現在ステージ3のプロポーザルです[1]。このプロポーザルは指定されたロケール情報に応じてdurationを適切にフォーマットするAPIを提供します。durationというのは、つまり経過時間のことです。たとえば、日本語でいえば「3時間46分25秒」のようなものです。これは当然タイムゾーンの考え方を持たないし、Temporal.Instantなどで表現されるExact Time[2]とも異なる概念です。例を示します。const formatted = new Intl.DurationFormat("ja-JP").format({    hours: 3,    minutes: 46,    seconds: 25,});console.log(formatted); // 3 時間 46 分 25 秒他のIntl系のAPIと同じように、コンストラクタの第一引数にロケール識別子を渡し、DurationFormatインスタンスのメソッドのにdurationを表すオブジェクトに渡してやると、フォーマットされた文字列を返します。durationに使える単位は、年(year)、月(months)、週(weeks)、日(days)、時間(hours)、分(minutes)、秒(seconds)、ミリ秒(milliseconds)、マイクロ秒(microseconds)、ナノ秒(nanoseconds)です。詳細なAPIについてはプロポーザルのREADME[1:1]もしくはMDN[3]を参照してください。Intl.DurationFormatの最大値についてIntl.DurationFormatは2023年の10月にステージ3に到達しました。この時点で、durationの最大値を規定する仕様が取り込まれていました[4]。この仕様では、duration内の単位ごとに最大値が規定されています。ちなみにこの動作はTemporal.Durationと一致しています。まず、この仕様では、年、月、週はそれぞれ 2^32 未満でなくてはならないと規定しています。次に、normalizeされた秒が、2^53 - 1 以下でなくてはならないと規定しています。normalizeされた秒というのは、日、時間、分、秒、ミリ秒、マイクロ秒、ナノ秒を、秒に合わせた値のことです。normalizeされた秒は、以下のように計算されます。normalizeされた秒 = 日 x 86,400 + 時間 x 3600 + 分 x 60 + 秒 + ミリ秒 x 10^-3 + マイクロ秒 x 10^-6 + ナノ秒 x 10^-9仕様では、この値が2^53 - 1[5]以下でなければならないと規定されている、ということです。test262の更新Firefoxの貢献者である@anbaによって、この仕様のためのテストを追加するPRがtest262リポジトリに作成されました[6]。このPRはすぐにapproveされたのですが、コンフリクトのためにマージされませんでした。V8のIntl.DurationFormatの実装に関心を持っているGoogleの@FTangと、JSCの実装に関心を持っている筆者が、たびたび催促のために@anbaをメンションしていたのですが、対応されることはありませんでした。ECMA-402のミーティングの議事録[7]によると、このtest262の更新が、Intl.DurationFormatをステージ4に進めるための実質的なブロッカーになってしまっていたようです。最近になっても@anbaからの反応がなかったため、関係するコミットのみをcherry-pickして筆者がPRを作成したところ[8]すぐにマージされました。これによって各処理系でIntl.DurationFormatの最大値を実装できるようになりました[9]。JavaScriptCoreにおけるIntl.DurationFormatの最大値の実装筆者は、このIntl.DurationFormatの最大値を規定する仕様をJavaScriptCoreに実装しました[10]。最大値はIsValidDuartionというabstract operation[11]で規定されています。このabstract operationはdurationの各単位の値を引数として受け取って真偽値を返します。引数の値は事前の処理によって整数であることが保証されています。年、月、週のバリデーションは単純に実装できます。単純にそれぞれの値が2^32より小さいことを確認すれば良いだけです。問題なのは日、時間、分、秒、ミリ秒、マイクロ秒、ナノ秒のバリデーションです。これらの単位の値は、前述した以下の式に従ってnormalizeした値が2^53未満であることを確認する必要があります。normalizeされた秒 = 日 x 86,400 + 時間 x 3600 + 分 x 60 + 秒 + ミリ秒 x 10^-3 + マイクロ秒 x 10^-6 + ナノ秒 x 10^-9JSCではdurationの各単位の値はdoubleで表現されているのですが[12]、この計算を単純にdoubleに対して適用すると丸め誤差が発生してしまい、正確な値を計算できません。そこで、秒を基準とした浮動小数点数として表現するのではなく、ナノ秒を基準とした整数で表現することとにしました。最初はuint64_tを使おうと考えたのですが、値が大きいときにはuint64_tに収まりきらないためWTFのInt128を使って実装しました。https://github.com/tc39/proposal-intl-duration-format ↩︎ ↩︎ようはUnix Timeのこと ↩︎https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DurationFormat ↩︎https://github.com/tc39/proposal-intl-duration-format/pull/173 ↩︎2^53 - 1というのは、Number.MAX_SAFE_INTEGERと同じ値であり、つまりNumber型（double）で正確に表現できる整数の最大値です ↩︎https://github.com/tc39/test262/pull/3988 ↩︎https://github.com/tc39/ecma402/blob/main/meetings/notes-2024-09-26.md#durationformat-for-stage-4 ↩︎https://github.com/tc39/test262/pull/4254 ↩︎実際には、test262にテストがなくても実装はできるが、あったほうが楽に実装できる。特に、おれみたいな仕様読み力に自信がない実装者にとっては... ↩︎https://commits.webkit.org/285131@main ↩︎https://tc39.es/proposal-intl-duration-format/#sec-isvalidduration ↩︎https://github.com/WebKit/WebKit/blob/2e7e9d53c9d0b2143450c9bb95be1d35fa1c09bd/Source/JavaScriptCore/runtime/ISO8601.h#L37-L86 ↩︎

Intl.DurationFormatの最大値を規定する仕様について

正規表現のプロパティエスケープなどの実装のために、JavaScriptエンジンはUCD(=Unicode Character Database)に関する情報を知っている必要がある。WebKitのJSエンジンであるJavaScriptCoreではUCDを ./Source/JavaScriptCore/ucd 配下にファイルとしてそのまま配置している。Unicodeのバージョンが上がるとtest262の方に更新が入るので、それに追従する形でJSエンジンのUCDのバージョンを上げる必要がある。前回 15.1 に上げたときはすべて手動でやったが、手動でやるのは面倒くさいのでスクリプトを書...

JSCのUCDを更新するスクリプト

WebKitのcommitterになった。僕はAppleやIgaliaやSonyの従業員ではなく、完全に趣味である。I'm officially a WebKit (@webkit) committer! Thank you to the JSC reviewers who have been reviewing my patches.— sosuke (@__sosukesuzuki) August 18, 2024 WebKitの開発者のステータスのポリシーは https://webkit.org/commit-and-review-policy/ を参照してほしい。Committerよりも強い権限を持つreviewerという人たちもいる。人のパッチを正式に承認したり拒否したりすることはreviewerにしか出来ない。2024年2月からパッチを投げ始めて、6月の半ばくらいにcommitterとして推薦された。そのあとAppleの社内手続きに二ヶ月くらいかかり、8月半ばに正式にcommitterになった。別にcommitterになることが大きな目標だったというわけではないのだけど、なんだかんだ嬉しく思う。ただ、committerに推薦されてからもう二ヶ月くらい経ってるから新鮮な嬉しさはもうあまりない。Ruby方面から「コミッターになりました」系のブログやツイートが流れてくることがたまにあるが、JavaScript方面からはあんまりないので、まあそういうことができて良かったと思う。一方で、自分の人生を考えたときに「こんなことやってていいのかなあ」と思う。JSCのバグを直したり勉強したりするのはたしかに楽しいのだが、自分の人生にとって得になるとはあまり思えない。しかし楽しいので別にいいのか？うーん、みたいな気持ちだ。別に苦しいとか悲しいとかではないのだが「何やってんだおれ…」みたいな気持ちはずっとある。OSSへの貢献というのはなんとなくエライ感じがするので気持ちがバグりがちだが、自分の場合はただ気持ち良くてダラダラやっているだけなので、SNSやYouTube shortsにほとんどの時間を費やすのと抽象的には同じ構造だと思っている。別に、他人がそういうパソコンばかりの人生を送っていることを否定する気は当然ないのだが、もう少し冷静に時間の使い方を考えても良いのかもしれない。もうちょっと旅行とか行った方が良い。余談だが、とある知人から「お前WebKitたくさんやってるけどちゃんと大学の勉強してる？」という指摘を受けた。僕はPrettierやBabelや労働のやりすぎで留年しているので、ごもっともな指摘である。ということで、僕のことを心配してくれている知人のために現時点での筆者の余暇時間の優先順位を明らかにしておくと、大学の課題とテスト勉強 > WebKit  > 卒業研究 > その他OSSというような感じになっているそんなわけなので、筑波大学情報学群情報科学類の授業の中で最も難しい（と個人的に感じている）授業である微分積分Bの単位を取ることもできた。筑波大学の在学年限は6年で、僕は今年度で最後なので、この調子で頑張りたい。

WebKitのコミッターになった

Prettier 3.3.3 は、文字列リテラルから不要なエスケープを取り除く。以下のように:// Input (3.3.3)const str = "\a";// Output (3.3.3)const str = "a";このエスケープ（\）は、そのままでは文字列リテラルの中に書けない文字を書くために使われる。たとえばダブルクォートを含む文字列をダブルクォートを使って書くときなど（"\""）。この文字列リテラル内の a はそのまま書いたって良いので、全く不要なエスケープである。この動作に関して、テンプレートリテラルに対しても同じことをするべきじゃないか、という旨のissueが作成された[1]。そう、Prettierは文字列リテラル中の不要なエスケープを取り除くが、テンプレートリテラルに対してはそうしない[2]。// Input (3.3.3)const tmp = `\a`;// Output (3.3.3)const tmp = `\a';文字列リテラルとテンプレートリテラルの間で動作に一貫性がない、ということになる。こういうのはできるかぎり一貫していてほしいので、テンプレートリテラル内の不要なエスケープも取り除くように変更しようと考えた[3][4]。しかし、チームで議論した結果、最終的には「そもそも、リテラルから不要なエスケープを取り除くという動作自体、フォーマッタじゃなくてリンターの仕事じゃね？」という結論に至った。つまり、文字列リテラルかテンプレートリテラルかに関わらず不要なエスケープを取り除かない、という方向で一貫性をもたせるということだ。ということで、そのような方向で進めているのでPrettier 3.3.4からはそのようになる[5]。引き続き同じ動作を期待する場合はESLintのno-useless-escapeなどを使ってほしい。どうでもいいけど、こういう変更はセマンティックバージョニングにおけるパッチ・マイナー・メジャーのどれでいれるべきなのかいまだにわからない。めんどくさいからパッチでいれる予定だけど。https://github.com/prettier/prettier/issues/16542 ↩︎ちなみに、タグ付きテンプレートリテラルの場合は一見不要な \ であってもタグ関数からアクセスできるため、不要ではない（ことがある）。 ↩︎https://github.com/prettier/prettier/pull/16562 ↩︎テンプレートリテラルの場合は ${ のエスケープを維持する必要があるので文字列リテラルに対するものとしては若干動作が異なる ↩︎https://github.com/prettier/prettier/pull/16563 ↩︎

文字列リテラルから不要なエスケープを取り除くのってリンターの責務かも

WebAssembly Type Reflection JavaScript APIの一部をWebKitに実装したので紹介します。WebAssembly Type Reflection JavaScript API とはWebAssembly Type Reflection JavaScript APIは、Memory・Table・Global・関数の型に関する情報をJavaScriptから取得するAPIを追加する提案です。https://github.com/WebAssembly/js-types で管理されています。たとえば、MemoryやTableであればサイズの制限、Globalであれば値の型とミュータビリティ、FunctionであればそのシグネチャをJavaScriptから取得できます。この提案は、既存のAPIに対して３つの変更を加えます。1. Memory、Global、Tableに対するtypeメソッドの追加以下の３つの関数が追加されます:WebAssembly.Memory.prototype.typeWebAssembly.Table.prototype.typeWebAssembly.Global.prototype.typeこれらのメソッドを呼び出すことでそれぞれの型の情報を取得できます。以下に具体的な使い方を示します:const memory = new WebAssembly.Memory({ initial: 10, maximum: 100 });console.log(memory.type()); // {"maximum":100,"minimum":10,"shared":false}const table = new WebAssembly.Table({ initial: 10, element: "anyfunc" });console.log(table.type()); // {"minimum":10,"element":"funcref"}const global = new WebAssembly.Global({ value: "i32", mutable: true }, 0);console.log(global.type()); // {"mutable":true,"value":"i32"}2. Module.importsとModule.exportsの返り値の要素のtypeプロパティの追加以下の２つの既存の関数の返り値が変更されます:WebAssembly.Module.importsWebAssembly.Module.exportsこの２つの関数は、WebAssemblyのモジュールのインスタンスを引数にとって、そのモジュールがimportあるいはexportしているそれぞれの値に関する情報を配列として返します。以下に具体的な例を示します:// このwatに対応するバイナリ://   (module//     (import "mod" "fn1" (func $log1 (param i64) (param i32) (result i32)))//   )const buffer = new Uint8Array([0,97,115,109,1,0,0,0,1,7,1,96,2,126,127,1,127,2,11,1,3,109,111,100,3,102,110,49,0,0]);const module = new WebAssembly.Module(buffer);const imported = WebAssembly.Module.imports(module);console.log(imported[0]);// {//   "module":"mod",//   "name":"fn1",//   "kind":"function",//   "type":{"parameters":["i64","i32"],"results":["i32"]}// }この提案以前は、モジュールの名前を表す module、インポートする値の名前を表す name、インポートする値の種類を表す kind という３つのプロパティがありました。この提案は、さらに型の情報を表す type というプロパティを追加します。type プロパティの値は、この例で示したようにインポートした値が関数であればこの例のようにそのシグネチャになります。インポートした値がMemoryやTable、GlobalであればそれぞれWebAssembly.Memory.prototype.type、WebAssembly.Table.prototype.type、WebAssembly.Global.prototype.typeの返り値の型の値になります。3. MemoryとTableのコンストラクタの引数の変更WebAssembly.Memory と WebAssembly.Table のコンストラクタが受け取るオブジェクトのプロパティの名前として、initial の代わりに minimum が使えるようになります。WebKitでの実装このType Reflection JavaScript APIは４年ほど前から存在していて、ChromiumとFirefoxには実装されています。WebKitには１と３は実装されていましたが、2は実装されていませんでした。RubyのWasm周りやSwiftWasmのメンテナーである@kateinoigakukunと話していたときに「Type Reflection JS APIの一部がWebKitにだけなくて困って、polyfil書いたんだよね～～」という話を聞きました[1]。筆者はここ半年くらいWebKitに継続的に貢献していますが、WebAssemblyに関連する部分は全く触ったことがなかったし、そもそもWebAssemblyのことを全く知りませんでした。いずれWebAssemblyもやりたいと思ってはいたのですが、きっかけを上手く見つけられずにいたところだったので、この機会に実装してみることにしました。コードリーディングと実装ここからはWebKitのコードリーディングと具体的な実装の手順の説明になります。WebAssembly.Module.importsとWebAssembly.Module.exportsの返り値の要素に追加するべきであるtypeプロパティが持っている情報は、明らかにモジュールをコンパイルするときにすでにわかっている情報です。なので、引数として渡されるWebAssemblyモジュールインスタンスから取得できると考えました。importsとexportsで考えることはほとんど変わらないので、とりあえずimportsについて説明します。WebKitで、WebAssembly.Module.imports関数の実装に対応するコードは Source/JavaScriptCore/wasm/js/WebAssemblyModuleConstructor.cpp#L202-L234 です。ここでは引数として渡されたモジュールインスタンスを JSWebAssemblyModule 型の変数 module として扱っています。なので、ここではこの module 変数から上手くデータをひっぱってきて返り値の type プロパティにつっこんでやれば良いわけです。さらに、周辺のコードを読むとモジュールに関するデータは module->moduleInformation() で取得できることがわかります。ではどうやって module->moduleInformation() からひっぱってくるべきデータを探すのかということになります。WebAssemblyモジュールのバイナリフォーマットのインポートセクションを解析する部分があり、そこでモジュールのデータをセットしているはずだと考えました。実際、Source/JavaScriptCore/wasm/WasmSectionParser.cpp#L147-L231でモジュールのインポートセクションを解析して、kind に応じて m_info というフィールドに色々とセットしていることがわかりました。module->moduleInformation() は基本的に WasmSectionParser.cpp で作られた m_info を返すだけなので、そこでセットされた情報を WebAssembly.Module.imports の方から読み出せば良いということになります。ということで、module->moduleInformation() からほしいデータを取得してオブジェクトを作成する createTypeReflectionObject という関数を書いて、type プロパティにセットするようにしたら、意図した通りに動作しました。コードは Source/JavaScriptCore/wasm/js/WebAssemblyModuleConstructor.cpp#L104-L200 にあります。ちなみにこの createTypeReflectionObject 関数は WebAssembly.Module.imports と WebAssembly.Module.exports の両方のために使うことを想定して作っています。WebKit でインポートのエントリを表す型は Wasm::Import で、エクスポートのエントリを表す型で Wasm::Export で、それらは異なる型です。WebKitではC++20を使うことができるのでコンセプトという機能を使って、Wasm::ImportとWasm::Exportのどちらかのみを受け付けるようにしてみました。コンセプトって初めて使いましたがTypeScriptみたいで面白いですね。template<typename T>concept IsImportOrExport = std::same_as<T, Wasm::Import> || std::same_as<T, Wasm::Export>;template <IsImportOrExport T>static JSObject* createTypeReflectionObject(JSGlobalObject* globalObject, JSWebAssemblyModule* module, const T& impOrExp){    // ...}Pull Request は https://github.com/WebKit/WebKit/pull/31702 です。Function Referenceとの関係ここに書いたところまでは割とサクッとできたのですが、このあと難しい箇所がありました。Function Referenceという別の提案の方に、Type Reflectionとの相互運用についての言及があります[2]。WebKitはすでにFunction Referenceをフラグ付きでサポートしているので、Type Reflectionを実装するなら、そこを考慮する必要がありました。そのための実装自体は前例があったから簡単だったものの、この提案のことは理解できていないので、もうちょっとちゃんと勉強する必要がありそうです。また、このFunction Referenceで追加された機能を使ったwatを、wabtを使ってwasmにしようとしたら構文エラーが起きてしまいました。どうやらまだFunction Referenceをちゃんとサポートできていないようだったので途中からwasm-toolsに切り替えました。おわりにWebAssemblyの世界に入門できた気がするのでやってみて良かったと思います。今回はJavaScript APIの実装でしたが、WebAssemblyのランタイム自体も触っていけるようになると良いですね。https://zenn.dev/katei/articles/wasm-js-types-polyfill ↩︎https://github.com/WebAssembly/function-references/blob/main/proposals/function-references/Overview.md#type-reflection ↩︎

WebKitにWasm Type Reflection API（の一部）を実装してみた

以下のスクリプトを run-jscwat という名前で適当な場所に作ってパスを通しておく。wat2wasm を使って test.wat を test.wasm にして、それを base64 にしたやつを標準入力に流す。run-jscwat#!/bin/bashWEBKIT_DIR=${WEBKIT_DIR:-"/home/sosukesuzuki/ghq/github.com/WebKit/WebKit"}JSC_PATH="$WEBKIT_DIR/WebKitBuild/JSCOnly/Debug/bin/jsc"TEST_SCRIPT="$WEBKIT_DIR/Web...

jscのWasm系APIをデバッグするためのスクリプト

ただのメモ。Macで ./Tools/Scripts/build-jsc でビルドする場合は成果物ができる場所が異なるので注意。自分は Linux で ./Tools/Scripts/build-webkit --jsc-only --debug でビルドしている。WebKitの./Tools/Scripts/run-jsc --jsc-only ./WebKitBuild/JSCOnly/Debug/test.jsとやっていたけどめんどくさい（実際には ./Tools/Scripts にパスが通っているので run-jsc --jsc-only ./WebKitBuild/JSCO...

JSCOnlyを実行するスクリプト

WebKitのtest262のCIがSonomaでは成功するけどVenturaでは失敗しているが、原因がわからずにちょっと困っている。失敗しているテストは全部 test/intl402 系なので、多分システムのICUのバージョンの違いなんだと思う。それはそうとして、特定のmacOSのバージョンでどのICUが使われているかわからないとデバッグが困難すぎる。幸い、Appleは https://opensource.apple.com/releases/ で各OSがどのOSSに依存しているのかを公開している。ただ、ICU は https://github.com/unicode-org/...

特定のmacOSで使われているICUのバージョンを調べる

オタクの後輩が「ある特定の時刻までのカウントダウンタイマーを作りたい」というので 「Intl.DurationFormat とか Temporal 使おうぜ」という提案をした。Intl.DurationFormat は WebKit にしか実装されていないのだが、対象のOSは Ubuntu であり、Safari を入手することはできなかった。そこで Playwright 経由で WebKit GTK の MiniBrowser を入手し、それを使うことになった。MiniBrowser 自体は普通に動き、さらに Intl.DurationFormat も普通に動くのだが、 Tempor...

MiniBrowser に JSC のオプションを渡す

この記事では Intl.Segmenter のような Intl の下に存在しているコンストラクタの中で Intl.Locale を除くものを「Intl のコンストラクタ」と呼ぶ。Intl のコンストラクタとロケールIntl のコンストラクタは、ロケールを表す文字列か Intl.Locale オブジェクト（あるいはそれらのみを含む配列）を受け取る。これは省略することもでき（つまり undefined を受けることができる）、その場合は規定のロケールが使われる。const s1 = new Intl.Segmenter("en-US");const s2 = new Intl.Segmenter(new Intl.Locale("en-US"));const s3 = new Intl.Segmenter(["en-US", new Intl.Locale("en-US")]);const s4 = new Intl.Segmenter();Intl のコンストラクタに、ロケール識別子として不正な文字列や Intl.Locale ではないオブジェクトを渡すと RangeError を throw する。try {    new Intl.Segmenter("invalid-locale-id");} catch (e) {    console.log(e.name); // RangeError}try {    new Intl.Segmenter({});} catch (e) {    console.log(e.name); // RangeError}ロケールのマッチングIntl のコンストラクタは受け取ったロケール情報が不正でないことを確認したら、受け取ったロケール情報とその環境で使えるロケールの情報をマッチングし、適切なロケールを選択する処理を行う。このときに行われるロケールのマッチングのアルゴリズムを Intl のコンストラクタの localeMatcher オプションで指定できる。localeMatcher オプションは "lookup" もしくは "best fit" という文字列を受け取る。"lookup" と "best fit" 以外の値を受け取ったら RangeError を throw する。省略した場合は "best fit" として扱われる。const s1 = new Intl.Segmenter("en-US", { localeMatcher: "lookup" });const s2 = new Intl.Segmenter("en-US", { localeMatcher: "bestfit" });try {    new Intl.Segmenter("en-US", { localeMatcher: "invalid-matcher" });} catch (e) {    console.log(e.name); // RangeError}Intl のコンストラクタに配列を渡した場合はその中でもっともマッチしたものを一つだけ選ぶ。仕様で動作が定められている lookuplocaleMatcher の値が "lookup" のときは、ECMA402 の LookupMatchingLocaleByPrefix という abstract operation で規定されたアルゴリズムによってマッチングを行う。具体的には以下の手順に従う:まず、利用可能なロケール情報の一覧 availableLocales と、コンストラクタの引数として受け取った requestedLocales の２つの値が存在するrequestedLocales を一つずつ見ていく（配列ではなく単体の文字列やオブジェクトを渡した場合は要素数が1の配列ようのように扱う）requestedLocales の各ロケール情報に含まれるUnicode locale extension sequenceの部分と、拡張を含まないロケール識別子の部分を分ける[1]分けたあとのロケール識別子が availableLocales に含まれていたら、それと拡張の部分をくっつけて返すロケール識別子が availableLocales に含まれていなかった場合、ロケール識別子から一つサブタグを取り除いて、step 4 を繰り返す（たとえば en-US-California が availableLocales に含まれていなかったら、-California の部分を取り除いて en-US が availableLocales に含まれているかを再度チェックする）。詳細な動作は ECMA402 を参照してほしい。実装依存の best fit一方で localeMatcher の値が "best fit" のときにどのようにマッチングを行うかは実装依存である。仕様上は LookupMatchingLocaleByBestFit という abstract operation が呼び出されているが、冒頭で implementation-defined であることが明記されている。JavaScriptCore[2]とSpiderMonkey[3]は、"lookup" のときと全く同じ動きをする。これはあくまで暫定的にこうなっているだけで、より良い実装があればそちらが採用されるだろう。V8でも "lookup" と同じ動きをするが、harmony_intl_best_fit_matcher フラグを付けると ICU 67.1 から実装されているicu::LocaleMatcherが使われるようになる[4]。これは、言語的な近さや歴史的な背景を考慮したアルゴリズムらしい。たとえば en-AU (オーストラリア英語) は en-US（アメリカ英語）より en-GB（イギリス英語）に近いものだと判定されるようだ。Unicode locale extension sequence は簡単に言えば en-US-u-ca-buddhist の u-ca-buddhist の部分のことだ。ca 以外にも cf や fw などたくさんの種類がある。詳細は UTS#35 を参照してほしい。 ↩︎https://github.com/WebKit/WebKit/blob/c994460e362bfdfa5706e5fb55b79eef38f51527/Source/JavaScriptCore/runtime/IntlObject.cpp#L928-L935 ↩︎https://searchfox.org/mozilla-central/rev/dea459eb01a4c38b696ae3d31c1540e86365a937/js/src/builtin/intl/CommonFunctions.js#314-326 ↩︎https://chromestatus.com/feature/5407573287108608 ↩︎

Intlにおけるロケール識別子のマッチング

最近、自分のプライベートの開発環境を大きく変えたので紹介する。先にまとめプライベートではMacを使わなくなった家にUbuntuが入ったミニPCを置いた外からはThinkPad X1 CarbonからTailscale経由のSSHで家のミニPCに接続購入までまず、自分にとって最も大きな変化はプライベートでMacを使わなくなったことだ。2013年くらいにプログラミングを始めてからずっとメインのOSはMacだったので、約10年ぶり、ほぼ初めての非Mac環境である。自分の普段の開発のユースケースは、Webアプリケーション開発とNode.js上で動くソフトウェアの開発、WebKitへのコントリビューション、たまにRustやGoやC/C++で自分専用ツールの開発、くらいなので別にMacで困っているわけではなかった。Web開発やNode.js上のソフトウェアの開発はまあ普通にMacで困らないし、WebKitもさすがAppleという感じでMacでも全く困らない（というかむしろMacの方が困らない）。Rust/Go/C/C++ あたりは、他の人の環境でも動くソフトウェアを作るならMacだけだと困ることもあるのだろうけど、Macでしか動かさないので特に困ってはいなかった。じゃあなんでMacを使わなくなったのかと言うと、自分はMacを持っていなくて、かつMacは高額だからだ。これまで、会社や研究室から貸与されたMacBookをプライベートな開発でもたくさん使っていたのだが、まあ普通にあんまり良くはないので、それはやめようと考えていた。研究室のPCの場合はプライベートで使っても問題はないかもしれないが、自分は大学院にいくつもりはなくすぐ返却することになるので、あまり使いたくなかった。ということでMacを自費で購入しようと思ったのだが、なんとMacはめちゃくちゃ高いのだ。自分のほしい性能のMacBookを購入しようとするとなんと300,000円を超えることがわかった。自分はパソコンにそんなにお金を出したくないので、Macはとりあえず諦めることにした。「どうしたもんかなあ」と思っていたときに @kateinoigakukun と話したら普段はミニPCで開発を行っているということを教えてくれた。正直ミニPCのことは全く考えていなかったのだけど、家にでかいディスプレイとかキーボードとかマウスはある。それに、家のクローゼットの中には5年くらい前に買った ThinkPad X1 Carbon があってSSHできるから、別にそれでも問題ないと思った。そこで、大学内のパソコン好きが集まる部屋 で「ミニPCにLinux入れて開発するのどう思う？」と聞いたら概ね肯定的な反応が返ってきたので、Amazonでその場で購入した。購入したミニPC自分はミニPCについて全然詳しくないので、偶然その場にいた後輩に聞いて Minisforum Venus Series UM790Pro を買った。スペックは以下の通り:keyvalueCPURyzen 9 7940HSメモリDDR5 64GBストレージ1TB PCIe4.0 SSD今 Amazon で見たら 146,980 円だったが、自分が買ったときはセールで 120,000 円くらいだった。CPU を Ryzen にするか Intel にするかは悩んだが、結局 Ryzen にした。特に理由はない。家に設置したミニPC、自分のものであることを示すためにステッカーを貼ってあるUbuntuインストール＆セットアップ購入したミニPCにはWindows 11が入っていたのだが、Windowsをメインとして使う気はなかったので、何かしらのLinuxを入れる必要があった。大学の後輩たちに聞くと「Arch良いっすよ」とか「Fedoraどうすか」とか言ってきたが、Linuxビギナーである自分にはちょっと難しそうと素直に思ったので、Ubuntuを入れることにした。特にこだわりはないし、他のディストリビューションを批判するつもりはない。今後変える可能性もある。自分は本当にパソコン初心者で、Ubuntuの入れ方や初期設定なども全然自信がないので、大学の後輩を頼ることにした。大学内のパソコン好きが集まる部屋にミニPCを持っていき、後輩のCentRaくんにインストールディスクの作成から何から何まで全部やってもらった。今度ご飯を奢ろうと思う。日本語入力のためのキーボード設定など一部つまづいたところはあったが、割とすんなり設定ができた。設定を初めてからWebKitをビルドできるようになるまで3時間くらいでいけた。すべて後輩のおかげだが。一点だけ困ったのは、peco の表示がおかしくなることだった。おそらく https://github.com/peco/peco/issues/554 と同じ問題で TERM=xterm としたら直った。そのあと「WindowsからSSHで使いたいんだよね」と言ったら、これまた後輩が「Tailscaleいいっすよ！！」と教えてくれたのでその設定もその場でサクッとした。めっちゃ簡単でびっくりした。自分はそこまでキーマップをカスタマイズする方ではないが Ctrl + hjkl をカーソルに割り当てるのだけはないとまともに操作できない。MacのときはKarabinar Elementsを使っていたが、Linux版はない。そこでLinux用の良いキーリマッパーを探したところ xremap というのを見つけたので、それを使うことにした。YJITユーザーではないが、sqldefもたまに使うので、k0kubunウェアには結構お世話になっている。普段の開発家にいるときはミニPCをデスクトップPCとして使っている。UbuntuもLinuxも使うのは初めてだが、直感的に操作できるGUIが備わっているので今のところは特に困っていない。日頃から使っていたアプリケーションのほとんどはブラウザ上で動作するものだったので、それをそのまま使っている。ブラウザ最高。ただ、WebKitに新しいファイルを追加するときにはXCodeのGUIが必要になる。このミニPCを買ってからそういう機会はまだ来ていないのだが、そのときだけはMacを使うかもしれない。外にいるときは、2019年に買ったThinkPad X1 CarbonからSSHで接続して開発をしている。このマシンにはWindows 11が入っている。Windowsで開発をしようとするとしんどいみたいな話を聞くことがあるが（自分はやったことないので知らない）、SSHのクライアントとして使う分には特に困っていない。ただ、長いことMacを使っていたため細かいところで使い方がわからずわざわざググることはある。こないだはプリンターへのつなぎ方がわからなかった。ThinkPad から家のミニPCへSSH接続するとき、ほとんどケースでVSCode Remote Extentionを使っている。これのおかげで、ミニPCを直接使うときとほとんど変わらない操作感を実現できている。おわりに良い感じの環境を整えることができて満足している。そして相変わらず筑波大学というのは便利な場所で、パソコンが苦手な人にパソコンを教えてくれる人がたくさんいる。

プライベートでMac使うのやめた

別にみんなそうするべきとは全く思わないのだけど、僕は最近GitHub Copilotを意図的に無効にすることがあるので、そのへんについて雑に書いておく。あらかじめ言っておくが、僕はGitHub Copilotを有効にすることもある。この記事もGitHub Copilotおよびそのユーザーを批判する意図は全くない。 GitHub Copilot が便利な場面僕がGitHub Copilotを使い始めて少なくとも一年以上は経ってる。自分が書こうと思っているコードに近いものが簡単に生成されていくことに最初は感動したし、便利な場面がはたくさんある。具体的に便利な場面を思い返してみる。...

最近は意図的にGitHub Copilotを無効にすることがある

XbyakはJITアセンブラで、デバッグが大変。生成されたコードを逆アセンブルして見るのも、普通のAOTコンパイラと比べるとちょっと工夫がいる。https://github.com/herumi/blog/blob/main/jit-debug.md#逆アセンブル で解説されている通りだけど、メモを残しておく。getCode を getSize 分だけバイナリとして適当なファイルに出しておく。    JITCompiler::Func fn = getCode<JITCompiler::Func>();    size_t codeSize = getSize();...

Xbyakで生成したコードをファイルに出して逆アセンブルする

TSKaigi 2024 で話した「Prettier の未来を考える」という発表のスピーカーノートです。スライドはこんにちは、今日は「Prettierの未来を考える」というタイトルでお話させていただきたいと思います。鈴木 颯介と言います。ユビー株式会社でプロダクト開発エンジニアとして働きながら、筑波大学でパソコンの勉強をしています。オープンソースソフトウェアが好きで、今日お話するPrettierのメンテナーをしたり、トランスパイラのBabelのコミッターをしたりしています。最近はWebKitのJSエンジンにたくさんパッチを投げたりしています。私が働いているユビーは、TSKaigi...

TSKaigi 2024 Prettierの未来を考える スピーカーノート

publicリポジトリのGitHub ActionsでM1 Macが使えるようになりました[1][2]。日本語では以下の記事が詳しいです。https://zenn.dev/cybozu_ept/articles/productivity-weekly-20240131#github-actions-で-m1-macos-ランナーが-public-リポジトリで無料に使えるようになりました記事中でも言及されていますが 4 月 6 日から macos-latest が M1 Mac を指すようになりました。これによって、actions/setup-node を使って Node.js 14 ...

GitHub ActionsでM1 Macが開放されたことによって何もしてないのにNode.js14のCIが失敗するようになった

インターナルなDiscordで人に説明したやつをそのままコピーしたものです。https://webkit.org/blog/15375/release-notes-for-safari-technology-preview-193/ の JavaScript の Resolved Issues にあるやつです。コミットは https://github.com/WebKit/WebKit/commit/1ff045b365bb63494783062033d5ef8a0c629cb7 です。Function.prototype.toString という関数はthisの関数を文字列化して...

マジでどうでもいいWebKitのバグを修正した(Function.prototype.toString編)

ECMAScript の Set にいくつかのメソッドを追加する Set Methods プロポーザルについて解説する。免責事項筆者は集合の用語に慣れているわけではないので、もし用語の使い方が不適切である場合は Twitter 等で連絡をいただきたい。また、Set Methods は本記事執筆時点で Stage 3 である。追加されるメソッドSet.prorotype.intersection(other)this と other の共通部分となる新しい Set を返す。const foo = new Set([1, 2, 3]);const bar = new Set([3, 4, 5]);console.log(foo.intersection(bar));// Set(1) {3}Set.prototype.union(other)this と other の和となる新しい Set を返す。const foo = new Set([1, 2, 3]);const bar = new Set([3, 4, 5]);console.log(foo.union(bar));// Set(5) {1, 2, 3, 4, 5}Set.prototype.difference(other)this と other の差となる新しい Set を返す。対称でないことに注意。const foo = new Set([1, 2, 3]);const bar = new Set([3, 4, 5]);console.log(foo.difference(bar));// Set(2) {1, 2}console.log(bar.difference(foo));// Set(2) {4, 5}Set.prototype.symmetricDifference(other)this と other の対称差となる新しい Set を返す。const foo = new Set([1, 2, 3]);const bar = new Set([3, 4, 5]);console.log(foo.symmetricDifference(bar));// Set(4) {1, 2, 4, 5}Set.prototype.isSubsetOf(other)this が other の部分集合であるかどうかを真偽値で返す。const foo = new Set([1, 2, 3]);const bar = new Set([1, 2]);const baz = new Set([4, 5]);console.log(bar.isSubsetOf(foo));// trueconsole.log(baz.isSubsetOf(foo));// falseSet.prototype.isSupersetOf(other)this が other の上位集合(superset)であるかどうかを真偽値で返す。const foo = new Set([1, 2, 3]);const bar = new Set([1, 2]);const baz = new Set([4, 5]);console.log(foo.isSupersetOf(bar));// trueconsole.log(foo.isSupersetOf(baz));// falseSet.prototype.isDisjointFrom(other)this と other が互いに素であるかどうかを真偽値で返す。const foo = new Set([1, 2, 3]);const bar = new Set([3, 4]);const baz = new Set([4, 5]);console.log(foo.isDisjointFrom(bar));// falseconsole.log(foo.isDisjointFrom(baz));// true参考TC39https://github.com/tc39/proposal-set-methodshttps://tc39.es/proposal-set-methods/WebKithttps://github.com/WebKit/WebKit/blob/main/Source/JavaScriptCore/builtins/SetPrototype.js

ECMAScript の Set Methods プロポーザル

TC39の活動で有名なJordan Harbandが作成した下記issueで知ったのでメモ。https://github.com/microsoft/TypeScript/issues/57000前提として、次のコードによって x がオブジェクト型であることを判断できる。JavaScriptにおける null は typeof の結果が "object" になるという有名な変な挙動がカバーされている。function isObjectA(x) {  return (typeof x === "object" && x !== null) || typeof x =...

JavaScript である値がオブジェクト型であることを判定する変なテク

2023 年を振り返ります。仕事移転したユビーのオフィスにあるかっこいい壁相変わらずユビーでプロダクト開発エンジニアをしていました。症状検索エンジン ユビーを開発するチームでフロントエンドとバックエンドを書いています。このプロダクト上で、製薬企業向けのソリューションを実現するための開発をしています。複雑なドメイン知識が求められる上に、会社の成長に伴って求められるデータやサービスの信頼性が上がってきていてチャレンジングな仕事だなと思っていますが、頼れる仲間と共に頑張っています。また、仕事に関する記事をいくつか書きました。テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携開発スピードを維持しながらモブプログラミングを実施した話そういえば、たまに「どのくらい働いているんですが？」と聞かれることがあるんですが、普通にフルタイムで働いています。大学が忙しいときには会社にはかなり融通を効かせてもらっているので、ありがたい限りです。大学研究室からの森だらけの景色いまだに筑波大学情報学群情報科学類で学部生をしていました。本当は 2023 年の 4 月のタイミングで 4 年生になりたかったんですが、修得単位数が足りなくて 4 年生になれませんでした。筑波大学(もしくは僕の所属する学群か学類)では、4 年生にならないと卒業研究に着手できないので、僕はまだ卒業研究に着手できていません。困った。ですが、よくわからないんですが、研究室にはちょっとだけ配属されていて毎週の輪講などには参加しているし、微妙に研究が始まっています（卒業研究に該当する科目の履修登録はしていないが、実態としては始まっている）。合宿にも行きました。僕の所属している研究室は言語処理系とかをやる研究室で、他のメンバーはだいたい構文解析をやっているんですが、自分はガベージコレクションのことを好きになってしまったのでそっち系のことをやっています。さらに、なんの偶然か同僚である@yukukotaniと研究室まで同じになってしまいました。留年しているフルタイムワーカーを二人抱えることになってしまった研究室の先生に対して、少し申し訳ない気持ちがあります。最近は勉強に対してちょっとだけ気持ちがあって、期末テストはそこそこ気合を入れて挑みました。手応えはまあ...、単位は来るんじゃないですかね、という程度ですが。最近は人と会う機会が増えて「卒業する気あるの？」と聞かれることも多くなってきたんですが卒業する気まんまんです。来年の動向にご期待ください。ちなみに、来年度卒業できないと最大在学年限の関係で強制退学になるのでシビアな戦いが始まります。やるしかねえ。オープンソースソフトウェア2023 年は Prettier 以外のソフトウェアにはほとんど関わりませんでした。全体的に OSS というものに関心がなくなってきている気がします。仕事とか勉強とか、OSS よりももっとやりたいことができたからなのでしょうか。よく考えてみると、僕はプログラムを書くのは好きで、最初のバイト先の影響で OSS の文化が当たり前だったから、OSS を趣味としてやっていただけであって、OSS というものが好きだったわけではないのかな、と思い始めました。Prettier というユーザーの多いプロジェクトの管理者的な役割を担っているせいで、コードを書く以外の OSS の苦しい仕事が増えてきて、そういう気持ちが強まっています。とはいえ、Prettier での仕事は基本的には楽しいので「みんなが求める Prettier の水準」を下回ることがないようにメンテナンスは継続するつもりです。また、Biome という競合が出てきたことで、Prettier のパフォーマンスを改善しようという動きもあり、そのへんも 2024 年に何かしらリリースしたいと思っています。Prettier 自体の 2023 年の振り返りについては Zenn に書いた 2023 年の Prettier 振り返り を読んでください。勉強僕がよく勉強に使っている筑波大学WORD編集部のブレた様子2023 年は結構色々勉強した気がします。一番勉強したのはガベージコレクションです。「ガベージコレクション 自動的メモリ管理を構成する理論と実装」を読んだ や ガベージコレクション実装したいから LISP 風インタプリタ作った に書いたように、本を読んで自分で実装したり、先生と色々話したりしていました。ガベージコレクションに関して普通の会話はできるようになったかなと思います。また大学の勉強もいくつかはまじめにやりました。そのおかげで、オートマトンやオペレーティングシステムについても、そんなに自信はないですが普通の会話ができるくらいにはなったんじゃないかなあと思っています。あと大学は全く関係ないですが、プログラム意味論の勉強をするために プログラミング言語の形式的意味論入門 を読んだり、低レベルプログラミングの一般的な知識が足りないなーと思ったので 低レベルプログラミング を読んだりしていました。いずれも読みかけですが、楽しいのでよし。そのほかパソコンあんまり覚えていないですが、しょぼい KVS を Go で実装したり、ECMAScript の正規表現パーサーを Go で書こうとして挫折したり、C 言語で正規表現エンジンを実装したり していたようです。ダイエット実は 2023 年の 6 月からダイエットを開始して、現時点で 20kg くらい体重が減りました。身長が 170cm で、体重がもともと 92kg くらいあってかなり激しい肥満という感じだったんですが、今は 72kg まで減っています。そんなに苦労した感じはなく、飯をあんまり食べずにエアロバイクを漕いでいたら 4 ヶ月くらいで 15kg くらい痩せました。本当はもう少し痩せたいのですが、やる気が出ず停滞中というです。発信次世代Webカンファレンスの会場設営の様子2023 年のはじめに、uhyo さん に誘って頂いて Web+DB PRESS に寄稿しました。雑誌とか書くの初めてだったので楽しかったです。2月24日に発売される WEB+DB PRESS Vol.133 の TypeScript 特集のうちリンタについての章を書かせていただきました。ESLintやPrettierをTypeScript用に設定するのって結局どうしたらいいの？と思ってる方はぜひ手にとってみてください。 https://t.co/dYbCT6IeFP— sosuke (@__sosukesuzuki) February 18, 2023 Findy Enginner Lab に記事を寄稿しました。まだ卒業もできてないのにキャリアについて語っていいんか？という気持ちはありましたが、せっかくの機会なので書かせてもらいました。Findy Engineer Lab に寄稿させていただきました。せっかくなので自分のキャリアについて振り返りました。/ 趣味だったOSS活動で収入を得られるようになるまで。「継続」と「発信」がキャリアを切り開いた - Findy Engineer Lab - ファインディエンジニアラボ https://t.co/mCvi8RRtuK— sosuke (@__sosukesuzuki) April 28, 2023 オフラインの登壇を何度かやらせてもらいました。たくさんの人と出会うことができて楽しかったです。日付イベント資料等2023 年 3 月 24 日Encraft#1Google Slide2023 年 9 月 6 日nihonbashi.js#7Speaker Deck2023 年 11 月 19 日JSConf JP 2023Zenn2023 年 12 月 16 日次世代 Web カンファレンス 2023まとめ実は色々やっていた。来年は卒業できるといいね。

2023 年振り返り

2023 年の Prettier の活動を振り返ります。 Prettier とはPrettier は JavaScript で書かれたコードフォーマッタです。設定可能な項目が少ないいわゆる opinionated なコードフォーマッタです。JavaScript や TypeScript だけではなく、HTML や CSS、GraphQL などもサポートしています。 リリース2023 年は、メジャーバージョンのリリースが 1 回、マイナーバージョンのリリースが 1 回でした。これまでは 3 ヶ月に 1 回程度マイナーバージョンをリリースしていたので、頻度は少し下がっています。...

2023 年の Prettier 振り返り

この記事は Angular Advent Calendar 2023 の 19 日目です。Prettier というコードフォーマッタは Angular のテンプレート構文をサポートしています。私は Angular をほとんど使ったことがありませんが、Prettier をメンテする上で Angular のテンプレート構文について調査したり、@angular/compiler の実装を読んだりしています。この記事では、Prettier による Angular テンプレート構文のサポートの技術的な詳細について説明します。そして、v17 で developer preview となった bu...

Prettier の Angular サポートの仕組みと built-in control flow 対応

この記事は、茨城県つくば市の町域であるところの天久保とは無関係な任意団体「天久保」のアドベントカレンダー の 5 日目です。今日は 12 月 10 日ですけど。今となっては学年を抜かされてしまった後輩に急かされてしまったので、急いで書いています。 冬は正規表現の季節12 月になっていよいよ冬の到来を感じる気候になってきました。冬といえば正規表現です(筑波大学で「オートマトンと形式言語」という授業が開講されるのが冬だから）。ちょうど一年前、私は生まれて初めて正規表現エンジンを作りました。去年作った正規表現については以下のブログを参照してください:https://sosukesu...

C言語で書いたVM型正規表現エンジンをWebAssemblyにしてブラウザで動かす

この記事はUbie Engineering Advent Calendar 2023の3日目です。こんにちは、ユビーでプロダクト開発エンジニアをしている Sosuke Suzuki です。この記事では QA エンジニアと連携するにあたって、テーブル駆動テストがとても役に立ったという話をします。 テーブル駆動テストとはテーブル駆動テスト(Table-Driven Testing)とはテストを書くときのテクニックの一つです。複数のテストに共通するパターンをテーブルとして抽出することで、コードの記述量を減らすことができ、テストを追加するのが簡単になります。TypeScriptとJe...

テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携

この記事は Fabio 氏が Prettier 公式ブログに寄稿してくれた Prettier's CLI: A Performance Deep Dive を許可をもらって翻訳したものです。このブログ記事は長く、まじめに翻訳する時間がなかったので、ChatGPT でサクッとやりました。変なところがあったらコメントで教えてください。先日の記事で紹介したように、Prettier には Biome Formatter という強力な競合が現れました。Biome は Rust で書かれており非常に高いパフォーマンスを発揮します。しかし、実は今のところ Prettier のパフォーマンスを改善しよ...

【翻訳】Prettier's CLI: A Performance Deep Dive

この記事は vjeux 氏によって Prettier 公式ブログに投稿された「$20k Bounty was Claimed!」を許可をもらって翻訳したものです。もとのタイトルを翻訳するのが難しかったので、できるだけわかりやすいものに翻訳しました。PrettierというJavaScriptのコードフォーマッターは、人々がコードを書く様々な方法を慎重に扱うことで、驚くほど広く採用されています。この時点で、フォーマットロジックは安定しており、私たちの三項演算子に関する作業が完了すれば、それは満足のいく状態になるでしょう。これは、次の重要な側面に注目できるということを意味します：パフォ...

【翻訳】Prettier を Rust で書き換えたプロジェクトに $20k の報奨金を支払うプログラムは Biome が勝ちました

この記事は、JSConf JP 2023 で発表した「書いたJavaScriptがそのままブラウザで動く未来へ」のスピーカーノートです。もともと PDF を公開していたのですが、読みにくいという声をいただいたので移植しました。内容はそのままで、見出しだけ付けています。 はじまりこんにちは、今日は「書いたJavaScriptがそのままブラウザで動く未来へ」というタイトルで発表をします。「いやいや、JavaScriptはブラウザで普通に動くだろう」と思われる方もいらっしゃるかもしれませんが、話を聞いてもらえれば何を言っているのかわかると思います。JSConf JPで登壇させていただ...

JSConf JP 2023「書いたJavaScriptがそのままブラウザで動く未来へ」スピーカーノート

この記事はAlex Rattrayさんの A curious case of the ternaries を、本人の許可を得て翻訳したものです(タイトルは大幅に変えてしまっていますが)。記事の最後にあるように Google Forms から新しい機能についてのフィードバックを求めています。私以外のメンテナーも読めるようにできるだけ英語で書いてほしいですが、「日本語でなら書いてもいいよ」という人がいたら日本語で書いてもらっても大丈夫です。三項演算子のフォーマットは長年の課題でした。Prettier の v3.1.0 では新しいフォーマットのスタイルを導入することで、ついにこれを解決しました(訳注: 後述の通り、まだ experimental なので、--experimental-ternaries をつけたときのみ有効になります)。このブログ記事では、これまでの経緯と背景、実際に触ってくれた開発者からのフィードバックと、新しい「curious ternaries」スタイルの概要について説明します。--experimental-ternaries オプションを試してみて、ご意見をお聞かせください。簡単な概要については v3.1.0 のリリースブログを参照してください。導入ネストされた三項演算子を様々な状況で適切にフォーマットすることは、驚くほど難しい課題です。開発者はそういった三項演算子を非常に読みにくいと感じていました。そのため最終的に、コードの一部を見苦しい if 文と let 変数を使ってリファクタリングしたり、即時実行関数や完全に別の関数に切り出したりすることもありました。ベータ版を実際に使ってくれた人たちによると、私たちが開発した新しいフォーマットスタイルは、慣れるまでに時間がかかるかもしれませんが、最終的には、最新のコードベースで三項演算子を使えるようになるでしょう。歴史的な背景Prettier のもともとの単純なアプローチ(ネストされた三項演算子の各レベルにインデントを追加するだけです)は、単純な場合には上手く機能しました。しかし、ネストされた三項演算子の長いチェーンには対応できていませんでしたし、他にもいくつか問題もありました。そこで 2018 年に、これをインデントをしないフラットな三項演算子に置き換えました。これは当時は良いアイデアのように思われましたが、評判はあまり良くありませんでした。元に戻すように求める issue には 500 を超える upvote が寄せられました。今回リリースした v3.1.0 ではインデントされた三項演算子に戻しましたが、より良い方法を見つけたいと考えていました。ここ数年の間私たちは、一般的なケースではインデントされた三項演算子と同じくらい読みやすくて、さらに様々な状況で適切に機能するようなソリューションを、いくつも考えて実験してきました。挑戦的な基準理想的には、私たちは以下の基準を満たすスキームを 1 つ見つけ出したいと考えています:すべての場合において、どの部分が if なのか、どの部分 then なのか、どの部分が else なのかを簡単に把握することができる必要がある。単一の三項演算子から、2 つの三項演算子のチェーン、さらにネストされた長いチェーンまで、ちゃんとスケールできる必要がある(私たちが検討した代替案のほとんどはこの条件を満たすことができませんでした)JSX、TypeScript の conditional types(これは if では表せません)、および通常の JavaScript のすべてを同じように扱える必要がある三項演算子のネストがどれだけ長くてもスケールできる必要がある(数十にネストされた TypeScript の conditional types を想像してみてください)。v3.1.0 で帰ってきたシンプルなインデントありの三項演算子は、明らかに 4 を満たしません。さらにおそらく 1 や 3 も満たすことができません。また、フラットで読みやすい形式の JSX の三項演算子もサポートしていましたが、JSX 以外では不自然な形になっていました。多くの人たちは Rust や OCaml などの言語の match の構文からインスピレーションを得て、単純な「case style」が良いのではないかと話していましたが、2 や他の目標を満たすことはできませんでした。訳注:「case style」というのは、条件と同じ行に、その条件の then 部分を書き、最後の行に残った else 部分を置くスタイルを指すようです。簡単に言うと次のコードのようなスタイルです:const message =  i % 3 === 0 && i % 5 === 0 ? "fizzbuzz" :   i % 3 === 0 ? "fizz" :   i % 5 === 0 ? "buzz" :  String(i);長くネストされた三項演算子全体に対して「case style」を適用すると読みにくくなってしまうというのが著者の主張です。訳注終わり。驚くべき解決策幸いなことに、私たちの基準を満たすフォーマットスタイルのアルゴリズムが見つかりました。しかし残念ながら、ほとんど開発者にとっては馴染みのない斬新なものになってしまいました。この機能のベータテストでは、このスタイルを見た開発者が、最初は懐疑的な姿勢を取ることがわかりました:しかし、少し使ったあと、彼らは元には戻りたくないと言い始めたのです:さらに、別の開発者は次のように述べています:ルールを有効にしてから最初の 1 時間は、少し奇妙だと思いました。しかし、2 時間目までには、汚い if へのリファクタリングを回避できました。もう元のスタイルには戻れません。私はネストされた三項演算子が嫌いでしたが、コードを if - else 文にリファクタリングするのも嫌いでした。この新しいフォーマットのルールは理解しやすくて、まるで if 式を言語に追加するようなものです。これらのフィードバックを得て、私たちは winning formula を手に入れたと感じました。しかし、それをいきなりデフォルトで有効にすると、コミュニティにとっては不快であることもわかっていました。そのため、私たちはこの新しいフォーマットを数ヶ月の間 --experimental-ternaries オプションとして提供し、それまでの間はコミュニティが求めていたもの、つまりインデントされた三項演算子のフォーマットを提供することにしました。スタイルの概要では、この新しいスタイルはどのようなものでしょうか？「curious」三項演算子の背後にある考え方を示す簡単な、やや不自然な例を以下に示します:const animalName =  pet.canBark() ?    pet.isScary() ?      'wolf'    : 'dog'  : pet.canMeow() ?    'cat'  : 'probably a bunny';? で終わるすべての行は "if" を表しますもし foo ? を見つけたら、それは foo について "if foo? then, ..." と質問するようなものです: で始まるすべての行は "else" を表しますもし : foo を見つけたら、それは "else, foo" を意味しますもし : foo ? を見つけたら、それは "else, if foo" を意味します: も ? もないすべての行は "then" を表しますもしただの foo を見つけたら、それは "then foo" を意味しますそして、「case style」の三項演算子の例を示すために書き換えた例を以下に示します:const animalName =  pet.isScary() ? 'wolf'  : pet.canBark() ? 'dog'  : pet.canMeow() ? 'cat'  : 'probably a bunny';新しいフォーマットのスタイルは「curious」な三項演算子と、「case style」の三項演算子(? が行の中央にある)をなめらかに組み合わせたものです。例を示します:const animalName =  pet.canSqueak() ? 'mouse'  : pet.canBark() ?    pet.isScary() ?      'wolf'    : 'dog'  : pet.canMeow() ? 'cat'  : pet.canSqueak() ? 'mouse'  : 'probably a bunny';フィードバックをください！新しくて読みやすいデフォルトを気に入っていただけるとうれしいです。また、--experimental-ternaries を有効にして、数週間試してもらえるとうれしいです！実際に使ってみて、Google Forms からフィードバックをください: https://forms.gle/vwEuboCobTVhEkt66

【翻訳】Prettier の新しい三項演算子のフォーマットを試してみてください

ガベージコクレクションは手を動かすまでがちょっと遠い下記の記事で書いたように、私は今ガベージコレクションに夢中です。https://zenn.dev/sosukesuzuki/articles/0d991d76f778b7少し勉強して、ガベージコレクションの難しさの1つは「実装してみる」までが遠いところなのではないかと思っています。ガベージコレクションというのは、それ単体で成り立つものではなく、基本的にはプログラミング言語の処理系と一緒に実装されるものです。したがって「ガベージコレクションに入門するぞ〜」と意気込んで理論を勉強しても、実装する対象となる適切な処理系がない、とい...

ガベージコレクション実装したいからLISP風インタプリタ作った

最近「おれってガベージコレクションを勉強するにあたってめちゃくちゃ恵まれた環境にあるのでは？」とふと思い立ち、ベージコレクションの勉強を始めました。ガベージコレクションの勉強を始めるにあたって、とりあえず「The Garbage Collection Handbook (first edition)」の邦訳である「ガベージコレクション 自動的メモリ管理を構成する理論と実装」を読むことにしました。この記事では、読み終わってうれしいので、雑に感想を書きなぐっています。表記が「GC」だったり「ガベージコレクション」だったりするのは雑に書いたからです。 前提知識ガベージコレクションの事...

「ガベージコレクション 自動的メモリ管理を構成する理論と実装」を読んだ

2023 年 7 月 5 日に Prettier 3.0 をリリースしました。Prettier 2.0 がリリースされたのが 2020 年 3 月 21 日だったので、実に 3 年以上ぶりのメジャーアップデートとなります。本当はもっと早くこのブログを書きたかったんですが、やる気が出ずだいぶ遅れてしまいました。この記事では Prettier 3.0 の主要な変更点を紹介します。Prettier 3.0 の主要な変更点Prettier 3.0 はメジャーアップデートということもあって大きな変更がいくつか含まれています。ここでは、そのうちユーザーに直接的な影響がありそうなものを紹介します。ここで紹介する以外にも大きな変更はありますが、プラグイン開発者向けのものとか、Prettier のソースコード自体が全部 ECMAScript Modules で書かれるようになったとか、ユーザーからしたらどうでもいいような変更が多いのでここでは紹介しません。興味がある方は公式のリリースブログを参照してください( https://prettier.io/blog/2023/07/05/3.0.0.html )。日本語/中国語とラテン文字の間にスペースを入れないようにするこの変更は、日本語を日常的に書く人たちにとって影響が大きいと思います。Prettier 2.0 までは Markdown をフォーマットするときに、日本語/中国語の文字とラテン文字の間に空白を挿入していました。たとえば、以下のような Markdown のテキストがあったとします。私はJavaScriptを書きます。Prettier 2.0 はこれを以下のようにフォーマットしていました。私は JavaScript を書きます。Prettier 3.0 からはこのようなスペースを挿入しなくなります。この挙動には賛否両論あると思います。日本語/中国語とラテン文字の間に空白を挿入しないスタイルを好む人からしたら鬱陶しい機能だったと思います。この挙動を回避するために Prettier を Markdown に対しては適用しない、というユーザーがいたことも知っています。しかし、逆にそれを好む人からしたら便利な機能だったようです。実際 Prettier 3.0 をリリースした後に、この挙動を元に戻してほしいという意見を聞きました。このブログ記事を見れば分かる通り、私自身は日本語とラテン文字の間に空白を入れるスタイルを好みます（好んでいるというよりは手癖でそう書いてしまうのですが）。しかし、私個人としてはそれは Prettier の責務ではない、と考えています。日本語とラテン文字の間の空白は、視覚的な調整のための目的で使われることがほとんどでしょう。であれば、それはテキスト情報に含まれるべきではなく、文字をレンダリングする側のソフトウェアが対応するべきで、少なくとも Prettier によってそれを強制されるのは間違っている、というのが私の考えです。もちろん、私が一人で決定したわけではありませんが、Prettier 3.0 ではこの考え方を優先しました。ユーザーのことを考えると難しい意思決定でした。trailingComma オプションをデフォルトで all にするPrettier には trailingComma というオプションがあります。このオプションは none と es5 と all の 3 つの値のどれかを取ります。none は一切の末尾カンマを取り除きます。es5 は ECMAScript 5 として妥当になるように末尾カンマを追加します。all はすべての箇所にできる限り末尾カンマを追加します。具体的な挙動を全部は覚えていないのですが、たとえば es5 だと関数の引数リストの末尾カンマは削除されます。このような古い挙動をする最後の有名なブラウザである Internet Expolorer がその役目を終えサポート終了となったことから、trailingComma のデフォルト値が es5 から all に変更されました。.gitignore に入っているファイルを Prettier も無視するもともとは Prettier はデフォルトでは .prettierignore に書かれているファイルのみ無視していました。Prettier 3.0 からは .gitignore に含まれているファイルもデフォルトで無視するようになります。個人的にはやりすぎじゃないかなあと思っていますが...型定義ファイル(*.d.ts)を Definitely Typed から本体に移すDefinitely Typed はもともと静的な型の概念がない JavaScript のパッケージに対して後から型を付けるための仕組みとしては優れていると思います。しかし、リポジトリがデカくて開発がしにくすぎるという問題があります。また、bot によって仕組み化されているとはいえ、自分が普段見ていないリポジトリを見に行くのが単純に面倒くさいとか、色々思うところがありました。なので、型定義ファイルを Definitely Typed から Prettier のリポジトリに移しました。JavaScript の API を使う場合に @types/prettier をインストールする必要はもうありません。おわりにもともとのリリース予定から 1 年以上遅れてのリリースになってしまいましたが、リリースできて良かったです。上手くやれたこともあったし、反省していることも多々ありますが、大きな達成感は感じています。ちなみに、Prettier 1.0 がリリースされたときは私はまだ開発に関わっていませんでしたし、Prettier 2.0 は Georgii Dolzhykov さんが主にリリースの管理を行っていました。つまり、Prettier 3.0 は私がリリースの管理を担当した初めてのメジャーバージョンになりました。かなり普及している OSS のメジャーバージョンのリリースを管理する経験は得難いものであると思うので、そういった意味でも良かったと思います。ただ、一部の作業は本当につらくて、自分のプログラミング人生 10 年くらいの中でも最も辛かったと言っても過言ではないような作業もありました。それについては別途ブログを書きたいと思います。

Prettier 3.0 をリリースしました

最近、Kohta Ito さんのブログ記事 0 から始める Node.js パフォーマンスチューニング を読みました。Kohta Ito さんは、実践 Node.js 入門 という書籍を執筆されたことでも知られています。このブログ記事の「framegraph 編」という節では、 Node.js でのフレームグラフの生成方法や見方が説明されています。私はフレームグラフというものを知ってはいましたが、それを見てパフォーマンスの改善に活かしたことはありませんでした。ということで、Prettier のフレームグラフを眺めてみて、実際にちょっとだけパフォーマンスを改善してみました。この記事では、そのパフォーマンス改善について説明します。フレームグラフを生成するツール 0x0 から始める Node.js パフォーマンスチューニング では、フレームグラフを生成するためのツールとして 0x が紹介されています。0x のリポジトリを見ると、Node.js の Technical Steering Committee の一人であり Web フレームワークの Fastify のメンテナーとして知られてる Matteo Collina さんによってメンテナンスされていることがわかります。0x の使い方は簡単です。基本的には、Node.js のスクリプトを実行するときに、node コマンドではなく 0x コマンドを使うだけでフレームグラフを生成できます。たとえば、my-app.js というファイルがあるとします。普通に Node.js で実行するときは次のコマンドを実行します。node ./my-app.jsそれに対して、0x で実行してフレームグラフを生成するときは次のコマンドを実行します。0x ./my-app.jsこのように 0x 経由で Prettier を実行し、そのフレームグラフを見てパフォーマンスに悪影響を及ぼしていそうな箇所を見つけました。Prettier のフレームグラフを見るフレームグラフを眺めることによって Prettier のパフォーマンスを改善しようと考えたときに、どのようなコードをフォーマットするときのフレームグラフを使うべきか、というのは悩みどころです。実用的で、それなりに量が多いコードが望ましいと考えました。その条件を満たすコードとして最初に思いついたのは TypeScript コンパイラの checker.ts です。checker.ts は TypeScript の型チェックにおけるコア部分が実装されたファイルで、巨大であることで有名で知られています。今確認したところ、なんと 49,000 行を超えています。まずは、Prettier の main ブランチでプロダクションビルドを生成します。Prettier ではプロダクション用のビルドを生成するときに yarn build を実行します。しかし、minify されているとフレームグラフから関数の名前が消えて、ボトルネックを見つけるのが困難になります。そのようなときのために、Prettier のビルドスクリプトには --no-minify というオプションが存在します。したがって、今回は yarn build --no-minify を実行します。次は、実際に checker.ts をフォーマットするフレームグラフを生成してみます。0x ./dist/bin/prettier.cjs checker.tsこれで、*****.0x/flamegraph.html のような名前の HTML ファイルが生成されます。この HTML をブラウザで開くとフレームグラフが表示されます。以下の画像が、実際に生成されたフレームグラフです。この記事には関係ないので上部を切り取っています。0xによって生成されたフレームグラフこのフレームグラフを少し見てみると、奇妙な点が見つかります。まず、Prettier の内部処理を大まかに説明します。Prettier では、以下の順番で処理を実行し、入力の文字列から出力の文字列まで変換します。文字列を AST にする(パース)AST を Doc と呼ばれる pretty print のための中間表現にするDoc を文字列にするフレームグラフ上でこの 3 つの処理を色分けしてみます。そして、それぞれをよくみて見ると、パース処理の先頭で重い関数が呼び出されていることがわかります。この関数呼び出しは他の関数を呼び出すわけでもなく、それ単体でそこそこ長い間実行されていて、奇妙です。0xによって生成されたフレームグラフを塗り分けたこの奇妙な赤いブロックにマウスのカーソルを乗せると、isProbablyJsx という関数が呼び出されていることがわかります。奇妙な赤いブロックにマウスのカーソルを乗せたこの記事のタイトルも合わせると、なんとなくこの関数の中身が想像できますね...？奇妙な関数 isProbablyJsx を探るisProbablyJsx という名前でコードを検索すると、すぐにその実装が見つかりました。isProbablyJsx は、引数で受け取った文字列が JSX っぽいかどうかを正規表現を使って判定する関数であるということがわかります。/** * Use a naive regular expression to detect JSX */function isProbablyJsx(text) {  return new RegExp(    [      "(?:^[^\"'`]*</)", // Contains "</" when probably not in a string      "|",      "(?:^[^/]{2}.*/>)", // Contains "/>" on line not starting with "//"    ].join(""),    "m",  ).test(text);}この isProbablyJsx は TypeScript のコードをパースする直前に、Prettier の入力の文字列全体に対して実行されています。そして、その戻り値によってパーサーに渡すオプションを切り替えます。まとめると「Prettier で TypeScript のコードをフォーマットするとき、入力の文字列全体に対して、JSX っぽいかどうかを判定する正規表現が実行されている」ということになります。(この関数の計算量は知らないですがおそらく)入力の文字列が大きくなると、それに伴ってこの関数の実行時間が増えます。isProbablyJsx を取り除く？isProbablyJsx という関数は無駄なわけではなく、明確な存在意義があります。なぜなら、TypeScript のパーサーや Prettier は、入力のコードが、通常の TypeScript なのかそれとも TSX なのかを知っている必要があるからです。したがって、ただ isProbablyJsx を取り除くことはできません。少なくともなんらかの方法で入力のコードが TSX であるかどうかを判定しなければいけません。Prettier の他の箇所では、TSX であるかどうかを判定するためにファイルの拡張子を使っています。単純に *.ts であれば通常の TypeScript、*.tsx であれば TSX、という風に判定しています。そこで isProbablyJsx を使っている箇所を、拡張子を使った判定に切り替えることを考えました。この方法は *.ts と *.tsx のファイルに限った場合、上手く機能します。しかし、TypeScript には *.mts と *.cts という拡張子もあります。これはそれぞれ Node.js における *.mjs と *.cjs に対応するものです。詳しくは teppeis さんの TypeScript 4.5 以降で ESM 対応はどうなるのか？ などの記事を参照してください。実はこの *.mts と *.cts には、TSX を書くこともできます。また、Prettier を API を使って呼び出した場合は拡張子がそもそも存在しません。これらの事情があるため、isProbablyJsx を完全に取り除くことはできませんでした。最終的には、次のようなロジックが採用されました。ファイルの拡張子が .ts の場合、通常の TypeScript のコードとしてパースするファイルの拡張子が .tsx の場合、TSX のコードとしてパースするファイルの拡張子が .mts や .cts の場合、まず通常の TypeScript のコードとしてパースし、失敗したら TSX のコードとしてパースするそれ以外の場合、isProbablyJsx で TSX かどうかを判定してパースするこれによって、ほとんどのユースケースにおいては isProbablyJsx が呼び出されることはなくなりました。この修正を実装した PR は Fix trailing coma print in type prameters, improve jsx parse by sosukesuzuki · Pull Request #14688 · prettier/prettier です。結果この PR の後で、さきほどと同様の手順で 0x を使って生成したフレームグラフが以下です。さきほどのフレームグラフと見比べると、奇妙な赤いブロック、つまり isProbablyJsx の呼び出しがなくなっていることがわかります。0xによって生成されたフレームグラフおわりにisProbablyJsx の呼び出しにかかっていた時間は、パースなどの他の重い処理と比べると大したものではありません。ですので、この改善は正直に言うとそれほど有意なものではなかったと思います。ですが、フレームグラフを眺めて、パフォーマンスに悪影響を及ぼしているであろう箇所を特定し修正する、という体験は楽しかったです。

フレームグラフを眺めて無駄な正規表現を消してPrettierのパフォーマンスをちょっとだけ改善する

先日、TypeScript-ESLintという OSS プロジェクトから $500 いただきました。ちなみに筆者は TypeScript-ESLint のチームに所属しているわけではありません。この記事では、改めて TypeScript-ESLint というプロジェクトの概要を説明すると共に、筆者が $500 いただいた経緯や、TypeScript-ESLint の運営状況について説明します。TL;DR資金に余裕があり、TypeScript-ESLint を使っている個人や企業は TypeScript-ESLint プロジェクトに寄付することを検討してください。TypeScript-ESLint への寄付は https://opencollective.com/typescript-eslint から行うことができます。一応明記しておきますが、筆者は今回 $500 いただきましたが今後も継続的にいただくわけではありません。筆者の収入をを安定させる目的でこの記事を書いているわけではありません。筆者の収入を安定させたい方は筆者の GitHub Sponsors から支援してください。TypeScript-ESLint とはESLint で TypeScript を扱うための一連のツールを含む OSS プロジェクトです。プロジェクトは GitHub で開発されており https://github.com/typescript-eslint/typescript-eslint から確認できます(一連のツールのほとんどは Nx を使った monorepo として管理されています)。ESLint はデフォルトの状態では ECMA-262 として標準化された JavaScript の構文と、JSX しか扱えません。したがって TypeScript で記述されたコードを扱うことはできません。ESLint には JavaScript 以外のコードを扱うためのカスタムパーサという仕組みがあります。そして、TypeScript-ESLint プロジェクトは ESLint で TypeScript を扱うためのカスタムパーサを提供します。これによって、我々は ESLint を使って TypeScript で記述されたコードを解析できるのです。また TypeScript-ESLint プロジェクトは、カスタムパーサの他にも TypeScript 用の ESLint プラグインなども提供しています。この ESLint プラグインには、TypeScript のための ESLint ルールが多く実装されています。このプラグインを使うことで、TypeScript を使った開発をより安全にできます。ESLint と TypeScript を併用する方法をより詳しく知りたい場合は、2 月 24 日発売の WEB+DB PRESS Vol.133 に詳しく書かせていただいたので、よろしければそちらを読んでみてください。WEB+DB PRESS Vol.133、どこよりも早い表紙画像です！TypeScript最新活用、速習Ruby 3.2、Tailwind CSS実践入門を大特集！2月24日発売です！#wdpress pic.twitter.com/TaHmqI7eyq— WEB+DB PRESS編集部 (@wdpress) February 6, 2023 $500 いただいた経緯筆者は TypeScript 4.5 以降、TypeScript の新しいバージョンがリリースされるたびに TypeScript-ESLint に対してそのバージョンをサポートするための PR を送っています。先日リリースされた 5.0 のサポートも実装しました。新しい構文をサポートする部分が大変なのはもちろんですが、TypeScript-ESLint は TypeScript の Compiler API を使っているので、ただバージョンを上げるだけだと壊れることが多いです。そのあたりを気合で修正していく作業をしています。場合によっては作業範囲が TypeScript 本体へのバグ報告や Microsoft の Rushstack に及ぶこともあり、面倒くさいことも多いです。その貢献が認められたため、今回 $500 いただきました(いきなりメールが来ました)。TypeScript-ESLint の運営状況少なくとも外部からは TypeScript-ESLint は 2~4 人のメンテナによって維持されているように見えます。またウェブサイトを主として見るメンバーも別にいるように見えます。TypeScript-ESLint は多くのルールが実装された ESLint プラグインをメンテナンスしているという都合があるため、issue のトリアージやバグ修正に対するコストが大きいようです。https://opencollective.com/typescript-eslint を見ると、総調達金額は $34,424 となっています。これを少ないと見るか多いと見るかは主観に依りますが、Babel は $1,127,389、ESLint は $572,857、webpack は $1,391,904 です。Prettier ですら $88,695 です。個人的な見解としては、TypeScript-ESLint をメンテナンスする作業へ報酬を支払うための十分な金額だとは思えません。まとめ経済的な余裕があり、TypeScript-ESLint を使っている個人や企業は TypeScript-ESLint プロジェクトに寄付することを検討してください。TypeScript-ESLint への寄付は https://opencollective.com/typescript-eslint から行うことができます。TypeScript-ESLint に集まった資金は、TypeScript-ESLint のメンテナたちに報酬として支払われる他、チームメンバではない貢献者に対しても一部支払われます(今回の筆者のように)。また https://typescript-eslint.io/ の下部を見ると Financial Contributors として企業のロゴが掲載されています。一定の額を超える寄付をした企業のロゴを掲載してくれているのだと思います(筆者はロゴ掲載のロジックを把握していないので、もし寄付するとなったら事前に確認すると良いと思います)。一応明記しておきますが、筆者は今回 $500 いただきましたが、今後も継続的にいただくわけではありません。筆者の収入をを安定させる目的でこの記事を書いているわけではありません。筆者の収入を安定させたい方は筆者の GitHub Sponsors から支援してください。

TypeScript-ESLintから $500 いただきました

Node.js の import specifier と ECMAScript の ImportSpecifier先日 Firefox の JavaScript エンジンである SpiderMonkey の公式ブログに Import Maps についての記事が投稿された。https://spidermonkey.dev/blog/2023/02/23/javascript-import-maps-part-1-introduction.htmlこの記事は、そもそも ECMAScript Modules とは何かというところから入り、Node.js のモジュールシステムの歴史やブラウザの ECMAScript Modules との関係などを説明した後、本題である Import Maps について解説している。短い時間で読める面白い記事なので、まだ読んでいない人はぜひ読んでほしい。この記事の脚注に興味深いことが書かれていた。In Node.js, it’s called import specifier, but in ECMAScript, ImportSpecifier has a different meaning.日本語に翻訳すれば「それは、Node.js では import specifier と呼ばれていますが、ECMAScript での ImportSpecifier とは別の意味です」ということである。この脚注の文脈における「それ(it)」とは import foo from "bar" における "bar" の部分、すなわち JavaScript の Import 宣言のモジュールを指定する部分のことである。つまり、Node.js では import foo from "bar" における "bar" の部分のことを import specifier と呼ぶが、ECMAScript の仕様での ImportSpecifier は別のものを指しているということだ。では、ECMAScript の仕様の ImportSpecifier は何を指しているのだろうか。先に答えを言ってしまうと import foo from "bar" における foo の部分である。具体的なコードで見る簡単に言ってしまえばこれで終わりだが、ECMAScript にはいくつかの Import の書き方がある。ここからは更に詳しく、それぞれの書き方の中で ImportSpecifier が具体的なコードのどの部分に対応するのかを解説する。ECMAScript ではこのあたりの構文を表現する要素として、ImportSpecifier の他に ImportList、ImportBinding、ModuleExportName などがある。実際には他にももっと多くの構文の要素があるのだが、ここではこれらの 4 つに絞り具体的なコードのどの部分にどの構文の要素が対応するのかを画像として見ていく。(画像を作ってから思ったがやや見にくいので頑張って見てほしい)ちなみに、Node.js での import specifier に相当するのは ECMAScript では ModuleSpecifier である。おわりに筆者は ECMAScript の ImportSpecifier のことはもとから知っていたので、Node.js の import specifier のことを知って驚いた。この違いによって困ることはなさそうだが。参考ECMA-262https://tc39.es/ecma262/#prod-ImportSpecifierhttps://tc39.es/ecma262/#prod-ImportedBindinghttps://tc39.es/ecma262/#prod-ImportsListhttps://tc39.es/ecma262/#prod-ModuleExportNamehttps://tc39.es/ecma262/#prod-ModuleSpecifierNode.jshttps://nodejs.org/api/esm.html#import-specifiersSpiderMonkeyhttps://spidermonkey.dev/blog/2023/02/23/javascript-import-maps-part-1-introduction.html

Node.js と ECMAScript の Import Specifier は意味が違うらしい

つい先程、https://github.com/prettier/prettier/pull/14212 という Pull Request を next ブランチにマージした。これは DefinitelyTyped で管理されていた Prettier の TypeScript 用の型定義を Prettier 本体のリポジトリへと移す Pull Request だ。この Pull Request によって、v3 からは @types/prettier をインストールする必要がなくなる。JavaScript で書かれたライブラリをメンテナンスしている他の人の意思決定の参考になるように、この記事ではこの変更を行ったモチベーションや手法について説明する。Prettier の JavaScript API の型定義の現状Prettier は JavaScript から使える API を提供している。たとえば、次のようにして Node.js や Web ブラウザの JavaScript から Prettier を使ってコードをフォーマットできる。// これは v3 で予定されている API であり、v2 とは若干異なることに注意import * as prettier from "prettier";const formatted = await prettier.format(  `console.log("Hello, Worlld");`,  { parser: "babe"; });Prettier のソースコードは TypeScript ではなく JavaScript で記述されている。そのため、TypeScript 用の型定義ファイル(*.d.ts)を生成できず、npm で配布している prettier パッケージには型定義ファイルが含まれていない。一応、ソースコードの一部は JSDoc コメントを使って型が明示されているが型定義の生成に使えるほどちゃんとした運用はされていない。しかしそれでは TypeScript から Prettier の JavaScript API を呼び出すときに不便なので、DefinitelyTyped に型定義ファイルを置いている。DefinitelyTyped に置かれている他のパッケージの型定義と同じように npm i @types/prettier でインストールできる。DefinitelyTyped のデメリットDefinitelyTyped は JavaScript で書かれているパッケージに対して型定義ファイルを定義し、別のパッケージとして配布できる仕組みである。これは、リポジトリ本体側がすでにメンテナンスされていなかったり、TypeScript に対応することに後ろ向きであったりする場合にも型定義ファイルを提供できるため便利である。しかしながら、いくつかの大きなデメリットがある。まず、リポジトリが巨大すぎる。DefinitelyTyped のリポジトリには無数の JavaScript ライブラリの型定義が含まれている。そのため git clone や git pull の実行には時間がかかるし、テキストエディタや GitHub での閲覧体験が悪い。これは、積極的に型定義をメンテナンスすることの妨げになる。次に、alpha バージョンや beta バージョンのための型定義を配布するのが難しい。Prettier は現在 v3 の開発を進めていて、すでに alpha バージョンとして npm に配布されている。以前書いた記事で紹介したように、Prettier の v3 では API が破壊的に変更される予定だ。これはプラグイン開発者にとっては大きな影響がある。そのためいくつかのプラグインの開発者はすでに alpha バージョンを使って v3 対応の準備を進めてくれている。TypeScript で実装されたプラグインの開発者は当然ながら v3 用の型定義を使って開発を進めたいと考えるが、@types/prettier として配布されているのは v2 用の型定義である。DefinitelyTyped の仕組みの上で alpha バージョン用の型定義を配布する方法があればよかったのだが、見つけられなかった。これらの理由から Prettier の型定義を DefinitelyTyped から本体リポジトリに移すことを決定した。特に、プラグイン開発の体験は重要なので 2 つめの理由が決め手となった。型定義ファイルを本体のリポジトリに移すhttps://github.com/prettier/prettier/issues/14033 という issue を作成した。この issue では、この記事ですでに述べたような DefinitelyTyped を使った型定義の管理のメリットやデメリットなどの概略が説明されている。インターナルなチャットで共有したところ他のメンテナーからの支持が得られたので作業を始めた。作業としては、DefinitelyTyped に含まれている Prettier の型定義ファイルを本体のリポジトリに移し、v3 で予定されている破壊的変更を反映するだけである。型定義ファイルの内容はほとんどコピペで良いのだが、他にいくつか考えなくてはならないことがあった。型定義ファイルをどこに配置するか、どうビルドするかバンドルせずに JavaScript ファイルをそのまま配布するようなパッケージであれば、対応する JavaScript ファイルと同じ階層に型定義ファイルを配置してそのまま配信すれば良いだろう(たとえば、Sindre Sorhus の提供する Node.js 用ライブラリの多くはそのような構成になっている)。しかし Prettier はソースコードをバンドルし ./dist 以下に吐き出し、それを npm にパブリッシュしている。そのため *.d.ts ファイルをどこに配置するか考える必要があった。自分が最初に考えたのは、ビルドスクリプトが置かれている ./scripts/build 配下に適当なディレクトリを切って *.d.ts を置き、ビルド時にそれをそのまま ./dist 以下にコピーするという方法だった。その方法でも上手く機能したが、コードレビューの段階で「*.d.ts ファイルは、それに対応する各 JavaScript ファイルの隣において、そこからビルド時に ./dist に移動するほうが良い」という指摘を受けた。その場合 ./src 以下に型定義ファイルが配置されることになり、開発するときにも型定義ファイルに注意が向くだろうと考えたため、最終的にはその方法を採用した。また、Prettier では ./dist に吐き出す package.json もビルド時に生成するため、型定義ファイルのコピーの他に、TypeScript 4.7 からサポートされた Conditional Exports の types フィールドを使って各エントリポイントに対応する型定義ファイルを指定するようにしている。テストはどうするかDefinitelyTyped には型定義をテストする仕組みがある。型定義を本体リポジトリに移すにあたって、自分たちでそのテストの仕組みを考える必要があった。最初に検討したのは https://github.com/SamVerschueren/tsd というツールだ。これは *.d.ts ファイルをテストするためのツールで、自分たちの目的にぴったりだろうと考えた。しかし実際にはディレクトリの構成が縛られてしまうなどの制約があった。前述のとおり Prettier はやや特殊な構成をとっているため、このツールをそのまま使うことはできなかった。最終的には、Jest から TypeScript Compiler API を実行し https://github.com/TypeStrong/ts-expect というライブラリを使って型を検証するという方法を選んだ。ts-expect を使うと、次のようにしてある値がある型であることをチェックできる。import { expectType } from "ts-expect";expectType<string>("test");expectType<string>(333); // コンパイルエラーになるts-expect を使った TypeScript のコードに対して TypeScript Compiler API を使って型チェックを行い、diagnostics メッセージの数が 0 であれば型エラーが存在しないということなので、テストをパスしたとみなす。実際のコードは https://github.com/prettier/prettier/blob/next/tests/dts/unit/run.js にあるので、詳細に興味がある人はそちらを参照してほしい。おわりにこれでプラグインの開発体験が多少改善されるだろう。最後に、Prettier が継続して開発されることに関心があり、金銭的に余裕がある企業や個人は https://opencollective.com/prettier から Prettier に寄付することを検討してほしい。

DefinitelyTyped がつらいので Prettier の型定義を本体のリポジトリに移すことにした

Prettier がデフォルトでインデントのためにタブを使うべきかどうか、現時点での私の考えです。useTabs のデフォルト値を true にするという提案Prettier には useTabs というオプションがあり、インデントのためにタブを使うかどうかを boolean で指定できます。デフォルトでは false が設定されています。2 年ほど前に Prettier v2 の準備をしているときに Change useTabs to true by default という、useTabs のデフォルト値を true に設定することを提案する issue が作成されました。この issue での議論は活発に行われ、建設的なコメントや逆に全く建設的でない人格を批判するようなコメントなど、実に多くの意見が寄せられました。この issue が作成れたのは v2 をリリースする直前だったので、私は「まだ十分コンセンサスが得られていないように思うから、少なくとも v2 でこのような変更を行うのは難しいと思う」という理由でこの変更を v2 には実装しませんでした。最近は v3 の準備をしており、「v2 のときは無理だったけど、あれからもう二年経ってるし、賛成している人も多いから再度考えてほしい」というようなコメントが投稿され、再びこの issue は活発になりました。理想私達はこの問題に対してどのように対処するべきなのでしょうか。インデントにタブを使うアクセシビリティ上の利点 で説明したようにタブにはスペースと比べてアクセシビリティ上の利点が存在します。ですので理想的には、Prettier はデフォルトでタブを使うべきだと思います。Prettier のようなツールはできるだけ多くの人に対してアクセシブルであるべきだ、というのが個人的な考えです。「useTabsは設定できるんだから、タブを使いたい人が勝手に true にできるんだからそれでいいじゃん」という意見もありますが、私はこれには反対です。デフォルトでアクセシブルになっているのが理想だと考えています。現実「Change useTabs to true by default」には 344 もの :+1: がついており、コメントを見ても多くの人が賛成しているように見えます。しかし私は、多くの人が賛成しているように見えているだけだと考えています。わざわざ GitHub のこの issue までたどり着き何かしらの反応を残す人のほとんどは、この問題について強い興味がある人たちだと思います。Prettier のユーザーのほとんどはこの issue に興味がないか、あっても気づいていません。スペースを使うことにこだわりがある人もいますし、こだわりはないものの変更を嫌う人もいます。もしも私達がこの提案を受け入れた場合、そのような人たちから「もとに戻せ」とか「こんな議論があったなんて知らなかった」といった厳しい言葉が飛んでくることでしょう。私はそれが本当に嫌です。疲れるしやる気を大きく削がれることになるでしょう。私にとって最も問題なのは、消耗してオープンソースソフトウェアに向き合えなくなることです。なので個人的には、この提案を受け入れたくありません。ありえない話ですが、逆に言えば Prettier を使っているすべてのユーザーがこの変更に賛成するならば、私も喜んで賛成します。おわりに多くのユーザーを抱えているオープンソースソフトウェアにおいて大きな変更を行うという意思決定は本当に重いものだということを、身を持って感じています。よりアクセシブルであるべきだと本心で思っているのに、そのための変更によって多くのユーザーに影響をあたえるのが怖いのです。この議論はまだ決着していないので最終的にどうなるかはまだわかりません。悩んでいます。

Prettierはデフォルトでインデントのためにタブを使うべきなのだろうか

この記事には誰かを攻撃したり差別したりする意図はありません。もし不適切な表現を見つけた場合は修正しますのでご連絡ください。「インデントにタブとスペースのどちらを使うのか」というのは昔から何度も議論されてきた問題です。最初に明確にしておきますが、私個人としてはタブを使おうがスペースを使おうが、プロジェクト内で統一されていれば構いません。しかしタブには、スペースにはないアクセシビリティ上の利点が存在します。タブの最大の特徴は、表示幅を自由に設定できることです。ご存知のとおり、一つのタブに対して実際の見た目としてどのくらいの幅が確保されるかは、テキストエディタなどのコードを閲覧する環境の設定次第です。たとえば、GitHub は一つのタブをデフォルトではスペース 8 個分の幅で表示しますが、 https://github.com/settings/appearance から自由に変更できます。大きなサイズのフォントを使っていてインデントを小さくしたい人はタブ表示幅を 1 にすることができますし、横幅の大きなディスプレイを使っていてインデントを大きくしたい人はタブ表示幅を 8 にすることができます。この性質は、視覚に障害がある人たちにとって重要なのだそうです。また、点字ディスプレイを使ってコードを書いている人にとっては、より大きな問題になるそうです。インデントのために使われる一つ一つのスペースは、点字の領域一つ分を消費するので、1 レベルのインデントあたり 4 スペース使うプロジェクトの場合、3 レベルのインデントがあるコードを読み書きするとき、インデントのためだけに 12 個の点字のための領域を消費することになります。タブを使っている場合はそのレベル分の必要最小限の消費で済みます。私には視覚障害はなく、点字ディスプレイを使ったこともありません。ですので実際にそのような立場の人々にとって、インデントのためにスペースを使うことがどのくらい難しくアクセシビリティを毀損してしまっているのかはわかりません。もしもこの記事を読んでくれた人の中でそのような環境でコードを書いたことがある人がいたら、お話を聞かせていただきたいので私に連絡をください。(Twitter の DM もしくはメール)。参考Default to tabs instead of spaces for an 'accessible first' environment · Alexander SandbergNobody talks about the real reason to use Tabs over Spaces : javascriptChange useTabs to true by default · Issue #7475 · prettier/prettier

インデントにタブを使うアクセシビリティ上の利点

先日 Babel のメンテナーとして知られる Nicolò Ribaudo 氏が次のツイートを投稿した。We finally finished migrating the Babel monorepo from Flow to TypeScript!It has been a very long process started by @z_bodya, and after migrating package-by-package @JLHwung just opened this PR 😄 pic.twitter.com/WKXxV8x2MY— Nicolò Ribaudo 🏳️‍🌈 • 💙💛 (@NicoloRibaudo) July 23, 2022 そう、JavaScript のトランスコンパイラである Babel のソースコードが Flow から TypeScript へと完全に移行したのだ。ユーザーには何の影響もない最初に名言しておくが、Babel のソースコードが Flow から TypeScript に移行したことによる Babel のユーザーへの影響はない。もしこの変更によって何かしらユーザーに影響があったとしたら、偶然バグが発生したか偶然バグが修正されてしまったかのどちらかである。Flow の現在と使い続けるリスクもしかしたら最近フロントエンドを触り始めた人は Flow についてほとんど知らないかもしれない。ちなみに筆者も Babel を開発する目的以外で使ったことはない。Flow は Meta(旧 Facebook)によって開発されている JavaScript に静的型を導入するための型チェッカである。わかりやすく言えば TypeScript と同じようなものだ。JavaScript のコード中に型アノテーションを記述すると、Flow が型チェックと型の消去を行う。昔は一世を風靡していた(?)ようだが今では TypeScript にその立場を譲っている。多くのユーザーが Flow から TypeScript への移行を行っていることがパブリックインターネットからも見て取れる。下記の記事らは「Flow TypeScript 移行」と Google 検索した結果上位に表示されたものだ。探せばもっとあるだろう。開発を止めずに Flow を TypeScript に移行する手法 - freee Developers HubFlow から TypeScript に移行しました - てくすたママリの WebView を JavaScript + Flow から TypeScript に移行しました - コネヒト開発者ブログFlow/PostCSS の大規模プロジェクトを TypeScript/emotion に移行して数万行のプルリクを投げた話 - JX 通信社エンジニアブログその一方で Meta 社内ではまだまだ現役で使われているようである。2021 年 5 月に Flow チームの Engineering Manager であるVladan Djeric 氏によって投稿されたブログ記事で今後の Flow の方向性と OSS としてのあり方が説明されている。Clarity on Flow’s Direction and Open Source Engagementこの記事によると、最近の Flow は Meta 社内の大規模な JavaScript コードベースの開発からの要求に耐えられるような高い型安全性とパフォーマンスを実現するために単なる「型付き JavaScript」ではなくなっており、型アノテーション以外の構文も追加してくとのことである。さらに、外部の開発者のみからの要求を受け入れるだけのリソースがないため基本的にはそのような要求は受け入れない方針のようだ。Meta からしてみれば、社外からの利用を歓迎しているというわけではないのだろう。(余談だが、Prettier は Flow をサポートしているものの、Flow の新しい言語機能に対応するための Pull Request のほとんどは Meta の Flow チームの開発者によって実装されている。)筆者個人としてはこの決定は残念だと思うが、もちろん悪いものではない。しかしながら、Babel のようなオープンソースのプロジェクトが Flow を使い続けるという判断をするのはリスクが高い。Babel の TypeScript 移行の流れBabel には強力なプラグインの仕組みが備わっており、ほとんどの機能が公式からのプラグインという形で提供されている。そして、それらの 150 を超えるプラグインはすべて https://github.com/babel/babel のリポジトリで管理されている。Babel のソースコードをすべて Flow から TypeScript に移行するということは、150 を超えるパッケージに対して手を加える必要がある大規模な作業になる。この大規模な作業は Babel のコントリビューターの一人である @zxbodya 氏によって開始された。2020 年 5 月に、@babel/parser 以外の全てのパッケージを一気に Flow から TypeScript へと移行する一つの巨大な Pull Request が作成された(@babel/parser は実装が複雑なので他のパッケージと比べて Flow から TypeScript に移行するのが困難だった)。Migrate Babel from Flow to TypeScript (except Babel parser) by zxbodya · Pull Request #11578 · babel/babel全ての Flow のコードを TypeScript に移行するのは途方もない作業である。そこでこの Pull Request では、@zxbodya 氏が開発した flowts というツールが使われている。この Pull Request は巨大でレビューが困難であったためパッケージごとに Pull Request が分割されることになった。その結果として 50 個以上の Pull Request が作成された。最後には @babel/parser を TypeScript に移行する Pull Request が Babel のコアチームメンバーである Huáng Jùnliàng 氏によって作成され、Babel の TypeScript の移行作業が完了した。Convert @babel/parser to TypeScript by JLHwung · Pull Request #14783 · babel/babelその後には Flow での型チェックのためのスクリプトを消し、 flow-bin を依存から削除する Pull Request が作成された。chore: remove flow check scripts by JLHwung · Pull Request #14785 · babel/babelBabelからFlowに関する依存が削除されたときの差分おわりにBabel が Flow から TypeScript に移行したことはユーザーへの影響はないが、Babel の開発に関わる人からしたら大きな一歩だろう。そして、Babel はまだまだ開発されている。最近では SWC や esbuild などが開発され、近い未来に Babel はその役目を他のソフトウェアに明け渡すのかもしれない。しかし、個人的には現段階における Babel のクォリティは高いと思っている。もし Babel を使って後方互換性を維持しているプロジェクトから大きな利益を得ている人がいたら、Babel への寄付を検討してほしい。https://github.com/sponsors/babelhttps://opencollective.com/babel

Babel が Flow から TypeScript に移行した

医療 AI スタートアップ Ubie(ユビー) に 3 月に入社していました。この 7 月で入社してから 4 ヶ月になります。本当はもっと早く入社エントリを書きたかったのですが、だらけていたらなんと 4 ヶ月経ってしまいました。入社ツイート誰？JavaScript やフロントエンドを触っているエンジニアですこれまでは筑波大学の情報学群情報科学類(学部)に通いつつ業務委託として働いたり、Prettier や Babel などのオープンソースプロジェクトのメンテナーやコミッターをやったりしていました。より興味がある人は2021 年の振り返りブログや、私の Twitter を見ていただけると良いと思います(Twitter には日常的なことを書き込まないようにしているのでどういうエンジニアなのかはわかりやすいと思います)。Ubie って？Ubie は 2017 年にエンジニアの久保と医師の阿部が創業したスタートアップです。ウェブサイトは https://ubie.life です。生活者向けの症状検索エンジン ユビーや医療機関向けのユビー AI 問診 などを提供しています。なんで就職したの？Ubie は私にとって初めての正社員としての勤務先です。つまり、転職ではなく就職です。私が Ubie に就職した理由は大きく分けて 3 つあります。1 つめは、医療というドメインは難しくて、楽しそうで、意義があるものだと思ったからです。医療はすでにたくさんの頭の良い人々が参入しているにも関わらず山積みの課題があり、それを解消することが多くの人に良い影響を与えるドメイン領域だと思います。エンジニアとして、そういった難しくかつ意義のあるドメインに対して仕事をするのは楽しそうだと思いました。2 つめは、一生懸命働く体験をしてみたかったからです。一生懸命に働いている人と、同じ立場で、大きな目標に向かって一生懸命に働くということに対する憧れがありました。これまでもインターンや業務委託として働いていましたが、それだと当事者意識を持つのが難しく、少なくとも 1 回は一生懸命に働いてみたい！と思っていました。3 つめは、Ubie に対して良い印象を持っていたからです。後述しますが私は過去にインターンや業務委託として Ubie で働いていたことがあります。また Ubie はその独特な組織設計や評価についての考え方などを積極的に発信しています。私自身の経験と、Ubie の対外的な情報から、少なくとも自分にとって納得できそうな「意思決定への姿勢」を持った会社だと感じました。前も Ubie で働いてなかった？以前から私と交流をしていてくれた方は「あれ、前も Ubie で働いてなかった？」と思うかもしれません。実は私は正社員として入社する前に Ubie でインターンと業務委託として働いていました。2018 年の 12 月から 2020 年の 5 月までの間はインターンとして働いていました。高校生のときに勉強会をきっかけに知り合ったたろうさんさんから誘ってもらってインターンとして働き始めました。2020 年 5 月に「もっと Web 技術に強い人と一緒に働きたいな！」と思いインターンを辞めました(当時の Ubie には Web 技術に詳しい人が少なかった)。2021 年 4 月から 2022 年 2 月までの間は業務委託として働いていました。同僚の yukukotani が zenn に書いていたのですが、Ubie では 2021 年の 4 月から https://ubie.app を Nuxt.js から Next.js に移行する作業が行われていました。https://zenn.dev/yuku/articles/a9edd53e13bb26そのお手伝いのために業務委託として再び働き始めました。この記事中に出てくる以前に業務委託をしてくれていてフロントエンドに詳しくて仲が良い友人というのが私です。移行作業が終わったあとはパフォーマンスチューニングやビルド改善などのフロントエンド周りの改善をやっていました。この 4 ヶ月は何をやっていたの？入社してすぐは、業務委託として行っていた仕事の続きのような形で https://ubie.app のフロントエンドの改善を行っていました。リファクタリング、パフォーマンスチューニング、ビルド改善、コードレビューなどです。しばらくしてから、もっと抜本的な設計の改善が必要だということで静的解析や GraphQL の Fragment Colocation を使ったフロントエンドの設計や PoC 実装を行っていました。ここ 2 ヶ月の間は、事業上の理由と Ubie のシステムのより広い部分を触って把握しておきたいという自分の理由から、複数のシステムが絡む製薬事業の開発を行っています。得意ではないバックエンド開発をやったり、初歩的なデータ分析のための SQL を書いたり、もちろんフロントエンドも書いたりと技術的にはいろんなことをやっています。4 ヶ月働いてみてどう？技術的、組織的な色々な課題はありつつも楽しく働けています。特に、データエンジニアと近い距離で働けるのが新鮮で楽しいと感じています。これまではフロントエンドやバックエンドのエンジニアやデザイナーと一緒に働くことがほとんどでした。データエンジニアの人たちは、自分が今まで一緒に働いたことのある職種の人たちとはまた違った視点で物事を見ていて、そのような視点は Ubie でのプロダクト開発においては重要です。また、個人としてデータエンジニアリングの技術に強い興味が湧いてきました。最近は会社のデータエンジニアに色々聞きつつ勉強しています。また入社のモチベーションの一つであった「一生懸命働く体験をしてみたい」というのも今のところは達成できていそうです。これから時間が経っていくにつれて考え方が変わっていくとは思いますが現段階では、当事者意識を持って一生懸命働くことに対して素直に楽しいと感じています。オープンソースはどうするの？続けます。趣味なので。最近 https://sosukesuzuki.dev/posts/2022-maintainer-month/ に書いたように、強いやる気があるわけではないものの最低限の OSS 活動は続けています。なので私の就職に伴って Prettier のアップデートが滞るということはないはずです(もし滞ってしまったら世の中が dprint や deno fmt、Rome Formatter に移行しはじめる気がするのでそれはそれで良いかもしれません)。大学はどうするの？続けます。せっかく入学できたので時間がかかっても卒業はしたいと考えています。最近は線形代数や微分積分と戦っています。他の仕事はどうするの？Ubie に入社したにも関わらず https://cybozu.github.io/frontend-expert に記事を書いているのを見て不思議に思った方もいるかもしれません。サイボウズではまだ副業の業務委託として仕事を継続させてもらっています。今後も継続したいと考えているので、良い働き方を模索中です。We are hiring!!一緒に働いてくれる仲間を募集しています。興味がある方は Twitter 等で連絡をください！Ubie Discovery 採用サイト

Ubieに入社して4ヶ月が経ちました

@azu さんのブログ記事 Maintainer Month: オープンソースをメンテナンスするコツ を読んで GitHub が Maintainer Month というイベントを主催していることを知りました。自分は Maintainer Month の Sponsoring の対象でありませんが、自分がオープンソースのプロジェクトをメンテするときに考えていることを書き残しておこうと思います。オープンソースガイド などにはすごいためになることが書かれていますが、積極的な内容で自分にとっては読むだけで疲れてしまうような内容でもあります。なのでこの記事ではあえて自分が普段考えていることの中でも消極的なことについて書いてみます。オープンソースのメンテナンスに疲弊している人や、オープンソースに貢献している人、もしくは貢献しようと思っている人に「こんなゆるい気持ちでやってる人もいるんだ」と思ってもらえれば嬉しいです。「もっとまじめにやれ」と思う人もいるかもしれないけど。普段のオープンソース活動自分は主に JavaScript のコードフォーマッター Prettier のメンテナーとして活動しています。その過程で Babel や typescript-eslint などの Prettier が依存しているプロジェクトにも積極的に貢献しています。自分が Prettier に関わりはじめたのは 2019 年 5 月頃なので 3 年くらい関わり続けていて、この 3 年間は世界で 2 番目に Prettier にコミットしたようです(通算では 4 番目)。特に 2021 年以降はアクティブメンテナーが減ったため、リリースブログの執筆やリリース作業なども行うようになりました。実質的に最近の Prettier に必要最低限のことをだいたい全部やっています。考えていることこの記事に書いたことはわざわざ意識しているわけではなく、数年間やっていたら自然とこういうスタンスになっていました。最低限をデリバリーするみんなが求める最低限の Prettier をデリバリーし続けることを頑張っています。あまりにも変なフォーマットはしないとか、あまりにも遅くないとか、新しい構文も自然にフォーマットできるとか、その程度のものです。それ以上のことができたら自分の中では特別立派なことだと考えており、基本的にはそういうことはしていません。たとえば Prettier 2.7 で実装した --cache オプション とか、Prettier 2.6 でバンドルサイズをたくさん削った とかは特別立派な類に入ります。逆に TypeScript の新しい構文のサポートは最低限のものに含まれます。過度に人に期待しないオープンソースのプロジェクトをやっていると当然他人とコミュニケーションをとるわけですが、過度に人に期待していません。Prettier に関わっている人は自分の知る限りみんなボランティアなので、やらない方が人間にとって自然な状態だと思っています。「いつまでにやります！」みたいなコメントは「（その当時は）やる気があります！」という程度に受け取っています。あんまり人のことを考えないIssue や Pull Request は大変ありがたく思っていますが、必要以上に意識しないようにしています。悪く言えば適切に無視しています。Issue や Pull Request を見るのは自分にとってはコードを書くことに比べてコストが高く、あまり楽しくありません。趣味のオープンソースのプロジェクトで疲れたくはないので必要以上には見ません。人に任せる積極的にコメントをくれる人に Issue をトリアージする権限を与えたり、興味がありそうな人に関連するパッケージのメンテナンスを託すなど、自分が得意じゃないことややりたくないことについては積極的に人に任せるようにしています。もらえるものはもらっとく寄付のお金などはもらえるならもらっておこうと思っています。上述の通り雑にやっているとは言え、余暇時間を潰してみんなの役に立つことをしているのは事実だと思うので、いただけるものはありがたくいただいています。なんだかんだお金があると時間的な余裕を作りやすくなるので Prettier の持続に興味がある人は https://opencollective.com/prettier から寄付をしていただけるとありがたいです。頭を使う作業のフォールバック先「やらなきゃいけないことがいっぱいあるのに絶対やりたくない！！」なんてことありませんか？私にはよくあります。自分にとってオープンソースのための作業は「コードを書きたいしそのための集中力はあるけど、やらなきゃいけないことは絶対やりたくない！！」というときにやることになっています。私はかなり自堕落な性格なのでそういうタイミングが頻繁に訪れます。ちなみにこの記事の執筆も自分にとってはオープンソース活動の一貫ですが、明日に控えた期末試験の勉強がやりたくなさすぎるので書いています。まとめあんまり感情を持たずに淡々とやりたいことを優先してやっています。みんなが求める最低限の Prettier にとってどうしても必要な場合に限ってやりたくないこともやります。本当はもっと積極的にやったほうがいいのだろうとも思っていますが、疲れてメンテナンスできなくなることに比べたら雑にやるほうがマシだと考えています。

オープンソースをメンテするときに自分が考えていること

この記事では Type Annotations プロポーザルの概要とモチベーションについて説明する。概要Type Annotations プロポーザルは 2022 年の 3 月 9 日に Microsoft の TypeScript チームの Program Manager である Daniel Rosenwasser 氏のブログ記事 A Proposal For Type Syntax in JavaScript で発表され、2022 年 3 月の TC39 ミーティングで Stage 1 になった。Type Annotations プロポーザルは JavaScript に TypeScript のような型注釈の構文を導入する。たとえば、次のような型注釈を持つ関数宣言などが可能になる。function hello(name: string): void {  console.log(`Hello, ${name}`);}現段階では Enum や Namespace、Parameter Properties などの一部の機能を除くほとんどの TypeScript の型の構文が仕様に含まれている。このプロポーザルの重要な点は型注釈の記述は可能になるが、実のところそれらはコメントのように振る舞い、実際に動作には全く影響を及ぼさないというところである。したがって、上で定義した hello 関数を次のように呼び出しても問題なく動作する。hello({ prop: 1 });型注釈に基づいた実際の型チェックについては外部のツール(テキストエディタや CLI)で行うことになる。モチベーションFlow/TS のトランスパイルなしでの実行このプロポーザルの主なモチベーションは、開発者が書いた TypeScript や Flow などの静的型付け JavaScript をトランスパイルなしで実行できるようにすることである。我々が普段 TypeScript コンパイラで行っているトランスパイルは大きく２つに分けられる。1 つはダウンレベルコンパイルである。たとえば const foo = "foo"; を var foo = "foo"; にするような処理だ。もう 1 つが型の消去である。たとえば const foo: string = "foo"; を const foo = "foo"; にするような処理だ。そして近年、ダウンレベルコンパイルの必要性は低くなってきている。なぜなら、フロントエンドではエバーグリーンブラウザが主流になっており、バックエンドでは Node.js や Deno が十分に新しい V8 を使っているからだ。JavaScript が動作する環境では、大体の場合新しい JavaScript が動作するような世界になってきている。そして Type Annotations プロポーザルによって型の消去も不要になれば、トランスパイルそのものが不要になるというわけだ。JSDoc コメントの延長線としての Type Annotationsこれとは別の文脈として、JSDoc コメント的な使い方における利便性の向上といったモチベーションもある。実は TypeScript コンパイラは JavaScript 中に書かれた JSDoc コメントを使った型チェックができる。これによって TypeScript の環境を本格的に構築しなくても型チェックの恩恵にあずかることができる。たとえば筆者がメンテナンスしている Prettier は JavaScript で書かれているが、一部のコードでは JSDoc コメントを使って型を明示して TypeScript コンパイラを使って型チェックを行っている。しかし JSDoc コメントは冗長であり、複雑な型を表現するのが難しいなどの問題がある。Type Annoatations プロポーザルがあればこれらの問題を解消できる。感想筆者個人としては「理想としては共感できなくはないが、現実的には不可能に近いのではないだろうか」というような印象を受けた。まず、トランスパイルというかビルドステップを消し去るにはモジュールバンドラーをどうにかしないといけない。ブラウザが ECMAScript Modules を解釈できるようになった今、モジュールバンドラーの役割はダウンレベルコンパイルではなくパフォーマンスの改善になっている。そこに関しては Type Annoataions ではカバーできない(Subresource loading with Web Bundles に期待したい)。さらにガバナンスの問題もある。TypeScript のサブセットの構文が TC39 によって ECMA-262 に組み込まれたとして、その後の TypeScript と TC39 の関係はどのようになっていくのだろうか。標準化が足かせとなり TypeScript 側の進化が遅れることも考えられるし、TypeScript 側だけが進化して標準化が遅れてしまい結局みんな TypeScript をコンパイルして使うような未来も考えられる。「開発者の書いたコードがそのまま動く世界」を実現するためには Type Annotations プロポーザルは必要なステップだと思う。しかしそのために解消しなければならない難しく現実的な課題が多い。ちなみに筆者は書き捨てのスクリプトを書くときに JavaScript + JSDoc で書くことが多いのでそういうときに Type Annotations があったら便利だとは思う(この記事を書きながら思ったがそういうときは Deno を使えばいいかもしれない)。この記事ではざっくりと Type Annotations についか解説したが、詳細については https://github.com/tc39/proposal-type-annotations を自分自身で読んでほしい。FAQ には結構興味深いことが書かれている。参考リンクhttps://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/https://github.com/tc39/proposal-type-annotationshttps://github.com/tc39/notes/tree/main/meetings/2022-03

JS に TS のような型注釈を書ける Type Annotations プロポーザル

実は先日リリースした Prettier 2.6 では前のバージョンである 2.5.1 と比べてバンドルサイズが 3MB ほど減っています。Prettier 2.5.1 のサイズ(20.0MB)Prettier 2.6.0 のサイズ(16.9MB)リリースブログで言及したとおり Prettier 2.6 ではモジュールバンドラーを Rollup から esbuild に移行したので、その影響かと思われるかもしれませんが実はそれだけではありません。esbuild への移行によって減ったバンドルサイズはそれほど大きくはありませんでした。バンドルサイズが 3 MB 減ったのは泥臭いチューニングをいくつか行った結果なのです。この記事では Prettier 2.6 で実施したバンドルサイズを減らすテクニックを紹介します。きっかけライブラリのサイズは大きいより小さい方が当然良いですが、その重要度はライブラリによって異なります。たとえばブラウザで動かす目的で開発された UI ライブラリにっとてはサイズが小さいことは重要です。しかし Prettier のようなコードフォーマッターにとってはそれほど重要なことではないと考えています。ブラウザ上ではなく開発を行うマシンか CI のためのマシンの上で実行されることが多いためそれほどクリティカルな問題ではないのです。そのような状況の中で、我々が Prettier のバンドルサイズを減らすための努力を始めたのにはきっかけがあります。それは Chrome DevToolss が Pretty Print 機能のためのコードフォーマッターとして Prettier を採用しようと試みたことです。https://github.com/prettier/prettier/issues/12144この issue は Chrome DevToolss の開発チームのメンバーだった Tim van der Lippe 氏によって作成されたものです。要約すると「Chrome DevTools のコードフォーマッターとして Prettier を使うことを考えたんだけど、バンドルサイズが大きすぎる。なんとかして減らしていけないか。」というような内容です。この issue が作成されたすぐあと Tim van der Lippe 氏によって Prettier のバンドルサイズをへらすためのいくつかの Pull Request が作成されました。これを受けて私と、もう一人のメンテナーである fisker Cheung 氏は Prettier のバンドルサイズを減らすために動き出しました。(私も fisker 氏もバンドルサイズのチューニングがもともと好きだという事情もあります。)Tree Shaking には頼れないesbuild は今のところ CommonJS の Tree Shaking をサポートしていません。そして残念なことに Prettier のソースコードは CommonJS で記述されています。つまりモジュールバンドラーによる Tree Shaking には頼れません。なので Tree Shaking 相当のことを自分たちでやるしかありませんでした。ファイルを適切に分割するたとえば次のような utils.js というファイルがあるとします。// utils.jsconst foo = function () {  console.log("Foo");};const bar = function () {  console.log("Bar");};module.exports = { foo, bar };この utils.js を require する main.js があるとします。// main.jsconst { foo } = require("./utils.js");foo();このとき Tree Shaking が適切に機能していれば最終的なバンドルから bar は取り除かれます。Tree Shaking なしでこれを実現するためには、単純に foo と bar を別のファイルで宣言する必要があります。// utils/foo.jsconst foo = function () {  console.log("Foo");};module.exports = { foo };// utils/bar.jsconst bar = function () {  console.log("Bar");};module.exports = { bar };そのような修正をいくつか行いました。https://github.com/prettier/prettier/pull/12156https://github.com/prettier/prettier/pull/12164https://github.com/prettier/prettier/pull/12176https://github.com/prettier/prettier/pull/12204https://github.com/prettier/prettier/pull/12203これは退屈でつらい作業でした。要らないものはビルド時に抹消する自分たちの管理しているコードに対しては上記のようなファイルを分割する方法で十分です。しかし依存しているライブラリのコードに対してはファイルをあとから分割することはできません。なので依存しているライブラリに関しては、未使用の API が esbuild の minifier によって抹消されるように設定する必要がありました。そのために esbuild-plugin-replace-text と esbuild-plugin-replace-module という２つの esbuild プラグインが fisker 氏によって実装されました。これらのプラグインを泥臭く設定することで、バンドルサイズを大幅に減らすことができました。esbuild-plugin-replace-textesbuild-plugin-repleace-text はバンドルする前のコードの中のある文字列を、指定の文字列で置換します。@rollup/plugin-replaceを知っている人はそれと同じだと考えてもらって大丈夫だと思います。(ちゃんと調べてないのでわかりませんが webpack の DefinePlugin もこの用途に使えそうです)さきほどの utils.js と main.js を思い出してください。utils.js を分割することなく最終的なバンドルから bar を取り除くことを考えます。esbuild-plugin-replace-text を使うと次のようにして実現できます。import { build } from "esbuild";import esbuildPluginReplaceText from "./esbuild-plugin-replace-text";const options = {  entryPoints: ["./src/main.js"],  minify: true,  bundle: true,  outfile: "./dist/main.js",  // その他のオプション...  plugins: [    esbuildPluginReplaceText([      {        file: "./src/utils.js",        find: "const bar = ",        replacement: "const bar = undefined && ",      },    ]),  ],};build(options);このように指定することで、 utils.js の const = bar  の部分をバンドル前に const bar = undefined &&  に置き換えることができます。これによって minifier の Dead Code Elimination により && の右辺が消されます。これでファイルを分割することなく、bar の実装を最終的なバンドルから消し去ることができます。esbuild-plugin-replace-moduleesbuild-plugin-replace-module も似たような機能を持つプラグインです。特定のモジュールに対する require / import を指定した別のモジュールへ置換します。次のような sub-lib.js があるとします。sub-lib.js は foo という関数をエクスポートしています。引数として与えられた kind が "A" のときに限り largeFunction という関数を呼び出します。// sub-lib.jsconst largeFunction = require("./largeFunction");const foo = function (kind) {  if (kind === "A") {    largeFunction(options);  } else {    console.log("Foo");  }};module.exports = { foo };ここで次のような lib.js があるとします。lib.js は bar という関数をエクスポートしています。bar は foo に "B" を渡しています。// lib.jsconst { foo } = require("./sub-lib.js");const bar = function () {  foo("B");};module.exports = { bar };そして次のような main.js があるとします。// main.jsconst { bar } = require("./lib.js");bar();このとき main.js をバンドルすると、最終的な結果には largeFunction の実装が含まれることになります。しかし foo の引数として "B" を渡してはいるため largeFunction が実際に呼び出されることはありません。このような状況で最終的なバンドルから largeFunction を取り除くことを考えます。esbuild-plugin-replace-module を次のように設定することで実現できます。(次のような largeFunctionShim.js を作成しておきます。)// largeFunctionShim.jsmodule.exports = () => {};import { build } from "esbuild";import esbuildPluginReplaceModule from "./esbuild-plugin-replace-module";const options = {  entryPoints: ["./src/main.js"],  minify: true,  bundle: true,  outfile: "./dist/main.js",  // その他のオプション...  plugins: [    esbuildPluginReplaceModule([      {        "./largeFunction.js": "./largeFunctionShim.js",      },    ]),  ],};build(options);esbuild-plugin-replace-module のオプションとして largeFunction.js を largeFunctionShim.js に置き換えることで、バンドルから実装を抹消できます(() => {} に置き換えられる)。ビルドのデバッグがしやすい環境を整える快適にビルドのチューニングを行うためにはビルドスクリプトの開発を快適に行う環境を整える必要があります。esbuildまず、esbuild の圧倒的な速さがなければ快適にビルドスクリプトを改善することは到底できなかったでしょう。この記事の冒頭で esbuild のおかげでバンドルサイズが小さくなったわけではないと書きましたが、esbuild なしでは無理でした。たしかに esbuild に移行したからバンドルサイズが小さくなったわけではありませんが、esbuild に移行したからこそバンドルサイズを減らすための作業に取り掛かることができたのです。esbuild-visualizeresbuild-visualizer というライブラリによって、ビルド結果を可視化することができます。(webpack の Webpack Bundle Analyzer のようなものです。)この仕組みによって、余計なライブラリが含まれていることにすぐ気がつけるようになりました。CLI オプションデバッグを行うにあたって便利ないくつかの CLI オプションが追加されました。たとえば minify の有無や、esbuild-visualizer によるレポートの作成の有無などを CLI オプションで切り替えられるようになっています。ドキュメンテーションPrettier のビルドスクリプトは複雑です。しかしその複雑さに反してドキュメントが存在しませんでした。レビューは行われるとはいえ、メンテナー個人の意思によって CLI オプションが追加されるため、当人以外それを覚えていないような状況でした。これでは便利な環境を整えても他のメンテナーはその環境の恩恵を受けることができません。そこで CLI オプションについてはきちんとドキュメントを残すことにしました。https://github.com/prettier/prettier/tree/ae080df3e7c38e22ddb47699f71bd2bbca3d822e/scripts/build今後ECMAScript Modules への移行この記事を読んで、バンドルサイズのチューニングをしたことがある人は「なんて不毛な！」と思ったことでしょう。私もそう思います。ここまで紹介したテクニックのほとんどはソースコードを CommonJS から ECMAScript Modules に移行することによって不要になる可能性が高いです。ECMAScript Modules は性質上静的解析がしやすく CommonJS に比べて Tree Shaking などの最適化がよく働きます。Prettier は次のメジャーバージョンである v3 から ECMAScript Modules へ移行します。Chrome DevToolsChrome DevTools のコードフォーマッターとして Prettier が使われるかもしれないという話を紹介しましたが、おそらく当面はそのようなことはないでしょう。というのも、そのために色々と動いていくれていた Tim van der Lippe 氏はすでに Google を退職されているようなのです。いつか Chrome DevTools 上で Prettier が動くようになったら嬉しいですね。おわりにQ. 3 MB 減ってもまだ 16.9 MB なので十分でかいですよね？何がうれしいんですか？A. でかいですね。あんまりうれしくないかも。でもブラウザで JavaScript のコードをフォーマットするために必要なサイズ(standalone.js + parser-espree.js)は 783 kb から 595 kb になっているので、約 200 kb のダイエットと考えるとちょっとはうれしいかも？

Prettier のサイズを減らすテクニック

先日次のツイートを見かけた。I have been writing Javascript since roughly 1997 but it still manages to occasionally do something that absolutely shocks me pic.twitter.com/JyYOo4wGOu— mcc (@mcclure111) January 11, 2022 JavaScript では [1, 2, 3] + [4, 5, 6] の結果が "1,2,34,5,6" であり、この挙動が直感に反しているというツイートである。実際のところ筆者も直感に反していると思う。しかしこの挙動は至って ECMAScript の仕様通りである。この記事では、なぜこの挙動が ECMAScript の仕様に従っていると言えるのか仕様を引用して説明する。大雑把な答えまず大雑把な答えを示しておこう。JavaScript で [1, 2, 3] + [4, 5, 6] が "1,2,34,5,6" になるのは、オペランドの配列の Array.prototype.toString が呼び出され、それらが文字列として結合されるからだ。しかしこれではつまらないのでちゃんと仕様をたどっていく。+ 演算子まずは + 演算子の挙動がどのように定められているか見ていこう。+ 演算子は The Addition Operator として https://tc39.es/ecma262/#sec-addition-operator-plus に定義されている。構文については多くの人の想像する通りだと思うし今回の本題ではないので無視するとして、セマンティクスを見てみよう。ここでは次のようにセマンティクスが定義されている。1. Return ? EvaluateStringOrNumericBinaryExpression(AdditiveExpression, +, MultiplicativeExpression).AdditiveExpression と MultiplicativeExpression とはここではそれぞれ左辺と右辺のことである。つまり + 演算子は EvaluateStringOrNumericBinaryExpression という Abstract Operation に左辺と+、そして右辺を渡した結果を返す。EvaluateStringOrNumericBinaryExpressionEvaluateStringOrNumericBinaryExpression は https://tc39.es/ecma262/#sec-evaluatestringornumericbinaryexpression に定義されている。この Abstract Operation は leftOperand、opText、rightOperand という次の３つの引数を取る。そしてその３つの引数を次のステップに従って実行する。1. Let lref be the result of evaluating leftOperand.2. Let lval be ? GetValue(lref).3. Let rref be the result of evaluating rightOperand.4. Let rval be ? GetValue(rref).5. Return ? ApplyStringOrNumericBinaryOperator(lval, opText, rval).これらのステップを大雑把に説明する。まず leftOperand を評価した結果を lref とする。そして GetValue(lref) の結果を lval とする(GetValue は https://tc39.es/ecma262/#sec-getvalue で定義されている。今回考えている場合のように [1, 2, 3] のような単純な配列を渡す場合はそのままの配列が返ってくると考えてよい。)。次にleftOperand に対しての処理と同じことを rightOperand に対しても行う。そうして lval と rval が得られる。最後に ApplyStringOrNumericBinaryOperator という Abstract Operation に対して lval と、引数として受け取っていた opText、そして rval を渡し、その結果を返す。つまり EvaluateStringOrNumericBinaryExpression はオペランドと演算子の種類を引数として受け取り、オペランドを評価し GetValue した上で、そのまま ApplyStringOrNumericBinaryOperator に渡すだけの Abstract Operation である。ApplyStringOrNumericBinaryOperatorApplyStringOrNumericBinaryOperator は https://tc39.es/ecma262/#sec-applystringornumericbinaryoperator に定義されている。ApplyStringOrNumbericBinaryOperator は lval、opText、rval という３つの引数を受け取る。ApplyStringOrNumbericBinaryOperator のステップをすべて掲載すると長いの関連するステップのみ説明していく。まずは最初のステップでは引数で受け取った opText のバリデーションを行う。1. Assert: opText is present in the table in step 7.step 7 に掲載されている表によると opText は次のいずれかである必要がある。***/%+-<<>>>>>&^|もちろんこの記事の対象である + もここに含まれており妥当な opText である。次のステップは opText が + であるときのみ実行される。2. If opText is +, then    a. Let lprim be ? ToPrimitive(lval).    b. Let rprim be ? ToPrimitive(rval).    c. If Type(lprim) is String or Type(rprim) is String, then        i. Let lstr be ? ToString(lprim).        ii. Let rstr be ? ToString(rprim).        iii. Return the string-concatenation of lstr and rstr.    d. Set lval to lprim.    e. Set rval to rprim.a と b で lval と rval をそれぞれ ToPrimitive に渡してその結果を lprim、rprim とする。c では、lprim と rprim の少なくともどちらかの型が String であればもう片方も String に変換し、それぞれ lstr、rstr とする。そして lstr と rstr を文字列として結合した結果を ApplyStringOrNumericBinaryOperator 全体の結果とする。この場合には後続の d と e は実行されない。結論からいえば [1, 2, 3] + [3, 4, 5] では、このステップ c が実行されることで文字列の結合が行われ "1,2,34,5,6" が出来上がるというわけだ。c が実行されるのは、 lprim と rprim の少なくともどちらかの型が String であるときだけだ。そして lprim と rprim は ToPrimitive によって返された値である。すなわち、配列に対する ToPrimitive の結果が String であるために、冒頭で紹介した直感的でない挙動が引き起こされているのだ。ToPrimitiveToPrimitive は https://tc39.es/ecma262/#sec-toprimitive に定義されている。ToPrimitive は input という１つの必須の引数と preferedType という１つのオプショナルの引数を受け取る。ToPrimitive は input が Object 型だったときにそれを非 Object 型(つまりプリミティブ型)に変換する Abstract Operation である。ToPrimitive は次のステップに従って実行される。1. If Type(input) is Object, then    a. Let exoticToPrim be ? GetMethod(input, @@toPrimitive).    b. If exoticToPrim is not undefined, then        i. If preferredType is not present, let hint be "default".        ii. Else if preferredType is string, let hint be "string".        iii. Else,            1. Assert: preferredType is number.            2. Let hint be "number".        iv. Let result be ? Call(exoticToPrim, input, « hint »).        v. If Type(result) is not Object, return result.        vi. Throw a TypeError exception.    c. If preferredType is not present, let preferredType be number.    d. Return ? OrdinaryToPrimitive(input, preferredType).2. Return input.1 は input が Object 型のときのみ実行される(input が最初から非 Object 型のときは 2 に進みそのまま input を返す)。次に 1 の各ステップ a、b、c について説明する。ステップ a では GetMethod を使って input の@@ToPrimitive を取得し exoticToPrim とする(GetMethod は https://tc39.es/ecma262/#sec-getmethod に定義されている。名前の通りオブジェクトからメソッドを取得するための Abstract Operation である。)。@@ToPrimitive は Well-known Symbols の１つで、Object 型の値がプリミティブに変換されるときの挙動を制御できる。MDN にドキュメントがあるので詳しくはそちらを参照してほしい。配列にはデフォルトの @@ToPrimitive は存在しないので今回の場合は exoticToPrim は undefined になる。そしてステップ b は If exoticToPrim is not undefined, then という条件付きで実行されるので、exoticToPrim が undefined である今回は b は実行されない。次にステップ c では preferedType が存在しないときに preferedType を number とする。今回 ToPrimitive は ApplyStringOrNumbericBinaryOperator から呼び出されているが、preferedType は指定されていないためこの c により preferedType は number になる。最後のステップ d では input と preferedType を OrdinaryToPrimitive という別の Abstract Operation に渡し、その結果を返す。つまり ToPrimitive は input に @@ToPrimitive が存在すればそれに基づいて input を非 Object 型に変換するが、@@ToPrimitive が存在しない場合は OrdinaryToPrimitive を呼び出し、その結果を返す Abstract Operation である。OrdinaryToPrimitiveOrdinaryToPrimitive は https://tc39.es/ecma262/#sec-ordinarytoprimitive に定義されている。OrdinaryToPrimitive は O と hint という２つの引数を受け取る。O は Object であり、hint は string もしくは number である。ToPrimitive から渡された input が O で、preferedType が hint だ。OrdinaryToPrimitive は次のステップに従って実行される。1. If hint is string, then    a. Let methodNames be « "toString", "valueOf" ».2. Else,    a. Let methodNames be « "valueOf", "toString" ».3. For each element name of methodNames, do    a. Let method be ? Get(O, name).    b. If IsCallable(method) is true, then        i. Let result be ? Call(method, O).        ii. If Type(result) is not Object, return result.4. Throw a TypeError exception.まずステップ 1 と 2 によって methodNames が決定する。hint が string のときは methodNames は "toString", "valueOf" になり number のときは "valueOf", "toString" になる。今回は ToPrimitive の 1 の c によって preferedType が number になっているので、methodNames は "valueOf", "toString" である。ステップ 3 では methodNames の各要素(今回の場合 "valueOf" と "toString")に対して順にステップ a と b を実行する。各ループごとに methodNames の要素は name という名前に格納される。まず a では Get を使って O から name に対応するメソッドを取得し method とする(Get は https://tc39.es/ecma262/#sec-get-o-p に定義されている)。次に b では IsCallable を使い method が呼び出し可能かどうかを調べる(IsCallable は https://tc39.es/ecma262/#sec-iscallable に定義されている)。もし呼び出し可能であれば method を呼び出しその結果を result とする。そしてその結果が非 Object 型であれば result を返す。そしてステップ 1、2、3を実行しての何も返すことができなかった場合、ステップ 4 で TypeError をスローする。OrdinaryToPrimitive を JavaScript で簡単に表現すると次のようになる。当然厳密ではないので疑似コードだと考えてほしい。function OrdinaryToPrimitive(O, hint) {    const methodNames =        // 1.        hint === "string" ? ["toString", "valueOf"]        // 2.        : ["valueOf", "toString"];    // 3.    for (const name of methodNames) {        // a.        const method = Get(O, name);        // b.        if (IsCallable(method)) {            // i.            const result = method(O);            // ii.            if (typeof result !== "object") {                return result;            }        }    }    // 4.    throw TypeError();}今回の場合は methodNames は "valueOf", "toString" なので、その順番でループが実行される。1回目のループでは Get を使って O(今回は配列)から valueOf を取得し method とする。method には配列の valueOf が格納され、IsCallable(method) をパスする。しかし配列の valueOf はその配列を返す。つまり配列の valueOf は Object 型の値を返すのだ。そのため ii の If Type(result) is not Object という条件はパスできない。したがって値を何も返さず次のループへ進む。2回目のループでは、Get を使って O から toString を取得し method とする。配列には toString が定義されているので、method はその配列の toString になる。今回のループでは method に 配列の toString が格納されているので IsCallable(method) は true になる。次に i でその method を呼び出した結果を result とする。配列のデフォルトの toString は String を返す。String は非 Object 型なので If Type(result) is not Object という条件をパスし result が OrdinaryToPrimitive の返り値となる。つまりなんだっけ？ApplyStringOrNumericBinaryOperator を思い出してほしい。ApplyStringOrNumericBinaryOperator では ToPrimitive によって左辺と右辺をプリミティブ化した値(lprim と rprim)が String であれば、それを結合して返すのだった。配列に対する ToPrimitive は結局のところ配列の toString を呼び出したものを返す。配列の toString の挙動は簡単に確認できる。(仕様では https://tc39.es/ecma262/#sec-array.prototype.tostring で定義されている)const arrStr = [1, 2, 3].toString();console.log(arrStr); // "1,2,3"つまり、単純にそれを結合したものが ApplyStringOrNumericBinaryOperator の返り値になり、それはそのまま + 演算子の返り値になるのだ。[1, 2, 3] + [4, 5, 6] の場合は、ToPrimitive([1, 2, 3]) が "1,2,3" であり ToPrimitive([4, 5, 6]) が "4,5,6" なので ApplyStringOrNumericBinaryOperator によってその２つが文字列として結合され + 演算子全体の結果が "1,2,34,5,6" になったということである。ここからハックさて、この仕様がわかればいくつかのハックが思いつくだろう。まずは ToPrimitive によって OrdinaryToPrimitive よりも先に実行される @@ToPrimitive を上書きすればその挙動を変更できる。const arr = [1, 2, 3];arr[Symbol.toPrimitive] = () => "hello!!";console.log(arr + [4, 5, 6]); // "hello!!4,5,6"また、配列の場合 toString よりも valueOf の方が優先される。なので valueOf が非 Object 型を返すように上書きしてもその挙動を変更できる。const arr = [1, 2, 3];arr.valueOf = () => "hello!!";console.log(arr + [4, 5, 6]); // "hello!!4,5,6"もしくは toString 自体を上書きしてもその挙動を変更できる。const arr = [1, 2, 3];arr.toString = () => "hello!!";console.log(arr + [4, 5, 6]); // "hello!!4,5,6"まとめThe Addition Operator の仕様には次のような記述がある。Note: The addition operator either performs string concatenation or numeric addition.つまり + 演算子というのは数値の加算もしくは文字列の結合を行う演算子なのだ。したがって直感的でない挙動を避けるためにはそれ以外の用途では使わない方がよいだろう。当然だが TypeScript では [1, 2, 3] + [4, 5, 6] のような式はコンパイルエラーになる。TypeScript を使おう。

なぜ JavaScript の [1, 2, 3] + [4, 5, 6] は '1,2,34,5,6' なのか

この記事は Prettier 公式ブログに掲載されている Christopher Chedeau (@vjeux) 氏による記事 Prettier begins paying maintainers を、許可を得て翻訳したものです。JavaScript を始めとしたいくつかの Web 開発のための言語のコードフォーマッターである Prettier は、2019 年から OpenCollective で寄付を募り始めすでに $50,000 が集まっています。私達はこの資金から二人のメンテナーに毎月$1500を支払うことにしました。この資金により、彼らは将来に渡って Prettier のメンテナンスを継続できます。オープンソースとお金の問題は往々にして厄介です。私たちはこの問題に対して様々なことを試してきました。Prettierがオープンソース化された直後に Facebook は James Long (訳注: Prettier の作者) と2週間の契約を結びこのプロジェクトに磨きをかけました。そして Christopher Chedeau（vjeux） には9ヶ月の間フルタイムで取り組んでもらいました。また、寄付で集まった資金が $10,000 を超えたころ、大きな貢献をしてくれた開発者全員に $1,000 ずつ配ろうとしました。しかし、手続きがやや複雑であったため、実際に報酬を受け取った人はほとんどいませんでした。現在私達が持っている $50,000 というのはそれなりに大きな金額ですが、それに取り組むだけのスキルを持った人をフルタイムで雇うには足りません。だからといってその資金を使わないまま放置しておくわけにもいきません。そこで、検討の結果、現在このプロジェクトのメンテナンスをしている二人に対して定期的に$1,500を支払うことにしました。彼らはこの二年間、Prettierプロジェクトの素晴らしいstewardでした。Fisker CheungSosuke Suzuki (訳注: 私)ご想像のとおり、全JavaScript開発者の60%が使っているプロジェクトをメンテナンスすることは簡単ではありません。現在、我々は 3.0 のリリースや ECMAScript Modules への移行などを予定しています。さらに、全ての新しい言語機能に対応し続け、定期的に発生するエッジケースのバグも修正します。もし Prettier があなたやあなたの会社の役に立っているなら、今一度 Prettier への寄付を検討してください。その寄付金は、Prettier をより良くするために使わせていただきます。

翻訳: Prettier はメンテナーへの報酬の支払いを始めます

2021 の出来事を振り返ります。学校2021 年 4 月で B3 になるはずだったんですが、留年しました。留年していたらしいということを夏頃に知りました。後輩が教えてくれました。僕が留年したことを教えてくれた後輩たちの顔はすごく楽しそうでした。いつか留年するつもりではいたので特に悲しい気持ちはなかったんですが、留年したことに気づくことすらできてなかったのはちょっとおもしろいなと思いました。両親も「そりゃそうだよね」みたいな反応をしていました。筑波大学の留年の仕組みをよく知らないので自分が B3 と名乗るべきなのか B2 と名乗るべきなのかよくわからないんですが、少なくとも卒業までの年数が1年伸びたのは確かなようです。留年はしたものの、線形代数 A という科目を再々履修で修得することができました。すごく嬉しかったです。色々と教えてくれた同級生、後輩、知りあいのエンジニアの方々、本当にありがとうございました。これはこの一年の中で最も偉大なことでした。秋に受講した授業の成績がまだ発表されていないのですが、かなりやばそうな雰囲気があります。仕事初めてソフトウェアを開発する仕事(アルバイト)をはじめたのが 2017 年の 1 月だったので約 5 年経過したことになります。現在は二つの会社で業務委託として雇用されています。Cybozuサイボウズのフロントエンドエキスパートチームというところで働いています。2021 年の最初の頃に、kintone というプロダクトのフロントエンドのコードベースに Prettier を導入するという仕事をしました。Prettier を導入するなんて簡単じゃないかと思われるかもしれませんが、実際はかなり長い道のりでした。kintone のフロントエンドは Closure Tools という JavaScript ツールチェインで実装されています。Closure Tools では JavaScript のコメントを使って型を記述して静的な型チェックができるのですが、この機能と Prettier の相性がすこぶる悪かったのです。実際に kintone のコードベースに対して Prettier を実行すると型が壊れるというバグがいくつか見つかりました。自分が入る前にこの問題に色々な方法でアプローチしたそうなのですが、どれも微妙に上手くいかなかったそうです。で、「せっかく Prettier にやたら詳しい人がチームに入ったんだから本体直せばいいやん」ということで、本体にいくつかパッチをあてるのと、それをリリースするための作業を業務時間にやりました。これは普通に楽しかったし、「Closure Tools を使い続けるのはつらいことが多いよ」という点と「OSS メンテナーを会社に抱えてるとこういうところでいいことあるよ」という点で、良い例を示せたかなと思います。という話をサイボウズの技術ブログに書きました。大規模 Closure Tools プロジェクトに Prettier を導入するまでの道のり - Cybozu Inside Out | サイボウズエンジニアのブログチームでやっているフロントエンドマンスリーという月に一回の配信にも何度か出演しました。自分はだいたい TC39 の動向とかを話していました。自分が情報を収集するきっかけにもなって良かったです。Cybozu Frontend Monthly他に外に出てる仕事としてはチームのウェブサイトを作りました。これはもともとハッカソンで作ったんですが完成させて公開しました。チームメンバーの皆さんはいろいろな有益なフロントエンド情報を会社のインターナルな場所に書いているんですが、そのうち結構な割合のものがサイボウズ特有の情報ではなかったので表に出していいじゃんと前から思っていました。なのでこういう場でたくさん発信していけたらいいなと思っています。サイボウズフロントエンドエキスパートチームのウェブサイトを作りました | サイボウズ フロントエンドエキスパートチームUbie実は 4 月くらいから気が向いたときに Ubie という会社で働いています。Ubie では昔インターンをやっていたのですが業務委託として戻りました。Ubie のとあるエンジニアが書いた記事があります。150 万 MAU の Nuxt.js 製サービスを機能開発を止めずに 1 ヶ月&1 人で Next.js に置き換えた話この記事の最後の方に出てくる「識者」というのは実は自分です。Ubie のドメイン知識が多少あって、コミュニケーションコストが低くて、フロントエンド周りを見れる、みたいなところで声をかけていただいたようです。記事にあるように、フロントエンドの設計の壁打ち相手になったり、少し手を動かしたりといったお手伝いをしました。この作業が終わったあとは、フロントエンドのパフォーマンスを改善したり、メンバーの Pull Request を見て気になった箇所を先回りするように ESLint のルールを入れたりとか、ライブラリのバージョンあげたりそういう細々したことをやらせてもらっています。Ubie のインターンをやめてから仕事では現代的なフロントエンド開発をほとんどしていませんでした。なのでそういうのに触れる機会としてはかなり良かったと思います。OSS9 月頃に GitHub Sponsors を始めたところ想像していた以上に多くの人から支援していただけたことが印象に残っています。Prettier今まで通りバグ修正とか機能追加みたいなコードを書く仕事や、Issue の管理や PR のレビューみたいな作業をずっとやっています。あと actionlint を Prettier で使いたかったので Go で書かれた actionlint を WebAssembly にコンパイルして Node.js から実行できる node-actionlint というツールを作りました。まあまあ便利なんですが Node.js と WebAssembly をかませる分速度的なオーバーヘッドがすごいので、ローカルで実行するときは本家 actionlint を使ってます。今年のバージョンのほとんどでリリースを担当しました。リリースはやることが多いので面倒だし緊張するのであんまりやりたくないのですが、自分がやらないと一生 Prettier がリリースされなさそうで、それは困るのでやることにしました。リリースに関連して、prettier-regression-testing という自作のツールを TypeScript で書き直して GitHub の Prettier オーガナイゼーションに移管しました。去年に比べて明確に他のメンテナーとのコミュニケーションが増えました。Prettier はインターナルな Discord サーバーがあってそこでアクティブでないメンテナーも集まって話をすることがあります。英語でのチャットは以前はすごい苦手だったんですが、最近ちょっとずつ慣れてきました。OpenCollective で集めたお金をどう使おうか、というのをずっと上手く話せずにいたんですが、ちょっと頑張ってやっとまとまったので近いうちにブログを書きます。新しいメンテナーを推薦して招待するとかそういう活動もしていました。いろんな Podcast や登壇で「Prettier には人が足りなくて〜〜」みたいな話をするのもいい加減飽きてきた感じがあるので人を増やそうと思ったのです。アクティブに活動してくいれているコントリビューターを他のメンテナーに推薦して合意がとれたら勧誘して、みたいなことをしてました。2021 年は約 100 個の Pull Request を出しました。Babelリポジトリのライト権限をもらいました。今の所権限を使ったことはほとんどありません。月に数回程度 Pull Request を投げています。たまにレビューとかもやっています。Babel でやった最も大きな仕事は、パーサーの構文エラーにエラーコードの概念を導入したことです。Prettier で Babel のパーサーを使うときに復帰したい構文エラーと復帰したくない構文エラーがあるんですが、今まではその判定をエラーメッセージに対する正規表現マッチングでやっていました。これだと Babel 側がエラーメッセージをちょっと修正しただけで Prettier の挙動に影響が出るのでエラーコードを導入してそれを使ってエラーから復帰するかどうかの判定をするように変更しました。https://github.com/babel/babel/pull/130332021 年は約 40 個 Pull Request を出していて、3 番目に多いみたいです。お金をもらっていないメンバーの中では 1 番でした。typescript-eslinttypescript-eslint のメンテナーは忙しそうなので助ける意味もこめて TypeScript の新しいバージョンがリリースされたときにはその対応をやっています。あと普通に自分がほしいルールを実装しました。2021 年は約 20 個 Pull Request を出しました。SWCRust への入門として SWC への貢献をちょっとずつやっています。Babel に比べてまだまだバギーなので貢献するべきところがたくさんあって楽しいです。ただ貢献するために求められる Rust 力はそんなに高くないので、Rust の練習としては微妙だったかもしれません。最初の頃はパーサーのバグ修正や機能追加をやっていました。普通の再帰下降構文解析で実装されているので、Rust のことがわからなくてもある程度雰囲気で書けました。最近はトランスフォーマーの実装をやっています。SWC のトランスフォーマーは Babel に比べるとかなり難しいです。パーサーを修正することに比べると Rust の知識が必要だし、何よりトランスフォーマーを書くための内部 crate のドキュメントがほとんどありません。なので既存のトランスフォーマーのコードを読んで、自分でコードをたくさん書いて修得するしかありませんでした。楽しかったです。余談ですが SWC のドキュメントには JavaScript でプラグインが書けるっぽいことが書いてあるんですが、これは v2 でなくなるようです。SWC で現在計画されているプラグインシステムではユーザーが Rust を使ってトランスフォーマーを書く必要があります(パフォーマンス上の懸念から JavaScript プラグインは今のところ計画されていません)。SWC が今後 Babel を置き換えていこうとするならここがネックになるような気がします。Babel プラグインは公式が便利なヘルパーを提供している上にドキュメントが豊富です。しかも多くの Babel ユーザーが得意であろう JavaScript で書けます。一方で SWC の場合は言語が Rust な上に今のところ便利なヘルパーはほとんどなくトランスフォーマーのドキュメントもない状態です。このあたりを変えていく必要があります。とりあえず JavaScript ツールをよく触るエンジニアは Rust の勉強を少ししておいた方が後々楽かもしれません。2021 年は約 20 個 Pull Request を出しました。イベント等いくつかのイベントや Podcast に出演させていただきました。楽しかったです。mozaic.fmmozaic.fm という Podcast に 2 回出演させてもらいました。一回目は「TC39」というテーマでしたが、あんまり TC39 の話は出来なかった気がしていて、ちょっと後悔しています。今ならもう少し TC39 っぽい話ができそうだなと思います。ep78 TC39 | mozaic.fm二回目は Monthly Web です。JavaScript っぽいことをちょっと話しました。ep82 Monthly Web 202104 | mozaic.fmWeb24Web24 という、24 時間 Web について議論し続けるというイベントに参加しました。このイベントでは、時間ごとにテーマとメンバーが変わるのですが、自分は Frontend Tooling というテーマで話しました。結構おもしろい話ができたんじゃないかと思います。アーカイブは残ってないので何を話したのか今となってはわからないのですが。Web24 - connpass東京 Node 学園 36 時限目東京 Node 学園 36 時限目で、「Prettier に従わなくてもよい場合」という発表をしました。「Prettier に脳死で従うべき」みたいな話を見るたびに「必ずしもそうではなくない？」と思っていたので、OSS 仕草の話をあわせて Prettier との向き合い方みたいな話をしました。Node学園 36時限目 オンライン - connpassUIT INSIDE ep. 100LINE の UIT INSIDE の ep. 100 に出演しました。過去の出演者たちが出演するやつらしくて、自分は前に Podcast に出演させてもらったので、声をかけていただきました。OSS をテーマに話しました。UIT INSIDE ep.100『100回記念8時間生放送』 - connpassJSConf JP 2021JSConf JP 2021 で、最初の基調講演をさせていただきました。ここ二年間くらい JavaScript の OSS に深く関わってきて、色々思うことをちまちまと発信はしていたのですが、ちょっとまとめて話したいなと思ったので CFP を応募しました。海外の OSS メンテナーたちにインタビューしたりして、自分も楽しくやれたので良かったです。30分の登壇をするのは初めてでしかも基調講演なのでちょっと緊張しましたが何事もなくやれました。JSConf JPブログhttps://sosukesuzuki.dev には 9 個書きました。TC39 の気になるプロポーザルを見つけたときに詳細を書くのが多かったです。何回かやっていると仕様を読むのに慣れてきてどんどん楽しくなっていきました。https://zenn.dev/sosukesuzuki には 17 個書きました。こちらはほとんどメモみたいな記事ばかりです。いくつかメモよりもう少し詳しいくらいの記事があります。メモが意外と伸びてびっくりしました。仕事で作った会社のブログ https://cybozu.github.io/frontend-expert にも 3 本くらい書きました。ブログを書くことを重視しているわけではないですが、文章を書くのは好きなのでこれからも思いついたときに雑に書きます。せっかく会社のチームのウェブサイトを作ったので、そっちでもいっぱい書こうと思います。その他自動車教習所2020 年の 6 月くらいから自動車教習所に通っていました。しかし、ずっとサボっていたら期限が切れてしまったので免許をとることはできず退校しました。あまりにサボっていたので半額返ってきました。でも車を運転したいので次の春に後輩と一緒に合宿免許にいきます。諦めない心が大事だと思います。読書何冊か技術書を読みました。数えてみたら月に 0.7 冊くらいは読んでいたみたいです。中でも次の3つの本は今の自分にとってすごくおもしろかったです。プログラマのための文字コード技術入門[試して理解］LinuxのしくみTCP技術入門まとめ「周囲の人間はよく頑張っていてすげーなーまあおれはのんびり適当に生きるけどね」みたいな気持ちでずっといた一年でした。個人的には本当になんにもやっていない感覚があったので振り返ってみて実は色々とやっていたことを知ってびっくりしました。（留年と教習所期限切れのダブルパンチでプラマイゼロどころかマイナスみたいな感じではありますが）とは言ってもやっていることの内容は去年の延長みたいな感じで新しいことはほとんどできていませんでした。なので来年は何か新しいことに挑戦したいです。しかしまずは進級と免許です。

2021 年振り返り

GitHub Sponsors をはじめました。I've just started GitHub Sponsors. If you like my Open Source work, you can sponsor me on GitHub.https://t.co/1xiCsXDpzC— sosuke (@__sosukesuzuki) September 9, 2021 すでに4人の方に支援していただいています。ありがとうございます。他の方にも支援していただけると嬉しいです。Sponsorどのような OSS 活動をしているのか主に JavaScript や TypeScript などのためのコードフォーマッター Prettier のメンテナーをやっています。バグの修正、新しい機能の実装、リファクタリング、Issue のトリアージ、Pull Request のレビュー、リリースブログの準備、そしてリリースをしています。(場合によっては私以外のメンテナーがリリースブログの準備やリリース作業をやることもあります。)また Prettier が依存している他の OSS プロジェクトにも貢献しています。たとえば、Babel や typescript-eslint に貢献しています。Babel では、パーサーを中心にバグ修正や機能追加をしています。最近では、babel/babel や babel/website のリポジトリへのコミット権限が付与されました。typescript-eslint では、TypeScript の新しい構文への対応や、Babel の TypeScript パーサーの AST との互換性の改善などの作業をしています。ほかにも、興味のあるプロジェクトには積極的に貢献しています。たとえば、Rust 製の JavaScript トランスパイラ swc のバグ修正や新しい構文への対応などをしています。私が作成した直近 25 件の Pull Request と Issue は https://sosukesuzuki.dev/github/ から確認できます。なぜ GitHub Sponsors をはじめたのかより多くの時間を OSS 活動に割くためです。現在、私は偶然にもある程度の時間を OSS 活動に割くことができています。私は大学生で、フルタイムの仕事がなく、家庭を持っていません。これは本当に偶然によるもので、今後もこの状況が継続される保証はありません。モチベーションが低下したり、就職したりして、十分な時間を OSS に割けなくなる可能性があります。GitHub Sponsors で支援をいただければ、その可能性を下げることができます。また、私のモチベーションが維持できないと Prettier プロジェクトのメンテナンスの継続が難しいという短期的な理由もあります。Prettier は JavaScript や TypeScript を使った開発では欠かせないソフトウェアとなりました。最近では、dprintなどの新しいソフトウェアも知られるようになってきましたが、最もよく使われているのはおそらくまだ Prettier です。しかし、Prettier Team は人手が足りていません。アクティブなメンテナーは私を含めて 2 ~ 3 人です。アクティブなメンテナーのうち誰か1人でもなんらかの事情で OSS 活動に時間を使うことができなくなった場合、Prettier のメンテナンスを継続するのが困難になります。私にとって OSS 活動はオンラインゲームのようなもので、そのほとんどが完全な趣味です。(一部仕事としてやったものもあります)なので、いつ飽きてやめるか正直わかりません。支援があれば、「応援されてるしお金も貰ってるからやるか〜」といったモチベーションが湧いてくるでしょう。なぜ今まで GitHub Sponsors をやっていなかったのかGitHub Sponsors に登録するには Stripe に登録する必要があり、そのために身分証明証が必要になります。以前私が GitHub Sponsors に登録しようとしたときは運転免許証かパスポートのみが有効でした。しかし私はどちらも持っていないので登録ができませんでした。（当時私は自動車教習所に通っており「運転免許証を近いうちにとれるやろ」と思っていたのですが、あまりの怠惰で自動車教習所の期限が過ぎてしまい、免許がとれませんでした。）最近になって再度確認してみたところ、マイナンバーカードでも Stripe の登録が可能になっていました。マイナンバーカードは持っていたので、GitHub Sponsors に登録できました。OpenCollective の資金は使わないのかPrettier は OpenCollective での支援を受け付けており、現在 $45,000 以上の資金が集まっています。https://opencollective.com/prettierこの資金の使い方について Prettier Team (過去の貢献者も含むコミュニティ)で議論されていたのですが、誰も興味がないのか、話がほとんど進みませんでした。(一応、何人かの貢献者に対して $1,000 ずつ分配されました。)おそらく、この議論にもっとも興味がある人間の一人は現在のアクティブメンテナーである私ですが、英語でお金について議論をするのが困難で諦めていまいました。しかし、せっかく $45,000 以上の支援をいただいているのに使わないのはもったいないので、もう一度話をしてみようと思っています。スポンサー特典はあるのか特にありませんが、私のモチベーションが高まり、Prettier のメンテナンスが継続されやすくなります。

GitHub Sponsors をはじめました

この記事では現在 Stage 3 の Class Static Blocks について解説する。なお、まだ現時点で Stage 3 であるため実装状況や細かい仕様は今後変更される可能性がある。概要Class Static Blocks プロポーザルは、クラス内でスタティックなメンバにアクセスできるブロックの構文を導入する。次のコードの static { から始まるブロックが新たに導入される構文である。このとき、スタティックブロック内のthis.fooはスタティックなメンバである。class C {  static foo;  static {    this.foo = "foo";  }}スタティックブロックはクラスCが評価されるタイミングで実行される即時実行関数のようなものと見ることもできる。また、クラスは複数のスタティックブロックを持つことができ、その場合は上から順に実行される。モチベーション2021年4月のTC39ミーティングで Static Class Features というプロポーザルが Stage 4 になった。Static Class Features は、次のようにスタティックなメンバをクラス内に列挙して定義するための構文を導入する。class C {  static foo = "foo";}このとき、C.foo は "foo" である。この Static Class Features の構文によって容易にクラスのスタティックなメンバを定義できるようになった。しかし、JavaScript の制御構文のほとんどは文である。そのため、Static Class Features の構文のみでは、複雑な計算の結果をスティックメンバの初期値として設定するのは難しい。たとえば、典型的な例として try catch について考えてみよう。try catch を使って次のような処理を記述したいとする。try 内でなんらかの計算をする計算が成功した場合はその結果をクラスCのスタティックメンバfooに入れる計算が失敗した場合はフォールバックの値をクラスCのスタティックメンバfooに入れるこのような場合に Static Class Features の機能だけではクラス内に書くことができない。class C {  static foo;}try {  const result = calculate();  C.foo = result;} catch {  C.foo = -1;}ここで Class Static Blocks を使うと次のようにクラス内に書くことができる。class C {  static foo;  static {    try {      const result = calculate();      this.foo = result;    } catch {      this.foo = -1;    }  }}また、Class Static Blocks はクラス内に閉じているためプライベートなメンバにもアクセスできる。let getFooOfC;let writeFooOfC;class C {  #foo;  constructor(foo) {    this.#foo = foo;  }  static {    getFooOfC = (c) => c.#foo;    writeFooOfC = (c, v) => {      c.#foo = v;    };  }}const c = new C("private value");getFooOfC(c); // -> "private value"writeFooOfC(c, "updated private value");getFooOfC(c); // -> "updated private value"TypeScript 4.4実は Class Static Blocks は、先日ベータ版が公開された TypeScript 4.4 に実装される予定である。公式のベータ版アナウンス記事では Class Static Blocks についての言及がなかったので気づかなかった人も多いのではないだろうか。実際に TypeScript の Playground で試してみることもできる(Playground link)。ref: https://devblogs.microsoft.com/typescript/announcing-typescript-4-4-beta/ref: https://github.com/microsoft/TypeScript/pull/43370ref: https://twitter.com/robpalmer2/status/1410855524770406403おわりに現代のフロントエンド開発ではそもそもクラスを使う機会が少なくなっているように感じる。そのため、Class Static Blocks が使えるようになっても実際に使うウェブ開発者はそこまで多くないだろう。しかしながら、ライブラリ開発などには役に立つ可能性が高いので、覚えておくとよいだろう。

JavaScript の Class Static Blocks について

この記事では、現在 Stage 3 の Object.hasOwn プロポーザルの概要や、経緯について解説する。プロポーザルの詳細については https://github.com/tc39/proposal-accessible-object-hasownproperty を参照してほしい。また Object.hasOwn は現在 Stage 3 であり、細かい仕様については今後更新される可能性がある。概要Object.hasOwn プロポーザルは、Object.hasOwn という新しいメソッドを導入する。Object.hasOwn メソッドは、Object.prototype.hasOwnProperty()をObjectのスタティックメソッドにしたものだ。つまり、次の２つのプログラムは同じ挙動になる。let hasOwnProperty = Object.prototype.hasOwnProperty;if (hasOwnProperty.call(object, "foo")) {  console.log("has property foo");}if (Object.hasOwn(object, "foo")) {  console.log("has property foo");}経緯とモチベーションObject.prototype.hasOwnProperty は使ったことがあるだろう。たとえば、for in 等でオブジェクトのプロパティを走査するときに意図しないものを参照しないために使うことがある。たとえば次のようなコードを考える。const foo = { prop1: 1 };for (const prop in foo) {  console.log(prop);}このようなコードを書いたとき、多くの場合 prop1 が表示されることを期待するだろう。実際、これをそのまま実行すれば prop1 と表示される。しかしこのコードより前に、次のような Object.prototype を変更するようなコードがあった場合、結果が変わってしまう。Object.prototype.prop2 = 2;const foo = { prop1: 1 };for (const prop in foo) {  console.log(prop);}これを実行すると、次のようにprop2も表示される。prop1prop2「そんなコード書かないよ」という人もいるだろう。しかし、依存の奥深くのライブラリに Object.prototype を更新するコードが入っていたらどうだろうか。そのような懸念から、for in を使う場合にはObject.prototype.hasOwnProperty 等を使ってガードすることが多い。Object.prototype.hasOwnPropertyを使えば、プロトタイプをさかのぼることなく、そのオブジェクトに特定のプロパティが存在するかどうかを確かめることができる。なので、次のようにhasOwnPropertyを使うことで、継承されているprop2を除いてfooに存在するprop1だけを表示できる。Object.prototype.prop2 = 2;const foo = { prop1: 1 };for (const prop in foo) {  if (foo.hasOwnProperty(prop)) {    console.log(prop);  }}しかし、実際にはfooに必ずhasOwnPropertyが存在するという保証はない。なぜなら、hasOwnProperty自体を上書きできるからだ。Object.prototype.prop2 = 2;const foo = {  prop1: 1,  hasOwnProperty: () => true,};for (const prop in foo) {  if (foo.hasOwnProperty(prop)) {    console.log(prop);  }}このコードを実行すると、次のように継承されたprop2も表示されてしまう。prop1hasOwnPropertyprop2また、たとえばObject.create(null)で生成されたオブジェクトにはhasOwnPropertyが存在しない。Object.create(null).hasOwnProperty("foo");// Uncaught TypeError: Object.create(...).hasOwnProperty is not a functionこのようなことを避けるため多くの場合次のようにして、必ず Object.prototype.hasOwnProperty を参照するパターンがよく使われている。Object.prototype.hasOwnProperty.call(foo, key);{}.hasOwnProperty.call(foo, key);ESLint にはそれを強制するためのルールが存在する（ 参照: https://eslint.org/docs/rules/guard-for-in ）。このパターンはよく知られており、ESLint のルールの存在もあって浸透しているよう。しかし、記述量が多くなる上に直感的でない。さらに、このパターンを理解するためには、Function.prototype.callや、現在ではあまり使われなくなったプロトタイプについての理解が求められる。そのため、JavaScript 初心者にとってはややハードルが高いように感じる。そこで、Objectのスタティックメソッドとして同等の機能を実装することで、使いやすくしようというのが Object.hasOwn プロポーザルの目的である。命名について実はObject.hasOwn はもともと Object.has という名前で提案されていた。しかし、Object.has という名前ではプロトタイプをさかのぼる挙動が想像されるということから改名されることになった。JavaScript には Reflect というトップレベルのオブジェクトが存在する。そして、Reflect には Object と同じようなセマンティクスを持つスタティックメソッドがいくつか存在している。さらに Reflect には Reflect.has というスタティックメソッドが存在する。Reflect.has は in 演算子と同じようなセマンティクスを持ち、つまりプロトタイプをさかのぼってプロパティの有無をチェックする。なので、JavaScript プログラマーが次のように推測してしまう可能性が高い。Reflect と Object には似たセマンティクスのメソッドがいくつか存在する。Reflect には has というスタティックメソッドが存在する。ならば、Object.has も Reflect.has と同じようにプロトタイプをさかのぼるだろう。このような懸念から、Object.has ではなく Object.hasOwn という名前に変更された。この改名に関する議論は以下のリンクを参照してほしい。https://github.com/tc39/proposal-accessible-object-hasownproperty/issues/3https://github.com/tc39/notes/blob/master/meetings/2021-04/apr-20.md#objecthas-for-stage-1提案の進化の速さプロポーザルにとって本質的なことではないが、このプロポーザルは異様な速さで Stage を進んでいる。2021 年 4 月の TC39 のミーティングで初めて議題にあがり、そのミーティング内で Stage 1 を飛ばしていきなり Stage 2 になった。そして、2021 年 5 月の TC39 ミーティングでは Stage 3 になった。現在 V8 と SpiderMonkery ではすでにフラグ付きで実装されている。2021 年 7 月のミーティングでも、"Accessible Object hasOwnProperty update" として議題にあがる予定だ。このままいけば ES2022 に入る可能性もあるだろう。おわりに筆者自身、数年前に JavaScript を始めたころは Object.prototype.hasOwnProperty.call を使ったコードを見て困惑した記憶がある。なので、よく使われるこのパターンが言語に入ってくれるのは喜ばしいことだと考えている。また、Stage を駆け上がっていく様を見るのも楽しいので、今後も注目しておきたいプロポーザルの1つである。

JavaScript の Object.hasOwn について

先日 import.meta について調査して人に話す機会があり HTML(Web) と Node.js の各ホストの import.meta がどのようなオブジェクトを返すのかを調査していた。そのときは、「HTML でも Node.js でも import.meta.url だけが生えていて〜〜」という話をしてしまった。後になって知ったのだが、Node.js には import.meta.url 以外にも import.meta.resolve というプロパティが実装されている。この記事では Node.js に実装されている import.meta.resolve について解説する。なお、import.meta.url はまだ Stability 1 の API なので、今後仕様が変わる可能性があることに注意してほしい。import.meta についてまず import.meta について軽く触れておこうと思う。import.meta については知っているよという人は飛ばしてほしい。import.meta は ECMAScript 2020 から入った機能で、現在実行中のモジュールに対してホスト固有のメタデータをオブジェクトとして提供する(現在は ECMAScript に入っているのでリポジトリはアーカイブされているが、プロポーザルは https://github.com/tc39/proposal-import-meta にある)。大事なルールとして、import.meta はモジュールに対してのみ機能するのでスクリプトの環境では使うことができない。そして、import.metaは現在の ECMAScript には２つしかない Meta Property と呼ばれる構文の１つである(ref: https://tc39.es/ecma262/#prod-MetaProperty)。import.meta は、ECMAScript の範囲内ではそれがオブジェクトであるということしか決まっていない。なので、実際にどのようなメタデータをモジュールに対して提供するかはホストの実装者に委ねられている。現在 HTML と Node.js の両方に実装されているのが import.meta.url である。これは現在実行中のモジュールの URL を表す。HTML では http スキームだが、Node.js では file スキームの URL になる。Node.js の import.meta.urlNode.js では import.meta.url はよく使われるだろう。Node.js 10 が EOL となった今、Node.js でも ECMAScript Modules を使ったプログラムを書くことが増えてきた。ECMAScript Modules では、今まで Node.js のプログラム内でよく使われてきた__filenameや__dirnameを使うことができない。そこでimport.meta.urlを使うことでそれに相当する値を簡単に作ることができる。import url from "node:url";import path from "node:path";const __filename = url.fileURLToPath(import.meta.url);const __dirname = path.dirname(url.fileURLToPath(import.meta.url));また、Node.js の module モジュールには CommonJS Modules での require に相当する関数を作るための関数 createRequire が実装されている。createRequire の引数にimport.meta.urlを渡すことでrequire関数を取得するのもよくあるパターンだと思う。import module from "node:module";const require = module.createRequire(import.meta.url);Node.js の import.meta.resolve実は Node.js には import.meta.url の他に import.meta.resolve というプロパティが実装されている。ECMAScript Modules 界隈では有名な Guy Bedford による https://github.com/nodejs/node/pull/31032 によって実装されたようで、この Pull Request は 2019 年の 12 月に作成されている。ドキュメントは https://nodejs.org/api/esm.html#esm_import_meta_resolve_specifier_parent にある。import.meta.resolve は CommonJS Modules でいう require.resolve に相当する関数である。つまり、モジュールの specifier を引数に渡すと、そのモジュールの URL が返ってくる。ECMAScript Modules でのモジュール解決は非同期に行われるため、import.meta.resolveの返り値は Promise になっている。また、import.meta.resolveは現在 Stability 1 の experimental な API なので、実行するには--experimental-import-meta-resolveオプションをつける必要がある。// index.jsconst lodashUrl = await import.meta.resolve("lodash");console.log({ lodashUrl });node --experimental-import-meta-resolve ./index.js{  lodashUrl: 'file:///Users/hoge/development/import-meta-resolve-example/node_modules/lodash/lodash.js'}import.meta.resolveにはオプショナルな第二引数が存在し、解決元となるファイルの絶対パス URL を指定できる。デフォルトではimport.meta.urlが指定されている。つまり、デフォルトではimport.meta.resolveが実行されるファイルの URL が指定されている。この第二引数を使うことで現在実行中ではないファイルをもとに解決されたモジュールの URL を取得できる。たとえば、次のようなディレクトリ構造があるとする。.├── pkg1│   ├── index.js│   └── package.json└── pkg2    ├── index.js    ├── node_modules    │   └── lodash    ├── package-lock.json    └── package.jsonこのとき、pkg1/index.js から pkg2 の lodash の URL を取得する場合、次のように import.meta.resolve を使うことができる。// ./pkg1/index.jsconst lodashUrlFromPkg2 = await import.meta.resolve(  "lodash",  "file:///Users/foo/import-meta-resolve-examples/pkg2/index.js",);console.log({ lodashUrlFromPkg2 });node --experimental-import-meta-resolve ./pkg1/index.js{  lodashUrlFromPkg2: 'file:///Users/foo/import-meta-resolve-examples/pkg2/node_modules/lodash/lodash.js'}おわりに自分はまだあまり Node.js の ECMAScript Modules で複雑なプログラムを書いたことがなく、この機能を知らなかった。しかし、今後様々なパッケージが ECMAScript Modules で書かれていくことを考えると、import.meta.resolve も安定に向かっていくのだろう。

Node.js の import.meta.resolve について

この記事では、現在 Stage 1 のプロポーザル Change Array by copy について解説する。プロポーザルの詳細については、https://github.com/tc39/proposal-change-array-by-copy を参照してほしい。また、ここで紹介した仕様に関しては今後更新されていく可能性がある。概要Change Array by copy は、簡単にいえばイミュータブルな配列操作メソッドを導入するプロポーザルである。JavaScript の配列には多くのインスタンスメソッドがあり、それらを使って配列を操作できる。配列のインスタンスメソッドには、ミュータブルなもの、つまりもとの配列を変更することによって配列を操作するタイプのものがいくつかある。たとえば、Array.prototype.push や Array.prototype.pop、Array.prototype.reverseなどはミュータブルなメソッドである。// もとの配列を破壊する例const array1 = [1, 2, 3, 4, 5];array1.push(6);console.log(array1); // [1, 2, 3, 4, 5, 6]const array2 = [1, 2, 3, 4, 5];array2.pop();console.log(array.2); // [1, 2, 3, 4]const array3 = [1, 2, 3, 4, 5];array3.reverse();console.log(array3); // [5, 4, 3, 2, 1]Change Array by copy プロポーザルは、これらのミュータブルなメソッドたちに対して、同じような操作をするためのイミュータブルなメソッドを導入する提案である。具体的には、次の 10 個のインスタンスメソッドを導入する。Array.prototype.filled(value, start, end) -> ArrayArray.prototype.copiedWithin(copiedTarget, start, end) -> ArrayArray.prototype.popped() -> ArrayArray.prototype.pushed(values...) -> ArrayArray.prototype.reversed() -> ArrayArray.prototype.shifted() -> ArrayArray.prototype.sorted(compareFn) -> ArrayArray.prototype.spliced(start, deleteCount, ...items) -> ArrayArray.prototype.unshifted(...values) -> ArrayArray.prototype.with(index, value) -> Arrayまた、ArrayのみではなくTypedArrayについても同様のメソッドたちを導入する。みればわかるとおりこれらのメソッドは、基本的には既存のミュータブルなメソッドの名前を過去形(というより意図されているのはおそらく過去分詞系)にした名前になっている。モチベーション根本的にミュータブルな配列操作というのは扱いが難しい。ある配列が現在どのような状態であるのかを把握するのが難しくなってしまう。たとえば、定数として扱いたい値を配列として確保する例を考える。const USER_NAMES = ["Suzuki Sosuke", "Javascript Taro", "Ecmascript Hanako"];このUSER_NAMESをアルファベット順にソートして関数someOperationに渡したい。// 整列済みの配列を引数に受け取るなんらかの操作someOperation(USER_NAMES.sort());このように関数に渡してしまうことがあるだろう。しかし、Array.prototype.sortは整列された新しい配列を返すだけではなく、もとの配列も変更してしまう。つまり、上記のsomeOperation実行後はUSER_NAMESという配列自体がソートされたものになってしまう。someOperation(USER_NAMES.sort());console.log(USER_NAMES); // ["Ecmascript Hanako", "Javascript Taro", "Suzuki Sosuke"]これはそのあとのプログラムで想定外の挙動を引き起こす可能性がある。そういったことを防ぐ手段がいくつかある。Object.freeze を使って配列を凍結する。Object.freezeで配列を凍結すれば、ミュータブルなメソッドをそもそも使うことができなくなる(むりやり使うと実行時エラーになる)。TypeScript を使っている場合USER_NAMESの定義の時点でas constをつける。as constをつければその配列は型上は凍結されたようなものとして扱われ、ミュータブルなメソッドを使うとコンパイルエラーになる。そのうえで、もとの配列を変更することなく整列済みの配列を手に入れる必要がある。たとえばArray.prototype.sortをそのまま使ったり、someOperationを呼び出すときにスプレッド構文等でコピーしてからソートしたり、lodash 等のライブラリを使用することが考えられるが、いずれも面倒くさい。ここで Change array by copy によって導入されるArray.prototype.sortedを使うことで、安全かつ簡単に配列をソートできる。// USER_NAMES は変更されないsomeOperation(USER_NAMES.sorted());ほかにも様々なケースが考えられる。ある程度 JavaScript を書いたことがあるひとなら、イミュータブルな配列操作メソッドがほしくなったことがあるだろう。経緯Change Array by copy プロポーザルが生まれた経緯には、現在 Stage 2 の Records and Tuples という別のプロポーザルが関係している。Records and Tuples は簡単にいえば、イミュータブルなオブジェクトと配列のようなデータ構造である Record と Tuple を導入するプロポーザルである。次のような構文で Record と Tuple を作ることができる。const record = #{ x: "x" };const tuple = #[1, 2, 3];Records and Tuples は 2019 年ごろから議論されていた提案であり、当初から「Record と Tuple に対して記述したコードはオブジェクトと配列に対しても同じように動作するべき」という方針があった。しかし、最近になって配列と Tuple の挙動の一貫性について調査したところ、Tuple.prototype にあって Array.prototype にはないインスタンスメソッドが存在することに気づいたらしい。それが pushedやpoppedやrevesedのようなイミュータブルなメソッドたちである。当初の方針にしたがうと、Tuple に対して記述したコードを配列に対しても動作させるために、配列にも同様のインスタンスメソッドを導入するべきというということになる。もともとは、それらのメソッドの仕様策定は Records and Tuples 提案の中に行うという考えもあったようだ。しかし、そういったイミュータブルな操作というのは一般的に Tuple だけではなく配列に対して実装されていても有益であるという判断がされたため、Records and Tuples とは異なる別のプロポーザルとして提案されるとことになった。その判断が行われたのが 2021 年 3 月のミーティングであり、実際にこの Change Array by copy プロポーザルが提案されたのが 2021 年 4 月のミーティングである。Tuple のために仕様が決まっていたとはいえ、かなりのスピードでミーティングまでいったことになる。ちなみに、該当するミーティングの議事は https://github.com/tc39/notes/blob/master/meetings/2021-03/mar-9.md#records-and-tuples-update に公開されている。おわりにChange Array by copy プロポーザルはわかりやすく実用的な機能であり、個人的にも ECMAScript に入るのが待ち遠しい。

JavaScript にイミュータブルな配列操作メソッドを導入するプロポーザルについて

この記事では現在 Stage 2 の Symbols as WeakMap keys 提案について解説する。プロポーザルの詳細についてはtc39/proposal-symbols-as-weakmap-keysを参照してほしい。また、ここで紹介した仕様に関しては今後更新されていく可能性がある。概要Symbols as WeakMap keys は、WeakMap のキーとしてシンボルを使えるようにするための提案である。現在の WeakMap では、キーとしてオブジェクトのみを使用できる。const weak = new WeakMap();const key = {};const value = "";weak.set(key, value);たとえば、キーとして数字や文字列などのプリミティブな値を使用すると実行時エラーが発生する。const weak = new WeakMap();const key = 3;const value = "";weak.set(key, value); // Uncaught TypeError: Invalid value used as weak map keyJavaScript のシンボルは数字や文字列と同様にプリミティブな値なので、現在の仕様では WeakMap のキーとして使うことができない。const weak = new WeakMap();const key = Symbol("key");const value = "";weak.set(key, value); // Uncaught TypeError: Invalid value used as weak map keyモチベーションシンボルは WeakMap のキーに必要な性質を満たすそもそも WeakMap は GC 可能なユニークな値をキーとして扱いたいだけなので、シンボルをキーとして使用できても問題がない、ということらしい。現在の WeakMap がオブジェクトをキーとして扱うようになっているのも、オブジェクトがユニークかつ GC によって不要になったら回収されるからである。{} === {}; // falseシンボルもユニークであり、不要になったら GC によって回収されるのでこの性質を満たす。Symbol("foo") === Symbol("foo"); // falseシンボルを WeakMap のキーとして扱えると人間にわかりやすい単純に、シンボルを WeakMap のキーとして使えると人間にとってわかりやすい。Records and Tuples の制限のためRecords and Tuples という現在 Stage 2 の提案がある。Records and Tuples プロポーザルは Record と Tuple という新しい２つのデータ構造を導入する。これはかんたんに説明すると、それぞれイミュータブルなオブジェクトと配列である。Record と Tuple の構文は、ぞれぞれオブジェクトリテラルと配列リテラルの先頭に#をつけたものになっている。const record = #{ x: 1, y: 2 };const tuple = #[1, 2, 3];このときrecordとtupleの中身はイミュータブルになっており、あとから変更することはできない。そして Record と Tuple には、プリミティブな値もしくは Record と Tuple しかプロパティの値として持てないという制約がある。つまり、Record と Tuple の中にはイミュータブルな値しかいれることしかできないということである。これはイミュータブルなデータ構造を導入する以上妥当な制約であり、むしろこの制約が存在しなかった場合、イミュータブルと呼ぶことはできないだろう。しかし、Record や Tuple は関数をプロパティの値として持つことができないということでもある。// 関数はオブジェクトであり、Recordはオブジェクトを持てないのでこれはできないconst record = #{  func: () => {    console.log("foo");  },};これが不便だというのは、容易に想像ができるだろう。この制限を保ったまま、擬似的に Record や Tuple に関数を保持させるために、Symbols as WeakMap keys を使用できる。シンボルはあくまでイミュータブルなプリミティブな値であるため、Record と Tuple は他のプリミティブな値と同様にシンボルくをプロパティの値として持つことができる。// シンボルはプリミティブな値なので Record はプロパティの値としてシンボル持つことができる。const record = #{ x: Symbol("foo") };つまり、Record にはシンボルをもたせておき、そのシンボルを使って WeakMap から関数を取得するようなことは可能なのだ。const weak = new WeakMap();const key = Symbol("function key");weak.set(key, () => {  console.log("HI!!");});const record = #{ x: key };weak.get(record.x)(); // HI!!そしてこの操作をよりかんたんにするためのラッパーを書くことができる。class RefBookkeeper {  #references = new WeakMap();  ref(obj) {    const sym = Symbol();    this.#references.set(sym, obj);    return sym;  }  deref(sym) {    return this.#references.get(sym);  }}const refs = new RefBookkeeper();const record = #{  x: refs.ref(() => {    console.log("HI!!");  }),};refs.deref(record.x)(); // HI!!現在の懸念点well-known な Symbol も WeakMap のキーとして使えるようにするのか？JavaScript には、well-known なシンボルと呼ばれる特別なシンボルがいくつかある。Symbol.iteratorは使ったことがある人もいるのではないだろうか。その他のものについては、 https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Symbol#static_properties や https://tc39.es/ecma262/#sec-well-known-symbols などをを参照してほしい。このようなシンボルを WeakMap のキーとして許容するかどうかは TC39 のメンバーの中でも意見が割れているようだ。現在は、許容することも禁止することも現実的な選択肢として考えられている。グローバルシンボルレジストリに登録されたシンボルも WeakMap のキーとして使えるようにするのか？SymbolにはSymbol.forとSymbol.keyForという２つの静的メソッドが存在する。これらのメソッドは、グローバルシンボルレジストリに関連するものである。グローバルシンボルレジストリは、その名の通り、グローバルにシンボルが登録される場所である。普通にシンボルを作成した場合はグローバルシンボルレジストリには登録されない。// グローバルシンボルレジストリには登録されないconst sym = Symbol("sym");Symbol.forを使うことで、グローバルシンボルレジストリにシンボルを登録できる。// グローバルシンボルレジストリに登録される。const sym = Symbol.for("sym");Symbol.forは、引数として key と呼ばれる文字列を受け取り、グローバルシンボルレジストリから key にマッチするシンボルを検索し、存在した場合そのシンボルを返し、存在しない場合は新しく key を使ってグローバルシンボルレジストリに新しいシンボルを作成し、そのシンボルを返す。// まだグローバルシンボルレジストリに、key `sym` に対応するシンボルが存在しないため、// 新しくグローバルシンボルレジストリにシンボルを作成し、そのシンボルを返すconst sym1 = Symbol.for("sym");// すでにグローバルシンボルレジストリに key `sym` に対応するシンボルが存在するため、// そのシンボルを返すconst sym2 = Symbol.for("sym");console.log(sym1 === sym2); // true;もう1つの静的メソッドであるSymbol.keyForは、Symbol.forとは逆にシンボルを引数として受け取り、そのシンボルに対応するキーの文字列を返す。const sym1 = Symbol.for("sym");console.log(Symbol.keyFor(sym1)); // symつまり、これらの静的メソッドを使えばどこからでも取得可能なシンボルを作成できる。このようなシンボルを WeakMap のキーとして許容するのかというのが論点である。WeakRef 等でも同様にシンボルをサポートするのか？WeakRef や WeakSet、FinalizationRegistry 等の弱参照に関係するその他のデータ構造でも同様にシンボルをサポートするかどうかについては、それをすることもできるししないこともできるということらしい。今の所明確なユースケースは存在しないが、WeakMap のキーとしてシンボルを追加することと一貫させるためにそのような仕様の修正が行われることはあるのかもしれない。おわりに提案のタイトルからわかりやすい仕様ではあるが、細かい部分でまだ決まりきっていないところもあるので引き続き議論を追っていきたい。また、Prettier や Babel などの開発では実際にこの仕様を使うようなシーンもありそうなので頭に入れておきたい。

JavaScript の Symbols as WeakMap keys について

2001 年 03 月 01 日に生まれたので、昨日 2021 年 03 月 01 日に 20 歳になりました。もしプレゼントをくれる方がいればこちらのほしいものリストからお願いします。https://www.amazon.jp/hz/wishlist/ls/2VMKXAI8J8278?ref_=wl_shareサイボウズフロントエンドエキスパートチームは毎月フロントエンドマンスリーという配信イベントをやっていて、自分もそれに出演しているんですが、配信終了後チームメンバーから誕生日を祝ってもらえて嬉しかったです。終わって @__sosukesuzuki の誕生日をお祝いした#サイボウズフロントエンドマンスリー— Sakito (@__sakito__) March 2, 2021 20 歳というのはなんとなく人生の節目っぽいので、現在の気持ちについて書きます。5 年後とかに今書いたこの文章を見て自分がどう感じるのか気になります。今のところソフトウェア開発者としてある程度まともになってきてはいるのかなーという感覚はあって、仕事とか OSS とかちょっとずつだけどやれているのでそのへんは良かったかなと思っています。これに関しては 10 代後半くらいからの出会いに恵まれた + 好きなことをやらせてくれる両親がいたのが本当に大きかったと思っていて、自分と関わってくれた色々な人にとても強く感謝しています。自分は(少なくとも今は)プログラミングが好きだし楽しいので、技術的なことに関しては正直あまり大きな心配はしていません。現状に満足しているわけじゃないんですが、勉強することもコードを書くことも人との会話も楽しいので、それらを今後も継続できると思っています。プログラミングや会話が楽しくなくなってきたら焦ると思います。ただプログラミング以外のスキルや素養については大いに心配しています。お金のこととかキャリアのこととか様々なライフイベントとかそういうことについて考えられていないし知識も乏しいです。少なくとも法律の上では大人と言われる年齢になってしまったので、そういうことをちゃんと勉強したり考えたりする必要があるんだろうなと漠然と思っています。やる気は全然湧いてきません。そしてお酒が飲めるようになったので誰かお酒を飲みに行きましょう(こんなご時世ですのでいけるようになったらですが)。

20 歳になった

現在 TC39 の 3 月のミーティングのアジェンダが GitHub にて公開されている(Link)。それによると、Module Frangments という新しいプロポーザルが@littledan氏によって提案される予定だ。この記事では、現在の Module Frangments の概要とモチベーション、構文について解説する。もしさらなる詳細に興味がある場合は https://github.com/littledan/proposal-module-fragments を読んでほしい。また、Module Fragments は現在 Stage 0 の提案であり、今後仕様が大きく変わっていくことが予想されるのでその点には注意してほしい。概要Module Fragments はインラインで JavaScript のモジュールを定義するための構文を導入する提案である。詳細は後述するが、次のような構文を用いて1つのファイル内に複数のモジュールを定義し、import できる。// filename: app.jsmodule "#count" {  let i = 0;  export function count() {    i++;    return i;  }}module "#uppercase" {  export function uppercase(string) {    return string.toUpperCase();  }}import { count } from "#count";import { uppercase } from "#uppercase";console.log(count()); // 1console.log(uppercase("daniel")); // "DANIEL"module ~~ からのブロックが Module Fragments が導入する構文だ。moduleキーワードのあとにモジュール指定子を置き、そのあとにブロックを配置することでモジュールとして扱うことができる。そして、import宣言のモジュール指定子として使うことで定義したモジュールを import できる。モチベーションModule Fragments は主に webpack や Rollup や Parcel などのモジュールバンドラーの出力として使われることを想定している。現在では多くの開発者が ECMAScript Modules(ESM) を使って開発を行っている。数年前まではウェブブラウザがモジュールシステムを解釈できなかったため、モジュールバンドラーを使ってモジュールシステムをエミュレートして単一(もしくは複数)の JavaScript ファイルを出力するのがウェブ開発の主流になった。しかし多くのウェブブラウザが ESM を実装した現在でも、読み込み時のコストなどの実行効率の懸念からモジュールバンドラーが広く使われている。しかしながら、モジュールバンドラーは ESM のセマンティクスを完全にエミュレートする必要があるため、その実装がかなり複雑になってしまう。また、ESM に関連する仕様はこれからも増えていくことが予想される。たとえば、top-level awaitやImport Assertionsなどのモジュールに関する仕様が ECMAScript に追加されるたびに各モジュールバンドラーはそれらをエミュレートするための実装を行う必要がある。さらに V8 や JavaScriptCore などの実際にウェブブラウザなどで動作する JavaScript エンジンは、バンドルされたあとのコードを実行することになるので開発者が記述したままのモジュール構造を見ることができない。そのためモジュールの構造を利用した最適化ができずパフォーマンスに悪影響を及ぼすことがある。Module Fragments は実行時のオーバーヘッドが低いためバンドラーの出力として使うことができ、以前に比べてモジュールバンドラーがエミュレートするべきモジュールの仕様を減らすことができる。また、モジュールバンドラーはモジュールの構造をそのまま吐き出すことができるようになるので、JavaScript エンジンはその構造を見ることができるようになる。構文Module Fragments では import ステートメントや export ステートメントのようなモジュールのトップレベルに配置できる新しい非終端記号を導入する。ECMAScript の仕様で言えばModule Itemに新しいステートメントが追加されるということになる。module "#m" {}また Module Fragments をネストすることはできず、必ずトップレベルで宣言する必要がある。// NGmodule "#m1" {  module "#m2" {}}ECMAScript のプロポーザルについて調べたことがある人なら、Module Blocksという現在 Stage 2 のプロポーザルで提案されている構文と似ていることに気がつくかもしれない。Module Fragments も Module Blocks もmoduleというキーワードを使うが、Module Blocks ではモジュール指定子を指定せずにmoduleの後にすぐ{がくるので構文的に衝突することはない。// Module Blocksconst m = module {};// Module Fragmentsmodule "#m" {}Module Fragments が実行されるランタイムがブラウザの場合、module キーワードのあとに続くモジュール指定子を表す文字列は # から始まる URL フラグメントで使える文字列である必要がある(つまり ASCII 文字列)。この指定子を使って絶対または相対 URL として Module Fragments で定義されたモジュールを import できる。// In https://example.com/bundle.jsmodule "#counts" {  let i = 0;  export function count() {    i++;    return i;  }}import { count } from "https://example.com/bundle.js#counts";なおこれは ECMAScript の仕様ではなくブラウザに限定された規則である。そのため、例えば Node.js や Deno などの別のホストがこれに従う必要はない。しかし、それらのホストでも必要に応じてこの規則に従うことが推奨されている。おわりに筆者がこの提案を見たときは Module Blocks と構文上の類似点が気になったが、この 2 つは全く異なるモチベーションで提案された提案である。Module Blocks は、Worker コンストラクタなどにそのままモジュールを渡すことで Web Workers などの利便性を向上させるなどの目的があるが、Module Fragments はバンドルのチューニングの目的で使われることになるのだろう。そのため一般のウェブアプリケーション開発者が直接 Module Fragments を使うことは少ないように思うが、ライブラリ開発者やウェブアプリケーションのバンドルのチューニングを行う開発者は将来的には把握しておく必要がありそうだ。個人的には、先日提案されたDeferring Module Evaluationや、Module Blocks、そしてこの Module Fragments などモジュールのパフォーマンスや利便性を向上させるための提案が続々と出てきているのは興味深い。ESM 自体が安定して使われるようになってきた今、そのパフォーマンスや利便性が気になるフェーズになってきたということだろうか。

JavaScript の Module Fragments について

過去のブログ記事で紹介した prettier-regression-testing というツールを Prettier Organization に移管した。Prettier のユーザーにとって何かが変わるとかそういうことは全くないのだが、自ら作成したリポジトリを OSS の Organization に移管したのは初めてだった。他のメンテナーにとっても便利だったらしいもともと prettier-regression-testing は自分がリリースするときにリグレッションが発生しないことを確認するのを簡単にするためのツールだった。大規模 Closure Tools プロジェクトに Prettier を導入するまでの道のり - Cybozu Inside Out | サイボウズエンジニアのブログこちらの記事でも紹介したように、Prettier のリリース前リグレッションチェックはすべて手動で行われており面倒だったので、自動化するため prettier-regression-testing を開発した。基本的には自分ひとりで使う想定で開発したが、他のメンテナーたちも使ってくれてより便利にするための PR を投げてくれた。コードが汚すぎたしかし prettier-regression-testing はありえないくらいメンテナビリティの低いコードになっていた。GitHub Actions 上で動作する JavaScript のコードを書くのがはじめてだったため手探りで書きなぐってしまい、結果としてワンファイルの JavaScript で、書いた本人ですら一ヶ月後には読めなくなってしまうようなコードが誕生した。その状態でも PR を投げてくれた他のメンテナーたちの適応力には驚いたが、さすがに「このままではだめだ...」と思い始めた。そんな気持ちを抱えたまま 4 ヶ月が経過し、そしてメンテナーの一人によって CLI で動かすためのかなり大きな PR が作成された。「このまま PR を受け入れてしまってはもう取り返しのつかないことになる」と思ったので、そのメンテナーには「本当に申し訳ないんだけど、週末に TypeScript でこの機能までカバーできるように書き直すから、そのときにレビューをしてほしい」という旨を伝え、週末に本気で書き直した。移管する意外と上手く書き直すことができ、「みんなにとっても便利そうなら、Prettier Organization に移管したいんですがどう？」と尋ねたところ賛成してもらえたので、移管した。移管作業自体は簡単で、GitHub のドキュメントに従って操作したらすぐ終わった。感想と教訓自分が自分のために作ったものが他人にも使ってもらえるというのは嬉しかった。また Prettier Organization のような公式の場所に自分の作ったリポジトリが置かれているのもなんとなく嬉しくなれる。自分しか使わないようなツールでも誰かの役に立つことがあるというのは色々なところで言われていることなので知識としては頭に入っていたが、それを実感できて良かった。今後も自分のためのツールであっても積極的に公開していきたいと思う。そして今回の件から得られた教訓としては、それがたとえ自分のためのものであろうが、長期的に使うかどうかわからないものであろうが、できるだけコードは丁寧に書いた方が良いということだ。こちらも当たり前のことかもしれないが、実際にそれで困ったという経験が得られたのは結果として良かったかもしれない。「丁寧に書く」というのは曖昧で難しいが、Node.js での開発においてはまず TypeScript を使うということと、少なくとも入出力の再現が容易である操作に関してはユニットテストを書いておくというのは意識したほうが良さそうだ。

はじめて自分で作ったリポジトリを OSS の Organization に移管した

https://sosuke.dev をブログにしていたんですが、わけあってドメインを失効してしまったのでしばらくの間ははてなブログに書くことになりそうです。2020 年ももうすぐ終わります。今年は OSS の開発に多くの時間を費やしてきた実感があるので、実際どのプロジェクトで何ができて逆に何ができなかったのか振り返り、そして来年はどのように OSS と向き合っていくのか考えていこうと思います。(GitHub Sponsors できない(免許もパスポートもない)ので、僕の活動を応援してくれる人がいたら下のほしいものリストからアマギフを aosukeke[at]gmail.com まで送ってくれるととても嬉しいです)https://www.amazon.jp/hz/wishlist/ls/2VMKXAI8J8278?ref_=wl_share主に関わったプロジェクトずっと JavaScript ツールチェイン系のプロジェクトに関わっていて、主に Prettier と Babel の 2 つの開発に関わっていました。Prettier去年の 9 月にコミット権限をもらってからアクティブに活動をしています。去年から引き続きバグ修正や機能追加など「みんなが求める Prettier」のクォリティを維持するための開発をしています。長く関わっているといろいろと自分の意見が出来てくるもので、様々な決定に関わったりとある程度重要な立場になってきたと感じています。また、アクティブなメンテナーの数は減る一方という状況もあり、 2.1 からはリリースブログとリリースを担当するようになりました。2.1 のリリースのときは大変緊張しましたが、パッチリリース含めて何度かリリースを繰り返す度に慣れてきていて、リリーススクリプトの改善等もできるようになってきました。2020 年のコントリビューションの数を見るとこんな感じです。コードレビューが多いので、コードを書いた数はそんなに多くありません。2020 年のコミットの数を見るとこんな感じです。まあ、そこそこやっているという感じでしょうか。質を劣化させないことは出来たと思うけど、プロジェクトを先に進める開発は全然できなかったなと思います。来年はもう少し大きな開発をやりたいと思っています。Babel9 月末頃から「パーサーの実装が気になって仕方がない！！！」という気持ちが出てきて、Babel のパーサーの実装を読み始めました。そこからバグを見つけ次第コミットしまくっていたら、10 月頃に Org に招待されました。I've joined @babeljs ! pic.twitter.com/Fvp5KsmndB— Sosuke Suzuki (@__sosukesuzuki) October 18, 2020 招待されるまでがかなり早かったように思えますが、Prettier メンテナーとしての活動で Babel と関わることもあったのでそのあたりで認知されていたのも影響しているのかなーと思っています。Babel 側のバグ修正を大量にやった結果、Babel のパーサーに依存している Prettier 側のタスク量がめっちゃ増えたのは大変でしたが「エコシステムを改善しているんだ」という感覚を持ててよかったです。Babel のシンタックスエラー直しまくったら Prettier の方の作業量めっちゃ多くなってびびってる https://t.co/TrUzTaqLMH— Sosuke Suzuki (@__sosukesuzuki) October 15, 2020 最近はバグ修正だけではなくて、新しいプロポーザルの実装なども自らお願いして担当したりしてます。https://zenn.dev/sosukesuzuki/articles/432588a7c8287d2020 年のコントリビューションを見るとこんな感じです。数は全然多くないですね。2020 年のコミット数はこんな感じです。こちらも全然多くはないですね。とはいえ、2020 年に限ればコアチームのメンバーたちの次に多いみたいです。Babel ではまだまだ新人コントリビューターという感じなので、引き続き貢献しつつもっと価値を出していけるようになると良いなと思ってます。あんまり Babel にとって役に立つことはできませんでしたが、得たものは大きかったように思います。Babel の開発をしていると ECMAScript の仕様をちゃんと眺めつつ実装していくことがよくあるので、そういった仕様を読む力がついたと思うし、なにより以前に比べて JavaScript に詳しくなったと感じています。その他のプロジェクトガッツリ時間を使ったのは Prettier と Babel だけでしたが、暇なときにその他にもいくつか自分が使っている OSS にちょこちょこ PR や Issue を出していたような気がするので見てみます。typescript-eslintPrettier が依存していたり Babel の AST との互換性を意識しているのもあってたまにコミットしていたAST の型がキレイについてて開発体験が良いExcalidraw出たばかりの頃に小さなバグをいくつか直したりした最近は全然やってなくてわからないけど、大学の課題で木書くときとかにたまに使ってるDefinitelyTypedPrettier の型定義が壊れがちなのでたまに直したりしていた他のライブラリはほとんどやってないと思うリポジトリが巨大なのであまり好きではないeslint-plugin-vue一時期インターンで Vue を使っていたので新しいルールを追加したりバグを直したりした最近は Vue を使ってないし全然やってないけど一応ウォッチしているmizchi/mdbufMarkdown を書くときに使っているエディタブラウザで動くしシンプルだしそこそこ速いので便利バグを修正したりダークモード追加したりしたこんな感じです。どれも楽しかったです。来年どうしていくのか今年関わったプロジェクトには関わり続けていくつもりです。特に Prettier は自分がいなくなるとちょっとやばそうだし。ただ同じことばっかりやっていても飽きるので、でも JavaScript は好きなので、来年は C++ を勉強して V8 や JavaScriptCore みたいな実用エンジンを読んだりできそうだったら貢献したりしたいなーと思ってます。あと、OSS プロジェクト内で価値を出していくにはやはり英語で議論する力が必要だと感じることも多かったので、コーディングの時間を減らして英語学習に使ったほうがいいかなとも思っています。

2020年 OSS 活動振り返り

はじめにImport Assertions は現在 Stage 3 の ECMAScript のプロポーザルである。2020 年 9 月に行われた TC39 のミーティングで Stage 3 になった(ミーティングノートは https://github.com/tc39/notes/blob/master/meetings/2020-09/sept-22.md#import-assertions-for-stage-3 にて公開されている)。Babel では 先日リリースされた 7.12 から Import Assertions を使えるようになった。この記事では現時点での Import Assertions について解説する。概要このプロポーザルは従来の import 文 にインラインの構文を追加し、モジュール指定子とは別に詳細情報の指定を可能にする。主に想定される用途は JavaScript 以外のタイプのモジュールのサポートだ。Import Assertions で追加される構文を使って JSON modules を import する例を考える。import json from "./foo.json" assert { type: "json" };import json from "./foo.json" までは従来の import 文と同様の形をとっている。その直後にある assert { type: "json" } の部分が Import Assertions で提案されている構文だ。この例では import されるモジュールが JSON modules であることを示している。ちなみに、JSON modules というのは Import Assertions とは別の Stage 2 の ECMAScript のプロポーザルである。もともとは Import Assertions のプロポーザルに含まれていたが、個別のプロポーザルとして分離された。JSON modules は JSON のモジュールとしての扱いを統一することを目的としている。現状では、それぞれの環境(例えば webpack や Node.js など)が JSON のモジュールとしての扱いを自由に実装できる。そこで JSON modules を仕様として定めることで、ECMAScript の仕様の準拠したすべての場所で一貫して動作させることが可能になる。本題とそれてしまうのでここでは JSON modules について詳しく解説はしない。構文まず構文について見ていこう。上述の通り基本的には import 文の後ろに assert というキーワードが続き、更にその後ろに詳細情報をオブジェクトリテラルのように記述する。import json from "./foo.json" assert { type: "json" };Import Aserttions がこのような中括弧を使った記法を採用したのには2つの理由がある。1つは、JavaScript を使う開発者はすでにオブジェクトリテラルの記法に慣れているため。もう1つは、将来的にassert以外の属性を指定できるようになる可能性があり、その場合に様々な属性に対してグルーピングを行うためである。以下の例を見てほしい。import json from "./foo.json" assert { type: "json" } with { transformA: "value" };この例では、assert { type: "json" } の後ろに with { transformA: "value" } という他の属性が続いている。このwithという属性は現在の仕様には含まれてはいない。しかし、将来的にこういった他の属性が別の提案として追加されることが想定されている。このとき中括弧を使ったオブジェクトリテラルのような構文によってそれぞれが属性に対応するグループだということがわかる。Import Assertions は import のみではなく export に対しても使うことができる。export { val } from "./foo.js" assert { type: "javascript" };また、Import Assertions は dynamic import をサポートしている。その場合、関数の第 2 引数にオブジェクトリテラルを渡すようにして指定する。import("foo.json", { assert: { type: "json" } });経緯次に、このプロポーザルが生まれたモチベーションや経緯について解説する。当初は、新しい構文を追加することなく JSON をモジュールとして読み込むための、Import Assertion とは異なる仕様として提案されていた。この提案では、次のようにして JSON をモジュールとして import できる。import json from "./foo.json";これは多くの非標準の環境での JSON の読み込みと似ている。たとえば、Node.js では --experimental-json-modules フラグをつければ上記のコードをそのまま実行できるはずだ。この提案は多くの開発者からの支持を受けた。その結果、whatwg/html にマージされ、Microsoft によって Chromium に実装された。しかし、あとになってセキュリティ上の問題が指摘された。もとの仕様では、例えば次のようなコードがあるとき通常は JSON が import されることが想像されるだろう。import foo from "./foo.json";しかし、宛先のサーバーで MIME タイプが変更されたり、宛先のサーバーが悪意を持った攻撃にさらされたりした場合に意図せずなにかを実行してしまう可能性がある。この問題に対する解決策として Import Assertions が ECMAScript に提案されることになった(当初は Module Attributes という名前だった)。Import Assertions では、import する側が import される側のコンテンツをどのように解析するべきかを指定できるため、そのような問題を防ぐことができる。ちなみに、もとの仕様は現在ではwhatwg/html からリバートされている。おわりに現在 Stage 3 であるため、よほどのことがない限り ECMAScript に正式に含まれることになるだろう。実際、TypeScript や Deno ではすでに実装が検討されている。更に詳細が気になる場合は https://github.com/tc39/proposal-import-assertions を見てほしい。

JavaScript の Import Assertions について

以前投稿した7 月と 8 月と 9 月前半の OSS 活動の中で、9 月前半までの記録を含めてしまったが、それ以降もそれなりに活動をしていたので改めて 9 月の OSS 活動として紹介したいと思う。9 月は Prettier のメンテナーとしての活動を続ける傍らで Babel のパーサーの改善も行っていた。Prettier は JavaScript をパースするときにデフォルトでは @babel/parser を使用するので、Babel のパーサーの改善は間接的に Prettier を改善することにもつながる。実際、自分が今月行った改善のおかげでいままで Prettier がフォーマットできなかったコードが一部フォーマットできるようになるので、Babel がリリースされたらテストケースを追加しようと思う。prettier/prettier2.1.2 をリリースした。これは 2.1 で発生したリグレッションの修正のみを含むパッチリリースである。Prettier のようなコードフォーマッターでは、何が破壊的変更なのかという判断が非常に難しいので、厳密に semver を守れている自信はないのだけど、できるだけ semver に従ったバージョニングをしていきたいと思っている。そのため、2.1 で発生したリグレッションの修正以外のコミットはリリースに含めたくなかった。しかしすでにmasterブランチにそういったコミットが入っていたので、手動でpatch-releaseブランチにcherry-pickしてそこからリリースした。ローカルの Git で行う作業が多いリリースは非常に緊張する。I've published @PrettierCode 2.1.2. This version includes some bug fixes. Please see changelog for detail.https://t.co/XoCPFUW6qm— Sosuke Suzuki (@__sosukesuzuki) September 16, 2020 2.1.2 に含まれる以下の変更もほとんど自分が行った。GraphQL: Fix formatting for directives in fields(9116)GraphQL でフィールドに対するディレクティブのインデントが崩れるというバグの修正だが、正直自分は GraphQL 1回も書いたことないので直してみてから有識者に聞いたところ挙動に問題はなさそうとのことだったのでマージした。Fix line breaks for CSS in JSstyled-components などの CSS in JS で改行が一部の改行が壊れるというバグの修正。// Inputstyled.div`  ${(props) => getSize(props.$size.xs)}  ${(props) => getSize(props.$size.sm, "sm")}  ${(props) => getSize(props.$size.md, "md")}`;// Outputstyled.div`  ${(props) => getSize(props.$size.xs)}  ${(props) => getSize(props.$size.sm, "sm")}  ${(props) => getSize(props.$size.md, "md")}`;YAML: Fix printing doubles a blank line before a commentこれは YAML のコメントと空行を組み合わせると奇妙なフォーマットが起こるというバグで、今でもよくわかっていない。YAML のシンタックスは自分には難しく、そしてほとんど書いたことがないので実は未だによくわかっていない。なので他のメンテナーに一部引き継いでもらった。未だに不安定な気はするものの、リグレッションは修正できたのでその状態でリリースを行った。まだリリースされていはいないいくつかの変更もここで紹介する。Use better fonts in Playground。Playgroundを等幅フォントに変更した。これによってスペースの数などを目視で確認するのが圧倒的に楽になった。Release script: Commit and push after updating dependents count。https://prettier.io には Prettier に依存しているパッケージの数が掲載されており、リリーススクリプト内でリリースと同時に更新している。しかし、実際には変更だけしてコミット・プッシュがされていなかったのでするように修正した。Refactor: Use set instead of array。これはRefactorとタイトルに書いてあるが、実際にはリファクタリングというよりパフォーマンス改善にあたる。Set のような使い方をされていた配列を、Set と WeakMap を使って書き換えた。sosukesuzuki/prettier-regression-testinghttps://zenn.dev/sosukesuzuki/articles/753d7ec2d65e154599c3 に書いたが、GitHub Actions を使って Prettier にバグがないかを確認するツールを開発した。個人で開発したものだが、OSS 活動のために作った OSS なのでここに書いておく。babel/babel先月はなぜか Babel パーサーへの意欲が高まってしまい、10 個ほど Pull Request を作成した。すべてシンタックスエラーの改善だが、一部は Prettier の挙動に影響を及ぼす。Babel は最近になって(7.9 から) errorRecovery 機能が導入されたこともあり、シンタックスエラーがあまりヒューマンフレンドリーではない傾向にある。そういった挙動を修正するのは比較的簡単だがあまり手がつけられていないようなので、もし Babel へのコントリビューションに興味がある人がいたらそこから挑戦していくと良いかもしれない。メンテナーとしての責任や義務感がないので、全体的に楽しくやることができた。そして JavaScript や TypeScript について多少詳しくなれたような気がする。Throw a syntax error for a declare function with a body現在の Babel は次のような変換を行う。// Inputdeclare function foo() {};// Outputfunction foo() {}この入力は TypeScript のインバリッドなコードだが、このような変換がされるのはバグである。Babel のパーサーは ambient context の関数だろうが、ボディがあれば FunctionDeclaration としてパースするためこのようなバグが起こる。本来であれば TSDeclareFunction としてパースするべきで、例えば typescript-eslint/typescript-estree はそのようにパースする。また、このコードはインバリッドであるため、errorRecovery可能なシンタックスエラーを吐いてあげると人間に親切である。なので、そのように修正した。Throw a syntax error for a parameter properties in not constructor現在の @babel/parser は次のようなエラーをスローする。// Inputclass C {  not_constructor(readonly foo: string) {}}// ErrorUnexpected token, expected "," (2:27)この入力は constrcutor 以外に対してパラメータープロパティを使っているためインバリッドな TypeScript のコードだが、このエラーはあまりにも不親切である。そしてこのエラーは errorRecovery 不能なために、例えば次のようなコードを Prettier に入力するとエラーになる。class C {  // o が足りない  constructr(readonly foo: string) {}}本来 Prettier は書きかけのコードであってもある程度フォーマットができてほしいので、これは修正する必要がある。なので、errorRecovery 可能なシンタックスエラーを吐きつつ、パースは成功するように修正した。Throw a syntax error for a constructor with type parameters現在の @babel/parser は次のようなコードに対してエラーをスローしない。// Inputclass C {  constructor<T>(foo: T) {}}しかしこのコードは constructor に型引数があるので TS 的にはインバリッドである。なのでシンタックスエラーをスローするように修正した。Do not throw an error for optional binding pattern params in function declaration現在の @babel/parser は次のようなコードに対してシンタックスエラーをスローする。// Inputexport declare function ohai({ foo }?: Args): string;// ErrorA binding pattern parameter cannot be optional in an implementation signature. (1:29)implementation signature ではないのにこのエラーが出るのはバグで、実際 TypeScript コンパイラーではこのエラーは出ない。なので修正した。Throw an error for a declare class field that have an initializer現在の @babel/parser は次のようなコードに対してシンタックスエラーをスローしない。// Inputclass A {  declare bar: string = "test";}本来 TypeScript では declare なフィールドに初期値をもたせることはできないはずなので、シンタックスエラーを吐くべきである。なので修正した。Add missing tests for TypeScript syntax errorsこれは足りていなかったテストケースを追加した。よく使われている OSS でも意外とこういうことがある。Improve syntax error for class fields in ambient context「初期値を持つ declare なクラスフィールドにシンタックスエラーをスローしない」、というのは修正したが、ambient context なクラスフィールドの定義方法は他にも存在し、それらに対してもシンタックスエラーをスローするように修正した。// Inputdeclare module m {  class C {    field = "field";  }}そして、エラーメッセージを TypeScript コンパイラと統一した。[ts] Throw a syntax error for index signature with declare現在の @babel/parser は次のようなコードに対してシンタックスエラーをスローしない。// Inputclass C {  [key: string]: string;}TypeScript では declare な index signature というのは定義できないはずなので、シンタックスエラーをスローするように修正した。Throw a recoverable error for missing initializer in const declaration現在の @babel/parser は次のようなコードに対して errorRecovery 不能なエラーをスローする。// Inputconst a;// ErrorUnexpected token (1:9)これは人間にとってわかりにくいので、errorRecovery可能なエラーをスローし、パース自体は成功するように修正した。Throw a syntax error for empty type parameter/argument現在の @babel/parser は次のようなコードに対してシンタックスエラーをスローしない。// Inputlet a: Foo<>;TypeScript コンパイラは空の型引数に対してシンタックスエラーをスローするので、それに合わせる形で修正した。

9 月の OSS 活動 (Prettier とか Babel とか)

背景Prettier をリリースする前には実際に Prettier を使っているプロジェクトのソースコードに対して新しいバージョンの Prettier を実行し、リグレッションが起きていないかを確認する必要がある。前回のリリースを担当したので、この作業も自分でやったのだけどかなり面倒くさかった。というのも、次のような作業を手動で行う必要があったから。そのタイミングでの最新バージョンの Prettier を使っているプロジェクトを GitHub で探す。フォークする。クローンして、Prettier のバージョンを master(prettier/prettier)に更新する。package.json を読んで Prettier を実行するスクリプトを探して実行する。差分をコミットしてフォークに Pull Request を投げて他のメンテナーに共有する。これらの工程を手動でやるのは、難しくはないけどとても面倒くさい。できればもうやりたくないので、よしなに自動化できたらいいなーなんて思ってた。そして、これとは別の文脈で、「Prettier のリリース頻度遅くない？」みたいな話がユーザーからもメンテナーからもあがっていた。それはそうで、1回のマイナーリリースに約半年かかることもある。これは別に意図しているわけではなくて、人手が足りなかったりしてそのバージョンでやりたいことが達成できず、ユーザーに急かされてリリースする、といった流れになっていた。なので、「月に1回マイナーリリースしたいねー」みたいな話を自分から提案してみた。https://github.com/prettier/prettier/issues/9095まだ決まったわけではないけど、個人的には月に一度のマイナーリリースを実現したいと考えている。月に一度マイナーリリースをするということは、上記のリグレッションチェックの工程を月に1回しなければならないということで、それは本当に面倒くさいし楽しくないので、やはり自動化をしなければと思い立ちそういう Issue を作った。(ついでに、自分のプライベート的にも 10 月からはオフラインとはいえ大学も普通に始まるし、最近自動車教習所に通い始めてしまったので、Prettier に割く無駄な時間は積極的に減らしていきたいと考えていた。)https://github.com/prettier/prettier/issues/9290この Issue で、自分は「自動化したいなー」というくらいの話しかしていなくて具体的な手法については全然考えていなかったのだけど、他のメンテナーから、別リポジトリに切り出して git submodule と GitHub Actions を使って Pull Request 上で差分を確認したいみたいな提案があった。確かに Prettier 本体のリポジトリで色々いじるより小回り聞くし別リポジトリでさっくりやってみるかーと思い作り始めた。概要開発したものは sosukesuzuki/prettier-regression-testing においてあって使い方も書いてあるので先にみたい人はそちらを見てください。使い方は簡単で、基本的には Issue に run という内容でコメントするだけ。それをトリガーにして GitHub Actions のワークフローが実行される。そのワークフローでは、 git submodule として事前に登録してあるリポジトリのソースコードに対して、新しい Prettier(これも submodule として追加されている)を実行する。実行した結果なにか差分があればそれを Issue コメントとして返す。なければない旨を表示する。Prettier のコミットハッシュやブランチを指定できると便利なので、run with checking out 36c35be2109e4d4d4b0e89862c993e15e22cc6d1 みたいなコメントをするとそこにチェックアウトした上で実行し、差分をコメントしてくれる。当初 Pull Request で差分を確認するつもりだったが、submodule 内の差分を Pull Request で確認する方法がわからなかったから Issue コメントとして実装してみたら意外にもいい感じだったのでそのままいくことにした。どうしても Pull Request 上で確認したくなったら git submodule じゃなくて git clone することになりそう。しくみまず、prettier/prettier が git submodule として ./prettier に置いてある。ワークフローで実行する Prettier はこの submodule です。そして、Prettier を実行する対象のリポジトリは submodule として ./repos 下ににおいてある。現在は自分が過去に何度か貢献していてなんとなく勝手がわかっている typescript-eslint/typescript-eslint と vuejs/eslint-plugin-vue がある。そして、ワークフローがトリガーされると次のような順番で処理が行われる。./prettier の依存をインストールする。(run with checking out ... で実行されていた場合、チェックアウトする)./repos 下においてあるリポジトリに対して ./prettier/bin/prettier.js を実行する(Prettier は素の JavaScript で書かれているので、GitHub から落としてきたものをそのまま実行できる)git diff --submodule=difff ./repos で対象のリポジトリに生まれた差分をテキストで得る。差分のテキストを含めた Issue コメントを作成する。簡単に言えばこのような感じ。ちなみに自分はシェルスクリプトや YAML を書くのが苦手なので、上記の工程は全部 JavaScript で書いた。(sindresorhus/execaを多用した。) https://github.com/sosukesuzuki/prettier-regression-testing/blob/97c104bab18ce9683532e0b76c9585034e5890f5/index.js にこの記事を書いている時点でのコードがあります。所感まだ対象にしているリポジトリが少なすぎるので、追加していきたいと思っている。できれば、TypeScript と JavaScript 以外のものをどんどん追加していきたい(その２つは得意なメンテナーが多い)。Vue の SFC とか GraphQL とかのコードを Prettier でフォーマットしているプロジェクトをご存知の人がいたら教えてくれると嬉しいです。それにまだ実際にリリース時のリグレッションチェックの作業に使ったわけではないので、本当に便利なのかはまだ正直わからない。でも手動でやるよりは明らかに楽になるのでリリースの頻度をあげられるんじゃないかなーとは思ってる。

GitHub Actions で Prettier がバグってないか確認する

7 月から 9 月前半までの OSS 活動の振り返りです。prettier/prettierブログにも書きましたが初めて自分でリリース行ったりしてコード書く以外のちょっと面倒なことの分量が増えたかなーという感覚があります。リリースの間隔が長すぎるというのはメンテナーたちも課題だと思っていて、月 1 マイナーリリースを目指そうかなーみたいな話がありつつも、最近自動車教習所に通い始めて自由な時間が減っている+秋学期は単位をとらないとまずいのでどうなるかはわかりません。2.1 のリリース2.1.1 のリリース2.1.2 のリリース#8849 remark v8 へのアップデートに伴うテストの追加#8820 #8849 では足りてなかったテストの追加#8740 一部の関数で JSDoc の型が正しく参照できてなかったので修正#8710 型チェックに使っている tsc がデバッグ用のファイルを無視するように修正#8692 TS4.0 でShort-Circuiting Assignment Operatorsが導入されるのでそのためにテストを追加#8689 一部の関数で JSDoc の型が正しく参照できていなかったので修正#9078 CSS in JS で不要な空白が挿入されるバグの修正#9058 ブログ記事の下書きを生成するスクリプトを修正#9024 過去に行った#7889 のリバートが不十分だったので続き#8982 TypeScript 4.0 サポート#8984 各 Pull Request に含まれるチェンジログからブログ記事を生成するときに一部文言を置換するように修正#8981 新しい Prettier を typescript-eslint のソースコードで実行したときに発生したバグの修正(1)#8967 新しい Prettier を typescript-eslint のソースコードで実行したときに発生したバグの修正(２)#8932 2.1 リリースブログを追加#9083 リリーススクリプトを実行するタイミングで dependents cound を更新してリモートリポジトリにプッシュするように修正#9164 Array を Set っぽく使ってるところで Set を使うように修正#9136 CSS in JS で一部改行が崩れるバグを修正#9116 GraphQL で一部インデントが崩れるバグを修正#9143 YAML で一部改行が二重にプリントされてしまうバグを修正kintone/dts-gen#325 標準の no-unused-vars ではなく @typescript-eslint の no-unused-vars を使うように修正acronjs/acorn-jsx#115 JSX Element にカッコなしで yield したときにシンタックスエラーになるバグを修正SchemaStore/schemastore#1213 Prettier 2.1 用のスキーマに修正mizchi/mdbuf#19 GraphQL コードブロックを書いたときに止まるバグを修正babel/babel#12061 babel-parser でコンストラクタ以外にパラメタプロパティを使ったときに出るシンタックスエラーを改善、またリカバリ可能に修正

7月と8月と9月前半の OSS 活動

先日 Prettier のバージョン 2.1 をリリースしました。いままでコミット権限をもらってから１年ほど経ちますが自分でリリースをしたのははじめてでした。こういう記録をあんまり見たことないような気がするので、やったこととかメンタルのことを書き残しておこうと思います。やったことリリースチェックリストの Issue を作るhttps://github.com/prettier/prettier/wiki/Release-Checklist にリリース前にやることリストのテンプレートがおいてあるので、それをコピーして Issue を作ってピンしておきます。(https://github.com/prettier/prettier/issues/8882)基本的にはこのチェックリストにしたがって作業を進めていきます。作業を整理するPrettier は GitHub で管理されていて、バージョンごとの作業の管理にマイルストーン機能を使っています。マイルストーンの運用に厳密なルールはなくて、メンテナが各々必要そうだなと思ったものをマイルストーンに入れています。なので、優先度の低いものや今はリソースが足りなくて取りかかれないものなどが入っていることがあります。そういったものをマイルストーンからはずして本当に次のリリースに必要なものだけを残します。作業を完遂するマイルストーンを整理したら、そこに入っている作業をこなします。今回のリリースでは、主に２つの作業がありました。remark パーサーのアップデートに伴うテストの追加と、メンバーチェインのフォーマットの中途半端な改善のリバートです。結構めんどくさい(難しくない)作業なんですが、頑張ってガガッと終わらせました。リバート作業の方は最初ミスってあとからまた直しました。いまのところそれが原因っぽいリグレッションは報告されてないから多分大丈夫だと思います。リリースブログを用意するhttps://prettier.io/blog/2020/08/24/2.1.0.html こういうやつを用意します。https://github.com/prettier/prettier/pull/8932Prettier のリリースブログは長くてしっかりしていると言われることがたまにありますが、全部の PR に Changelog をつけてもらっていてそれをスクリプトでくっつけているのであんまり記事の Author が書く量は多くありません。でもプレビューしてみてコードブロック狂ってるとかシンタックスハイライトきいてなさそうみたいな不具合は修正する必要があります。他のプロジェクトで新しい Prettier を実行してみてバグってないか確かめるPrettier を使っているいくつかの OSS のコードベースに対して新しい Prettier を実行してみておかしなところがないかを探します。(https://github.com/prettier/prettier/issues/8882#issuecomment-671021183)僕がそのリポジトリの勝手がわかっている方がやりやすいので、過去に何度か貢献したことのあるプロジェクトの中から良さそう(書かれてる言語とかが異なるもの)を選びます。今回はtypescript-eslint/typescript-eslintとvuejs/vue-eslint-plugin、excalidrawを使いました。この作業は結構めんどくさくて、それぞれフォークしてそのリポジトリの Prettier を更新して実行してフォークに PR 作ってみんなに共有して〜〜みたいな作業を手動でします。自動化したいのでよさそうな方法を考えています。また、本当はもっと多くのプロジェクトに対してこれをやるべきだと思っているので、もし Vue(SFC)や Angular や GraphQL で書かれた Prettier を使っているよさそうな OSS をご存知の方がいたら教えて下さい。見つけたバグを直す↑ の作業で見つかったバグを修正します。https://github.com/prettier/prettier/issues/8941https://github.com/prettier/prettier/issues/8943これが結構面倒。簡単に直せるやつならいいけど、今回はちょっと難しかった...。TypeScript 4.0 の空気を読むこれは今回特有。2.1 準備中に TS4.0 の RC が出たり Babel が 7.11 で TS4.0 をサポートしたり typescript-eslint も一部の構文だけサポートしたり他のエコシステムの対応状況を見つつ、どこまでサポートをするべきかを考えます。結局準備が長引いている間に TS4.0 の本リリースが行われたので、フルでサポートしました。これは依存しているパーサーを更新したりちょっとテスト書いたりすればいいから技術的には簡単です。https://github.com/prettier/prettier/issues/8646リリースするそんな感じで、チェックリストの項目を全部クリアしたらリリースします。リリーススクリプトが用意されているので基本的にはそれを実行して表示される指示に従えば問題なくリリースできます。過去のメンテナーに感謝です。一個おもしろい話としては、リリース準備中活動していたメンテナは僕含め誰も npm へのパブリッシュ権限をもっていなかったのでリリースができなかったタイミングがありました。結局過去のリリースを行った人に頼んで権限を付与してもらいましたが。ちなみにめっちゃ緊張しました。「なんかミスったらやべえぞ！！！」と思ってましたが、結果としてはほとんど何事もなくリリースが完了しました。メンタルっぽい話自分はバグを直したり機能を追加したりコミュニケーションをとったりするのは楽しいと感じるから全く苦ではないのですが、リグレッションをチェックする作業とかリリースブログを用意する作業とか Issue を眺めて治ってるかチェックする作業とかはきつくて、「めんどくせーーー」と思いつつも僕がやらなかったら誰もやらないもしくはやるのがだいぶ遅れることになるので、頑張ってやりました。自分は今大学が夏休みで、お仕事(業務委託)の稼働時間も少なくなっているので Prettier のための作業をする時間が結構確保できたけど、フルタイム社会人やりながらこういうことやってる人は時間の使い方が上手すぎるだろと思います。そういう人を目指して頑張ります。なんか自分で色々とめんどくさいこともやってみて、お金のないコミュニティベースの OSS が持続しているのは偶然っぽいし、もし将来なにかしらの理由で億万長者になることがあったら OSS にお金をあげたいなあと思いました。ただ、自分でリリースをすると達成感は明確にありました。数年前まで中学校の校庭でサッカーしてたやつのマシンから世界中で使われるソフトウェアがリリースされてるってすげえな...と感動しました。

はじめて自分で Prettier をリリースした

５月いっぱいで、それまで月 100 時間くらいやってたインターンをやめたので OSS に多くの時間を割くことができるぞ！！！と意気込んでいたんですが、その割にはサボっちゃいました。無念。しかも 6 月末から新しいお仕事を初めてしまったので、7 月はどのくらい時間を使えるかわからないですねえ、頑張っていきたい。ただその会社では OSS 活動が割と推奨されてるので少なくともモチベは維持できそうだと思ってます。みんな褒めてください。海外出たことなくてパスポートがなく、運転免許もないので GitHub Sponsor を始められていないのですが、僕を個人的に応援したい人がもしいたらそうすけ応援セット(ほしいものリスト)から水とか米を送ってくれると大変モチベーションに繋がります。Prettierめんどくさくなっちゃったのでスクリーンショットで...。一番下に Definitely Typed があると思うんですが、これは Prettier の doc builder の一部が型定義になかったので追加したやつです。２つまだオープンになっている PR がありますが、これらは影響範囲が大きいので慎重にすすめています。もう Prettier を壊したくないので！一番上に大きく表示されているものは、二項演算子とコメントを組み合わせたときにインデントが崩れるというもの。https://github.com/prettier/prettier/pull/8476a +  a + // comment  a;このコードがa +a + // comment  a;こんな風に修正されてしまう。このバグは今まで報告されていなくて、他のメンテナーがテストケースを作ってるときに発見したみたいなんですが、多分パイプライン演算子が入ってきたらこういうコードが頻繁に書かれる気がするので、パイプラインが ECMAScript とか TypeScript に入る前に直せてよかったですね。他にも、まだ実装途中なんですがちょっと大きめの修正をやっています。https://github.com/prettier/prettier/pull/8554三項演算子とコメントを組み合わせたときに、コメントが意図に反して移動してしまうというもの。test  // comment  ? first  : second;こんなふうに、条件と ? の間にコメントをいれるとtest  ? // comment    first  : second;? のあとに移動してしまいます。これは前々から報告があったもので、だいぶ前に実装して PR を出して放置してたんですがやっぱりやったほうがよさそうだったのでその PR を閉じて新しく始めたものです。これを実装してテストーケースを書いていく中でいくつか三項演算子とコメントを組み合わせたときのフォーマットのバグを発見したので、それらも修正しました。あと日本語話者の方々からしたら興味深い問題であろう、Markdown のラテン文字と日本語の間にスペース入っちゃう問題も水面下で進行中です。僕は前々からこの挙動はおかしいから直すべき、という立場なんですが、個人的にはラテン文字と日本語の間にはスペースを入れるスタイルを好んで使っています（あくまで個人が好きに選択すべきであって、Prettier が干渉すべき問題ではない。それを縛りたいのであれば textlint 等でやるべき、という主張です）。So you actually do use spaces between Latin and Japanese characters. Now I'm confused.— Georgii Dolzhykov (@thorn0) June 12, 2020そしたら他のメンテナーから、「（君いつもラテン文字と日本語の間にスペース入れるのはおかしいって言ってるけど）実際ツイートではそういう風に書いてるじゃん...、どういうこと...？」という反応を頂いておもしろかったです。mizchi/mdbufmizchi さんが作ってるシンプルなマークダウンエディタ。ブラウザですぐ開けて動作も軽快なので好んで使っています。自分は昔Boostnoteっていうののメンテナンスをしていたことがあって、そのときにマークダウンエディタについて色々考えたんですが、複雑なエディタは重かったり、複雑すぎてバグっていてメンテナンスがきつかったりとか色々あって、速くてシンプルなものを選ぶようになりました。自分でも作ったりしたんですが、そういった自作を含めても mdbuf が一番使いやすいので愛用しています。このブログや Prettier のチェンジログとかも mdbuf で書いていて、本当によく使っているんですが、チェンジログを書いてるときに vue のコードブロックを書くと止まっちゃうことに気づきました。それではちょっと困るので、vue コードブロックのシンタックスハイライトを無視するようにしました。https://github.com/mizchi/mdbuf/pull/13余談ですが、GitHub のリポジトリページに contributors という項目があるんですが、そこに mizchi さんと syake さんと僕で並んでしまっていて、なんかちょっと申し訳ない気持ちになっています。(syake さんは favicon とかを修正してくれたみたいです。タブから探すのがめっちゃ楽になってすごくありがたいです。)

6 月の OSS 活動

https://github.com/sosukesuzuki/prettier-doc-interpreterPrettier ではコードを整形する過程で Doc という中間表現を使うのですが、それをシュッと試せる JavaScript の(構文的には)サブセットを作ってブラウザで動かしてみました。これがあると、Prettier を開発するときに Doc の挙動をすぐに確かめられるので嬉しくなります。Prettier のしくみまず、Prettier のしくみをざっくり説明します。フォーマットしたいコードを受け取ったら、それをパースします。パースしたら、AST を再帰的に見ていってこの記事の主役である Doc と呼ばれる中間表現に変換します。Doc はフォーマットの対象の言語に依らず、テキストの形を表現するためのデータ構造で、最終的に文字列に変換されます。そして変換された文字列を返します。Doc の作り方と形Prettier のソースコード内には Doc を生成するための関数や変数(doc builder)が定義されていて、次のように使われています。("foo"と"bar"は通常の JavaScript の文字列リテラルです)const doc = group(concat(["foo", hardline, "bar"]));ちなみに、doc builder のドキュメントは https://github.com/prettier/prettier/blob/master/commands.md にあります。このとき変数docは次のようなオブジェクトになっています。// 変数 doc の中身{  "type": "group",  "contents": {    "type": "concat",    "parts": [      "foo",      {        "type": "concat",        "parts": [          {            "type": "line",            "hard": true          },          {            "type": "break-parent"          }        ]      },      "bar"    ]  },  "break": false}このオブジェクトをprintDocToStringという関数に渡すと文字列に変換できます。const { formatted } = printDocToString(doc);console.log(formatted); // => foo\nbarこのあたりのロジックは Prettier のコアとなる部分で、開発初期のころからほとんど変更されていません。プラグイン作る人くらいしか使わないと思いますが、doc builder やprintDocToStringはprettierパッケージで export されています。作ったものhttps://github.com/sosukesuzuki/prettier-doc-interpreterDoc を生成するための式(e.g. group(concat(["foo", hardline, "bar"])))を文字列として受け取って、変換した結果の文字列(e.g. "foo\nbar")を返す関数です。まだちょっとバギーだし機能不足なんですが...。$ npm install prettier-doc-interpreterで入ります。こんな感じで使えます。import { evaluate } from "prettier-doc-interpreter";const source = `group(concat(["foo", hardline, "bar"]))`;const formatted = evaluate(source);console.log(formatted); // => foo\nbarしくみ(受け取った JavaScript のコードを実行して返すものなので、最初はevalでやっちゃおうかなーとも思ったんですが、危険だったりエラーを丁寧に吐けなかったりするし、おもしろくないのでやめました。)まず、受け取ったコードを acorn でパースします。そしたら AST を上から見ていって、prettier/standaloneから import した doc builder に渡して Doc を作ります。このときに不正なノードや変な形をした Doc があったらエラーを投げます。最後に、作った Doc をprettier/standaloneから import したprintDocToStringに渡して文字列に変換して、返します。パーサーに acorn を使った理由ですが、ブラウザで動かすことを考えるとできるだけ軽量なものが望ましいというのと、TS とか JSX とかをパースするつもりはなかったので @babel/parser みたいな高機能なものは不要だったというのがあります。ただ、acorn の型定義はちょっと弱いので、型定義だけは@types/estreeを使ってみました。const ast = acorn.parse(code, { locations: true }) as any as ESTree.Node;多分本当は acron の吐く AST と ESTree の型定義は異なると思うけど、とりあえず問題なく動いたのでよし！問題がでたら直すかも。ブラウザで動く Playground もあるよhttps://prettier-doc-playground.netlify.app/https://github.com/sosukesuzuki/prettier-doc-playgroundpreact と TypeScript でできています。prettier-doc-interpreterの実行は Web Worker でやってます。comlink-loader便利ですね。人に共有できると便利なので、状態を URL ハッシュにもたせています。こういうやつにはよくある機能ですね。

Prettier の中間表現 Doc をシュッと試せる JavaScript のサブセットを作ってブラウザで動かす

5 月のオープンソース活動です。意外とちゃんとやってた。PrettierVue や HTML の改善をやっていたような気がします。あと Babel 7.10 や TypeScript 3.9 の対応も若干。ここに載せた以外にも細かな改善もしました。Vue の SFC のパース改善https://github.com/prettier/prettier/pull/8153Prettier は HTML をパースするためにangular-html-parserという Angular の HTML パーサーのフォークを使っているんですが、Vue の SFC のような HTML ではないけど HTML っぽいものにもそれを使用しています。今までは Vue の SFC をそのまんま HTML としてパースしていました。なのでカスタムブロック内や pug 等の HTML 以外の言語を使った template 内に HTML タグとして認識されちゃう文字のパターンを入れるとシンタックスエラーになっていました。(Playground Link)<custom-block>const foo =    "</";</custom-block>これを解消するためにいくつか方法を考えました。vue-eslint-parserを使うか？とか、Vue 公式の SFC コンパイラのパーサーを使うか？とか。しかし、前者はカスタムブロックのサポートを公式にはしていないようで今回のニーズを満たすパース結果が得られず、後者はルートのコメント情報がパース結果に残らずフォーマッターに使うには不十分でした。なので angular-html-parser を修正してもらって、最終的に少々トリッキーな方法で解決しました。気が向いたらそのお話もどこかに書くかもしれません。Stage-1 プロポーザル private filed in in の対応https://github.com/prettier/prettier/pull/8431Babel 7.10 で対応された Stage-1 のプロポーザルの対応です。次のようなコードはいままでシンタックスエラーだったんですが、フォーマットできるようになります。Prettier 側の対応はパーサーのバージョンアップとオプションの指定だけだったので楽でした。#prop in obj;TypeScript 3.9 で入った Non Null Assertion と Optional Chaining の解釈の変更の対応https://github.com/prettier/prettier/pull/8450リリースノートを見て TypeScript 3.9 は新しい構文ないから Prettier の対応ないじゃん！って思ってたらありましたね。Babel 7.10 も同様の修正が入っているので、babel-tsパーサーにも対応しています。TypeScript 3.8 まではx?.y!.z;は(x === null || x === void 0 ? void 0 : x.y).z;という JavaScript にコンパイルされていたんですが、TypeScript 3.9 からはx === null || x === void 0 ? void 0 : x.y.z;にコンパイルされるようになりました。なので以前までの挙動を再現したい場合にカッコを補ってあげなくてはいけないんですが、Prettier はそのカッコをはずすようにフォーマットをしていたので、維持するようにしました。// Input(a?.b)!.c;// Prettier stablea?.b!.c;// Prettier master(a?.b)!.c;eslint-plugin-vueno-arrow-functions-in-watch ルールの追加https://github.com/vuejs/eslint-plugin-vue/pull/1155ドキュメントに書いてあるんですが、Vue のwatchにアロー関数を使うのはアンチパターンです。thisで束縛される値が変わってしまって、Vue インスタンスを指さなくなります。なので、watchにアロー関数を使っているときに警告を出すルールを追加しました。詳しくは eslint-plugin-vue のドキュメントの https://eslint.vuejs.org/rules/no-arrow-functions-in-watch.html を見ていただけると。typescript-eslintmethod-signature-styleルールの自動修正のバグの修正https://github.com/typescript-eslint/typescript-eslint/pull/1966TypeScript では interface の関数プロパティを二通りの方法で書くことができます。// メソッドのショートハンドinterface T1 {  func(arg: string): number;}// 通常の関数プロパティinterface T2 {  func: (arg: string) => number;}method-signagure-styleルールはこれをどちらかに強制できます。ただ、メソッドのオーバーロードがあったときにメソッドのショートハンドから通常の関数プロパティに強制すると、ルールの自動フォーマットの結果がエラーになってしまうバグがありました。例えば、次のコードを通常の関数プロパティに強制することを考えます。interface T {  method(): void;  method(arg: string): void;  method(arg: number): string;}今までの実装だと、このようにフォーマットされていました。interface T {  method: () => void;  method: (arg: string) => void;  method: (arg: number) => string;}実際試してみるとわかりますが(Playground link)、これはDuplicate identifier 'method'.でコンパイラに怒られてしまいます。なので、これを intersection types としてフォーマットすることでエラーを回避します。interface T {  method: (() => void) & ((arg: string) => void) & ((arg: number) => string);}これはセーフになります(Playground link)。

5 月の OSS 活動

Deno では以下のようにサブコマンドを実行することで、ソースコードのフォーマットをできます。ref: https://deno.land/manual/tools/formatter$ deno fmt example.tsオフィシャルにコードフォーマッターを提供することによって、少なくとも Deno の世界のために記述されるコードのスタイルが開発者によってバラバラになったり、そのために議論が生まれるということはなさそうです。これは大変良いことです。この deno fmt コマンドの内部では以前までは Prettier が使用されていたのですが、 deno v 0.32.0 から dprint という Rust で書かれたコードフォーマッターが使われるようになりました。ref: https://github.com/denoland/deno/pull/3820この dprint、どうやら実行速度がとても速いという噂を聞いたので、実際のコードでためして Prettier と比較してどの程度速いのか試してみようと思います。実行マシンとベンチマーク方法以下の性能の MacBook Pro で計測を行います。MacBook Pro (13-inch, 2019, Four Thunderbolt 3 ports)プロセッサ 2.4 GHz Intel Core i5メモリ 16 GB 2133 MHz LPDDR3グラフィックス Intel Iris Plus Graphics 655 1536 MB以下のような形のディレクトリを作り、dprintとprettierをローカルインストールします。/repositories下には https://github.com/prettier/prettier と https://github.com/mictosoft/typescript がクローンされています。dprint.config.js と prettierrc はデフォルトのままにします。.├── dprint.config.js├── package.json├── repositories│   ├── prettier│   └── typescript└── yarn.lockhyperfineを使って、それぞれnode_modules/.bin/下にある bin を叩いて計測をします。計測してみるまず、そこまでコード量が多くない https://github.com/prettier/prettier の /src ディレクトリ下の JavaScript ファイルを対象にして時間を計測してみます。対象ファイル数: 117対象コード行数: 29205$  hyperfine "./node_modules/.bin/dprint \"repositories/prettier/src/**/**/*.js\"" "./node_modules/.bin/prettier \"repositories/prettier/src/**/**/*.js\" --write" --ignore-failureBenchmark #1: ./node_modules/.bin/dprint "repositories/prettier/src/**/**/*.js"  Time (mean ± σ):      1.209 s ±  0.206 s    [User: 4.046 s, System: 0.139 s]  Range (min … max):    1.003 s …  1.663 s    10 runsBenchmark #2: ./node_modules/.bin/prettier "repositories/prettier/src/**/**/*.js" --write  Time (mean ± σ):      2.519 s ±  0.135 s    [User: 4.123 s, System: 0.136 s]  Range (min … max):    2.318 s …  2.709 s    10 runsSummary  './node_modules/.bin/dprint "repositories/prettier/src/**/**/*.js"' ran    2.08 ± 0.37 times faster than './node_modules/.bin/prettier "repositories/prettier/src/**/**/*.js" --write'平均値を見てみます。dprint: 1.209 sprettier: 2.519 sこの規模のプロジェクトでも、 dprint のほうが 2 倍くらい速くなっています。少し大きめのコードでも試すために、 https://github.com/microsoft/typescript の /src 下の TypeScript ファイルに対してもやってみます。対象ファイル数: 430対象コード行数: 438366$  hyperfine "./node_modules/.bin/dprint \"repositories/TypeScript/src/**/**/*.ts\"" "./node_modules/.bin/prettier \"repositories/TypeScript/src/**/**/*.ts\" --write" --ignore-failureBenchmark #1: ./node_modules/.bin/dprint "repositories/TypeScript/src/**/**/*.ts"  Time (mean ± σ):      5.295 s ±  0.143 s    [User: 7.884 s, System: 0.213 s]  Range (min … max):    5.132 s …  5.548 s    10 runsBenchmark #2: ./node_modules/.bin/prettier "repositories/TypeScript/src/**/**/*.ts" --write  Time (mean ± σ):     22.387 s ±  0.242 s    [User: 38.089 s, System: 1.103 s]  Range (min … max):   22.121 s … 22.848 s    10 runs  Warning: Ignoring non-zero exit code.Summary  './node_modules/.bin/dprint "repositories/TypeScript/src/**/**/*.ts"' ran    4.23 ± 0.12 times faster than './node_modules/.bin/prettier "repositories/TypeScript/src/**/**/*.ts" --write'平均値を見てみます。dprint: 5.295 sprettier: 22.387 sこの規模になってくると差が顕著になってきますね。速い体感でわかるくらい速いし、測ってみたら速かったです。今後 Deno や dprint がどうなっていくかはわかりませんが、1.0 がリリースされる前の段階で dprint のような Rust 製のコードフォーマッターに移行したのは英断だったように思います。コードフォーマッターとしての性能はまだ見れていないのでなんとも言えませんが、もしかしたら通常の TypeScript/JavaScript プロジェクトにも採用できるかもしれません。今度は、 dprint に Prettier のテストケースを食わせてちゃんとフォーマットできるかやってみようと思います。

Deno に採用されたコードフォーマッター dprint が速い

4 月の OSS 活動です。今月は仕事と大学の方がそこそこ忙しく思うように OSS に時間をとれませんでしたが、カスタムブロックのサポートやずっと放置していたパイプラインオペレータのサポートができたのでそこは良かったかなと思います。PrettierSmart / F# スタイルのパイプラインオペレータのサポートhttps://github.com/prettier/prettier/pull/6319ECMAScript のパイプライン演算子のプロポーザルには３種類ありますが、Prettier がサポートしているのはMinimal Pipelineのみでした。この PR では、それ以外のSmart Pipeline、F#-style Pipelineのサポートを追加します。この PR は実は 2019 年の 6 月に作成していたのですが、実装が難しい箇所があり約 10 ヶ月放置していました。しかし、唐突に良い実装を思いついたので実装してマージしました。Vue のカスタムブロックのサポートhttps://github.com/prettier/prettier/pull/8023Vue の SFC の中にはカスタムブロックとして任意の言語を記述できます。しかし、渡されたテキストを見てもどの言語で書かれているのか判別できないという理由で、いままで Prettier はその中に書かれたコードをフォーマットしていませんでした。それでは不便なので lang や type 属性をカスタムブロックタグにつけた場合、それに対応した言語としてフォーマットを行う機能を追加しました。<template>  <p>foo</p></template><custom-block lang="javascript">const foo =     "foo";</custom-block>↑ このコード中のcustom-block の中身は JavaScript としてフォーマットされるようになります。将来的には、2.1 から追加される embeddedLanguageFormatting オプションを使って属性なしでのフォーマットができるようにしたいと考えています。(DefenitelyTyped) 型定義を 2.0 用に更新https://github.com/DefinitelyTyped/DefinitelyTyped/pull/435762.0 でいくつか API が更新されたけど追従できてなかったので修正します。typescript-eslintexplicit-module-boundary-types ルールに shouldTrackReferences オプションを追加https://github.com/typescript-eslint/typescript-eslint/pull/1778explicit-module-boundary-types ルールは、export されている関数の型を明示することを強制します。しかし、変数に代入された関数の場合は警告が出ません。これは警告が出るexport const foo = (arg) => arg;これは警告が出ない(よくない)const foo = (arg) => arg;export default foo;なので、shouldTrackReferencesオプションを追加して、それが true のときは変数の参照を追って警告を出すようにしました。以前までとの挙動が変わることはありませんが、このオプションはデフォルトで true になります。

4 月の OSS 活動

誰かがこれを見てなにかを参考にしてくれたらいいなぁっていう気持ちと、自分のための活動の記録として、OSS 活動を毎月適当なタイミングでまとめていこうと思います。その３月分です。Prettier最近レビューばかりでバグ修正とかがあんまりできてなかったんですが、３月は結構できました。7709: 改行を含む変数代入・宣言のときのコメントの位置の修正改行とブロックコメントを含む変数の代入・宣言が壊れちゃうやつです。このバグによって Closure Compiler や JSDoc など、式の直前にコメントが存在することに意味があるツールでは、意味を破壊されてしまいます。// Inputconst foo = /* comments */  bar;// Outputconst foo /* comments */ = bar;// This PRconst foo = /* comments */ bar;7729: 空の型パラメータの中にコメントいれるとエラーが出るこれは一体誰が困るんですかね。// Inputconst a: T</* comment */> = 1;// OutputError: Comment "comment" was not printed. Please report this error!// This PRconst a: T</* comment */> = 1;7764：TypeScript 3.8 の export * as ns 構文のサポートexport * as ns のサポートです。これで、TS 3.8 から入るすべての構文のサポートが完了しました。7804: Babel パーサーでの TypeScript 3.8 type only import/export の対応2.0 から parser=babel-ts オプションをつけることで Babel を使って TypeScript のパースができるようになったのですが、TypeScript 3.8 で追加された type only import/export のサポートができていませんでした。この PR はそれを修正します。ちなみに、type only import/export は Babel 7.9 から入っているんですが、リリース直後にそれ周りのバグを見つけたのでツイッターで Babel のメンテナチームの方に確認したら、一瞬で Issue が作られて一瞬で直されて一瞬でリリースされていました。ありがたい。7869: TypeScript の as を二項演算子としてフォーマットする今まで TypeScript の as は行の幅が長いときにうまいことフォーマットされないことがありました。例えば、下の例の場合は、= に直後に改行が入ることが期待されると思います。// Inputconst varibale = foooooooooooooooooooooooooooooooooooooooooooooooooooo as SomeType;// Outputconst varibale = foooooooooooooooooooooooooooooooooooooooooooooooooooo as SomeType;これは、as に対してあまり凝ったロジックを使わずにフォーマットしていたので、想定通りといえば想定通りの挙動でした。ただ、TypeScript の as は基本的に JavaScript の二項演算子(3 + 3 の + とか)と同様のフォーマットをして問題なさそうということになったので、そのように修正しました。これは、もともと Babel や ESLint のメンテナのkaicataldoが実装しかけていたアイデアを引き継いだものになります。// This RPconst varibale =　　foooooooooooooooooooooooooooooooooooooooooooooooooooo as SomeType;7892: Flow の inexact object type で他にプロパティがないときにコメント入れるとエラーが出るこれも誰が困るんだろうシリーズかもしれない。Flow 書かないからよくわかんないけど。// Inputtype Foo = {  // comment  ...,};// OutputError: Comment "comment" was not printed. Please report this error!// This PRtype Foo = {  // comment  ...,};eslint-plugin-vue1086: no-template-target-blankルールの追加まだマージされてません。eslint-plugin-react のjsx-no-target-blank相当のことを Vue のテンプレートでやります。これによって、rel='noreferrer noopener' なしで target='_blank' を使ったときに警告がでるようになります。このルールはもともと会社で必要だったので社内向けに作ったのですが、せっかくだから eslint-plugin-vue に追加してみようと思い PR を投げました。

3 月の OSS 活動

追記:3 月 21 日にPrettier 2.0はリリースされ、無事 TypeScript 3.8 のサポートも行われました〜ここから本文:TypeScript 3.8 の正式版が 2 月 20 日 にリリースされましたね。(リリースノート)type only import/export や ECMAScript private field、top-level await など、いくつかの便利な新しい構文がサポートされるようになりました。でもまだ、 Prettier はそれらをサポートできていません。ベータ版リリース直後から Issue はつくられていた3.8 のベータ版がリリースされたのが 1 月 10 日です。(リリースノート)実はその翌日の 1 月 11 日に Prettier に Issue が作られています。(prettier/prettier#7263-Support TypeScript 3.8)対応するのを忘れていたとか、必要だと思っていなかったとかそういうわけではなく、きちんと認識した上でまだサポートできていません。新しい構文のサポートはパーサーライブラリに依存するPrettier は自分でパーサーを実装しておらず、外部パーサーライブラリに依存しています。(JavaScript のパースには @babel/parser を使っているし、 Markdown のパースには remark を使っています。)TypeScript のパースには、typescript-eslint チームが開発している typescript-estree を使っています。これは、 TypeScript Compiler API を使って TS コードをパースし、それを ESTree っぽい AST に変換するためのライブラリです。そして、新しい構文のサポートをするときはこの依存するパーサーの負担が大きくなります。Prettier 側が大変なことも構文の種類によってはあると思いますが、今回追加される構文たちの場合、すでに(見た目の上では)似た構文が存在するので printer の修正は難しくないと思います。Babel や ESTree との兼ね合いtypescript-eslint/typescript-eslint#1465-WIP: feat: new ast for typescript 3.8-comment新しい構文のサポートをするとき、 typescript-eslint チームだけでそれを行うことはできません。各々が勝手に実装すると、ツール間で扱う AST のノードの形がずれてしまうため、Babel や ESTree と相談しつつ決定する必要があります。以前、TypeScript 3.7 で実装された Optional Chaining と Nullish Coalescing のときにこのあたりで若干失敗しているようです。3.7 がリリースされたあと typescript-estree は Babel と同様の形のノードを採用する決定をしました。(Babel の AST の仕様)しかし、 ESTree はそれとは異なる形のノードを採用しようとしているので、ESLint は Babel/typescript-eslint とは違った AST を扱うことになります。(estree/estree#204-Update es2020.md for Dec 2019で Optional Chaining と Nullish Coalescing のノードの形が議論されていて、まだマージされていないみたいですが。)こういった自体を避けるため、今回は慎重になっているようです。あと typescript-eslint チームはだいたいみんなボランティアだから時間がないみたいです。待っててねつまり、Prettier チームとしては typescrit-estree の更新を待つ必要があり、それを開発している typescript-eslint チームとしては Babel や ESTree との兼ね合いがあるので全体的に遅れているという感じです。誰も悪くないので気長に待ちましょう。

Prettier の TypeScript 3.8 対応遅れてそうだけどどうしたの？

https://dev.to/arcanis/introducing-yarn-2-4eh1コアにかなり大きな変更が入ったらしい。v1 からのマイグレーションについてマイグレーションガイドがあるらしい。あとで読む。一応、メジャーなツールでは最新版を使っていれば特に問題は起こらないそう。ただ、Flow と React-Native は現時点では Plug’n’Play (PnP)環境では動かない。(PnP ってなんだろう)それぞれのチームと協力して頑張っていくらしい。v1 のメンテについて来週 1.22 がリリースされる予定で、それ以降は完全にメンテナンスモードに入る。つまり、脆弱性にパッチあてる以外のリリースはしない。新機能は Yarn v2 に対してのみ開発される。v1 のコードベースは、yarnpkg/legacy に移行される。数年後にアーカイブされるかも。v2 のコードベースが yarnpkg/yarn になることはない。履歴が消えるのが痛いから。当面は yarnpkg/berry のままで開発する。これまでのウェブサイトは legacy.yarnpkg.com に移動し、 v2 用のウェブサイト(今の next.yarnpkg.com)がメインドメインに移動する。Node の Docker イメージは、2020 年 4 月リリース予定の Node 14 から、Yarn 2 を出荷する。それまでは yarnPathを使ってすべての Node イメージで Yarn 2 をシームレスに使えるらしい。変更の詳細CLI の出力ほぼすべてのメッセージには独自のエラーコードが含まれていて、ドキュメントで検索できる。行ごとに色をつけるのではなく、各メッセージの重要な部分につける(通常はパッケージ名とバージョン)これからの数ヶ月の間に調整が入る(特に色覚異常へのアクセシビリティとか)ワークスペース周りyarn up <name> ですべてのワークスペースで使われているパッケージを更新できる。yarn add -i <name> で他のワークスペースで使われているパッケージと同じバージョンを再利用する。version pluginってのがあるらしい。あとで読む。ゼロインストールゼロインストール機能はないけど、そのために調整された Yarn の機能が多くある。ベンダーファイルをキャッシュから直接読むから、リポジトリにキャッシュが含まれている場合 yarn install が不要。リポジトリサイズに大きな影響が出るけど、yarn 1 のオフラインミラー機能と同様に合理的らしい。yarn 1 のオフラインミラーを知らないのであとで読む。詳細はゼロインストールのドキュメントを読むと良いらしい。yarn dlxdlxは`download and execute の略)npx と同じことを脆弱性低めにやる。yarn workspaces foreachyarn workspaces foreach run build` みたいなことができるようになるらしい。オプションで、並列実行するかとかスキップするワークスペースを選んだりできる。patch:プロトコル依存関係ツリーの特定のパッケージに変更を適用したいときに使える。{  "dependencies": {    "left-pad": "patch:left-pad@1.3.0#./my- patch.patch"  }}portal: プロトコルlink:と似てる。portal:は推移的な依存解決をするけどlink:はそうじゃないらしい。このあたりはよくわからん。ワークスペースのリリース全く新しいワークフローを設計したらしい(https://next.yarnpkg.com/features/release-workflow)あとで読むワークスペースの Constraints (日本語でこれを翻訳するべきなのかしないでそのまま書くべきなのかわかんない)Constraintsという新しいコンセプトが導入された。ワークスペースに対してバリデーションを Prolog を書くことができる例えば、次の Prolog で書かれたルールはアンダースコアに依存しないことを検証するgen_enforced_dependency(WorkspaceCwd, 'underscore', null, DependencyType) :-workspace_has_dependency(WorkspaceCwd, 'underscore', _, DependencyType).パッケージごとのビルド設定ビルドスクリプトをパッケージごとに実行するかどうかを指定できるようになった。現時点ではデフォルトではすべて実行する。enableScriptsですべてをオフにして明示的に実行するパッケージを選ぶこともできる。シェルのノーマライズYarn 2 の開発当初、Windowns 勢から PR をもらうことがよくあり、それらの多くは Bash でしか動かないとかの問題だったなので、scriptsに記述されるであろうものの 90%をカバーできるような簡易的なインタープリタを実装した。これによって OSX でも Windows でも関係なく実行できるようになった。Peer Dependency のリンクの改善Lock ファイルのフォーマットYarn 1 のときは、YAML ライクだけど YAML じゃない記法を使っていた。でもサードパーティ開発者にとっては厳しいので、YAML の標準にした。TypeScript で書かれたユーザーには影響はないが、Flow をやめて TypeScript で書かれている。Moduler Architectureこれを読めばわかりそうプラグインが作れるようになったから依存関係にアクセスしたいサードパーティツールの開発が楽になった。設定のノーマライズパーッケージの境界が厳密になったdependenciesにないパッケージは使えない。Buncle Dependencies の除去bundleDependenciesが使えなくなったらしいけど名前しか知らなかった使いたい場合は、マイグレーションガイドをよんで代替案を考えるべきRead-Only パッケージ安全性のためにパッケージが読み取り専用になったこういうことはできない:const { writeFileSync } = require(`fs`);const lodash = require.resolve(`lodash`);writeFileSync(lodash, `module.exports = 42;`);

Introducing Yarn 2 ! メモ

Prettier の.cjs対応をしようとおもって、すでに対応されているmjsとかで grep してもヒットしないからどこに情報持ってるんだろうって思って調べたメモをちょっとちゃんと書いたものです。前提1: Prettier はファイル名からパーサーを推測するPrettier を CLI から使うとき、parserオプションを使ってパーサーを指定できます。# パーサーオプションを指定してみる$ prettier foo.js parser=babelただし、ファイル名からパーサーを推測できるときは、parserオプションを省略できます。「foo.jsは拡張子が.jsだから、JavaScript としてパースすればいいよね」といった具合に、Prettier がパーサーを推測してくれます。# これもオッケー$ prettier foo.jsもっとも多いユースケースであるソースコードのフォーマットにおいては、パーサーを明示的に指定せずに使っている人が大半だと思います。2: JavaScript としてパースしてほしいいろんなファイル.js ファイルはもちろんですが.jsx や .es6 など、JavaScript としてパースしたいファイルが他にもいくつかあります。.cjsも JavaScript としてパースしたいファイル拡張子の1つなのですが、現時点で Prettier は対応していませんでした。(.mjsは対応しています。)$ prettier test.mjsconsole.log("Hello, ECMAScript Modules!");$ prettier test.cjstest.cjs[error] No parser could be inferred for file: test.cjs(補足)一応 .cjs について大雑把に解説しておきます。Node.js は CommonJS と ECMAScript Modules という２つのモジュールシステムをサポートしていて、あるファイルがそのどちらのモジュールシステムを使って書かれているのかを Node.js になんらかの方法で伝える必要があります。その方法の1つがファイル拡張子であり、.cjsの場合は CommonJS、.mjsの場合は ECMAScript Modules となります。詳しく知りたい人は https://nodejs.org/api/esm.html を読んでください。Prettier Pluginshttps://prettier.io/docs/en/plugins.htmlPrettier にはプラグインという機能があり、コアで対応できていない言語でも外部のプラグインとして対応できます。例えば、GitHub の Prettier オーガナイゼーション下には https://github.com/prettier/plugin-php や https://github.com/prettier/plugin-ruby といったプラグインが存在しており、コミュニティによって管理されています。Prettier のプラグインは次の５つを named export することで実装できます。(optionsとdefaultOptionsは必須ではなかった気がする)languagesparsersprintersoptionsdefaultOptionsこのlanguagesというのは、当然ですが決められた形をしたオブジェクトの配列で、そのオブジェクトにはextensionsというプロパティを含めることができます。そしてextensionsに渡す配列で、言語と拡張子の対応付け行っています。実は、JavaScript や HTML などのコアでサポートしている言語も、内部的にはプラグインとして実装されています。(これらは Prettier のソースコード内ではinternalPluginsと呼ばれています。)https://github.com/prettier/prettier/blob/master/src/common/internal-plugins.jsなので、前述のlanguagesはコアでサポートしている言語にも存在し、extensionsも存在します。linguist-languagesinternalPluginsの実装を読むと、extensionsはlinguist-languagesというライブラリからひっぱってきていることがわかります。どうりでどれだけ grep してもヒットしないわけです。ソースコードに含まれていないのですから。https://github.com/prettier/prettier/blob/master/src/language-js/index.js#L9これは Prettier のメンテナの一人であるika 氏が、github/linguistのlanguages.yamlを JSON に自動でフォーマットしたものみたいです。本家 linguist の.cjs追加は、https://github.com/github/linguist/pull/4703 で行われており、それに追従したlinguist-languagesが v7.7 としてリリースされていました。(Prettier が依存しているのは 7.6)つまり、依存しているlinguist-langagesのバージョンを 7.6=>7.7 にしたら直ったよっていう話でした。

Prettier がファイルパスからパーサを推測するときの情報源

昨年から引き続きですが、ずっと JavaScript か TypeScript を書いていました。先にまとめ18 歳になった筑波大学に入学したOSS 活動を再開して Prettier のコミッターになった勉強会で発表したUbie でフロントエンドの開発をしてます18 歳になった誕生日おめでとう自分— sosukesuzuki (@__sosukesuzuki) February 28, 2019 今年も 3 月に誕生日を迎え、18 歳になりました。祝ってくれた方々はありがとうございました。次の 3 月で 19 歳になります。筑波大学に入学した筑波大学情報学群情報科学類、合格！ｗ— sosukesuzuki (@__sosukesuzuki) October 19, 2018 筑波大学の情報学群情報科学類というところに入りました。わかりきっていたことですが、数学はできないし授業に出るのもできてなくて苦しいですが、友人はおもしろい人ばかりなのでなんだかんだ楽しく生きてます。学園祭実行委員会の情報っぽい部門に入ってたまにウェブアプリ書いたりウェブサイト作るお手伝いとかもやっていました。学園祭実行委員会は主に 2 年生が動くことになるので、来年はもっと開発や他のもろもろをやっていくことになると思います。OSS 活動を再開して Prettier のコミッターになったPrettier のコミット権限をもらったので、コミッタになりましたhttps://t.co/ZBNu13rM7s— sosukesuzuki (@__sosukesuzuki) September 28, 2019 高校 1~2 年生のときにBoostnoteのメンテナンスをやってたとき以来だと思いますが、本格的に OSS 活動を再開して、9 月末くらいに Prettier のコミッターになりました。僕の今年のコミット数は現時点(2019/12/21)で 39 コミットなのでそこまで多いわけではないんですが、Prettier はアクティブメンバーが少ないので 2019 年では 3 番目に多いことになります(通算では 13 番目)。Issue のトリアージや PR のレビュー等をしつつ、フォーマットのバグを直したり、たまにリファクタリングしたり、CI が壊れてるの直したり色々していました。Prettier で作業していると AST とにらめっこしたり依存している各パーサー(@babel/parser とか @typescript-eslint/estree とか)のバグとも戦ったりするので、JavaScript/TypeScript のシンタックスにそれなりに詳しくなれたんじゃないかなと思っています。今年は JavaScript/TypeScript の部分しか見られなかったので来年は CSS とか HTML あたりもやっていこうかなと思っています。勉強会で発表した昨年までは身内以外の勉強会とかで発表したことがなかったんですが、今年は何回か発表してみました。僕が知ってるような知識って大体の人が知ってるような気がしていたのでいままで発表するのを躊躇ってたんですが、 Prettier のコミッターって(多分)日本にいないのでそういう話をしていました。We Are JavaScripters!、Ginza.js、Nihonbashi.jsで発表させていただきました。運営の方々ありがとうございました。こうした発表を通じてエンジニアの知り合いができたのも嬉しかったです。来年はカンファレンスとかで発表できたらいいなと思っています。Ubie でフロントエンドの開発をしてます2018 年 12 月からインターンで参加している Ubie で、今年もずっと働いていました。最近はチームメンバーも給料も増えてきました。基本的には茨城からリモートで働きつつ、たまーに三越前のオフィスまで出社しています。具体的には、toC のウェブサービスの開発を Nuxt.js と TypeScript でやってます。まだオープンになっておらず、鋭意開発中のプロダクトです。機能追加やバグ修正など、コードを書く仕事をたくさんしつつ、エラー対応とかデプロイフローの改善とか Linter の整備とか(その一貫で@typescript-eslint にコントリビュートしたり)フロントエンド周りで色々と必要なことをたくさんやっていました。

sosukesuzuki

標準偏差さんとsksatのツイートから学ぶABI(Application Binary Interface)

VueFes Japan 2024の「次世代フロントエンドクロストーク」の感想ともっと聞きたかったこと

Intl.DurationFormatの最大値を規定する仕様について

JSCのUCDを更新するスクリプト

WebKitのコミッターになった

文字列リテラルから不要なエスケープを取り除くのってリンターの責務かも

WebKitにWasm Type Reflection API（の一部）を実装してみた

jscのWasm系APIをデバッグするためのスクリプト

JSCOnlyを実行するスクリプト

特定のmacOSで使われているICUのバージョンを調べる

MiniBrowser に JSC のオプションを渡す

Intlにおけるロケール識別子のマッチング

プライベートでMac使うのやめた

最近は意図的にGitHub Copilotを無効にすることがある

Xbyakで生成したコードをファイルに出して逆アセンブルする

TSKaigi 2024 Prettierの未来を考えるスピーカーノート

GitHub ActionsでM1 Macが開放されたことによって何もしてないのにNode.js14のCIが失敗するようになった

マジでどうでもいいWebKitのバグを修正した(Function.prototype.toString編)

ECMAScript の Set Methods プロポーザル

JavaScript である値がオブジェクト型であることを判定する変なテク

2023 年振り返り

2023 年の Prettier 振り返り

Prettier の Angular サポートの仕組みと built-in control flow 対応

C言語で書いたVM型正規表現エンジンをWebAssemblyにしてブラウザで動かす

テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携

【翻訳】Prettier's CLI: A Performance Deep Dive

【翻訳】Prettier を Rust で書き換えたプロジェクトに $20k の報奨金を支払うプログラムは Biome が勝ちました

JSConf JP 2023「書いたJavaScriptがそのままブラウザで動く未来へ」スピーカーノート

【翻訳】Prettier の新しい三項演算子のフォーマットを試してみてください

ガベージコレクション実装したいからLISP風インタプリタ作った

「ガベージコレクション自動的メモリ管理を構成する理論と実装」を読んだ

Prettier 3.0 をリリースしました

標準偏差さんとsksatのツイートから学ぶABI(Application Binary Interface)

VueFes Japan 2024の「次世代フロントエンドクロストーク」の感想ともっと聞きたかったこと

Intl.DurationFormatの最大値を規定する仕様について

JSCのUCDを更新するスクリプト

WebKitのコミッターになった

文字列リテラルから不要なエスケープを取り除くのってリンターの責務かも

WebKitにWasm Type Reflection API（の一部）を実装してみた

jscのWasm系APIをデバッグするためのスクリプト

JSCOnlyを実行するスクリプト

特定のmacOSで使われているICUのバージョンを調べる

MiniBrowser に JSC のオプションを渡す

Intlにおけるロケール識別子のマッチング

プライベートでMac使うのやめた

最近は意図的にGitHub Copilotを無効にすることがある

Xbyakで生成したコードをファイルに出して逆アセンブルする

TSKaigi 2024 Prettierの未来を考える スピーカーノート

GitHub ActionsでM1 Macが開放されたことによって何もしてないのにNode.js14のCIが失敗するようになった

マジでどうでもいいWebKitのバグを修正した(Function.prototype.toString編)

ECMAScript の Set Methods プロポーザル

JavaScript である値がオブジェクト型であることを判定する変なテク

2023 年振り返り

2023 年の Prettier 振り返り

Prettier の Angular サポートの仕組みと built-in control flow 対応

C言語で書いたVM型正規表現エンジンをWebAssemblyにしてブラウザで動かす

テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携

【翻訳】Prettier's CLI: A Performance Deep Dive

【翻訳】Prettier を Rust で書き換えたプロジェクトに $20k の報奨金を支払うプログラムは Biome が勝ちました

JSConf JP 2023「書いたJavaScriptがそのままブラウザで動く未来へ」スピーカーノート

【翻訳】Prettier の新しい三項演算子のフォーマットを試してみてください

ガベージコレクション実装したいからLISP風インタプリタ作った

「ガベージコレクション 自動的メモリ管理を構成する理論と実装」を読んだ

Prettier 3.0 をリリースしました

TSKaigi 2024 Prettierの未来を考えるスピーカーノート

「ガベージコレクション自動的メモリ管理を構成する理論と実装」を読んだ