Prettierの2万ドル懸賞金をBiomeが獲得

 (prettier.io)
3 ポイント 投稿者 GN⁺ 2023-11-28 | 1件のコメント | WhatsAppで共有
  • JavaScriptコードフォーマッタ Prettier は、フォーマットロジックが安定域に近づいたことで、Rustベースの互換実装を通じて 性能競争 を促そうとした
  • 11月9日、Prettierはテストスイート 95%通過 を条件に1万ドルの懸賞金を提示し、Vercel CEOのGuillermo Rauchとnapi.rsの追加により総額は2万2,500ドルになった
  • Biome は約3週間にわたり複数人で互換性を高めて懸賞金を獲得し、この過程でPrettierとの実際の互換範囲が急速に広がった
  • テストを合わせる過程で、Prettierの バグや疑わしい判断 も明らかになり、Prettier側でも改善のための具体的な根拠が得られた
  • Prettierは寄付金でメンテナー2人に毎月1,500ドルを支払ってきたが、現在の予算では 8か月分のランウェイ しか残っておらず、追加の寄付が必要な状態である

BiomeがPrettierの懸賞金を獲得

  • PrettierはJavaScriptコードフォーマッタで、人々がコードを書く非常に多様なスタイルを細かく扱うことで広く採用されている
  • フォーマットロジックはすでに堅牢な状態で、ternaries の作業が反映されれば満足できる段階に達すると見ている
  • 次の課題は 性能改善 である
    • Prettierはもともと高速なツールではなかったが、ほとんどのユースケースでは十分に速かった
    • 現状にとどまらないため、友好的な競争という形で改善を促した

  • 懸賞金の条件と参加

    • 11月9日、Rustで書かれたプロジェクトがPrettierのテストスイートを 95%通過 すれば受け取れる $10k bounty を提示した
    • Vercel CEOのGuillermo Rauchが同額を追加し、総額2万ドルになった
    • napi.rs が2,500ドルを追加した
    • Algora側は懸賞金向けのランディングページを作成した

  • Biomeの達成結果

    • Biome プロジェクトが懸賞金を獲得した
    • 約3週間で12人ほどが集まり、互換性を改善した
    • 詳細はBiomeの full report にある
    • テストを合わせる過程で、Prettierの bugs and questionable decisions も多数見つかり、Prettierはこれを改善できるようになった

性能競争が生んだプレッシャー

  • Prettierチームが別プロジェクトに資金をかけた理由は、性能競争 を生み出すためである
    • PrettierはJavaScriptコードフォーマッタ分野で支配的な地位にあった
    • 競争不足により、性能改善やさまざまなエッジケース修正への動機が乏しかった
  • いまやBiomeには、Prettierと互換性を保ちながらはるかに高速な実装があり、ユーザーは乗り換えることができる
  • Fabio SpampinatoはこのチャレンジをきっかけにPrettier CLIを本格的にプロファイリングし、いくつもの極端な非効率を発見した
    • これらの問題は年末までに修正する予定である

Prettierの寄付とメンテナンス予算

  • Prettierの懸賞金と継続的な運営は、多くの個人と企業による大きな寄付のおかげで可能になっていた

  • 主な企業寄付

    • Indeed: 20,000ドル
    • Frontend Masters: 10,850ドル
    • Sentry: 10,529ドル
    • Salesforce: 10,025ドル
    • Airbnb: 8,426ドル
    • Cybozu: 6,086ドル

  • 主な個人寄付

    • Shintaro Kaneko: 1,635ドル
    • Suhail Doshi: 1,000ドル
    • icchiman: 500ドル
    • Mariusz Nowak: 270ドル
    • Benoît Burgener: 270ドル
    • Jeremy Combs: 270ドル
    • f_subal: 230ドル
    • これらの寄付金により、Prettierは過去2年間、2人に毎月1,500ドルを支払ってきた うえでリリースを続けてきた
    • Fisker CheungとSosuke Suzukiがこの役割を担っている
    • 現在の予算では 8か月分のランウェイ しか残っておらず、追加の寄付が必要な状態である
    • Prettierを使って恩恵を受けているなら、https://opencollective.com/prettier で寄付できる
    • Open Collective はプロジェクト運営に大きく役立っている
    • メンテナーは個人情報を提供せずに登録できる
    • 銀行のように機能し、世界中で送金と受け取りができる
    • 税務書類も適切に処理する
    • Prettierは合計 11万ドル を集め、そのうち 7万5,000ドル を再分配した
    • 今回の懸賞金は一度限りだが、コードフォーマットのエコシステムに活力を吹き込み、より良い開発者体験を作ることが目的である

関連記事

1件のコメント

 
GN⁺ 2023-11-28
Hacker News の意見

  • Prettier チームがなぜ別プロジェクトに資金を出すのか気にはなったが、答えに十分納得できたわけではない
    Prettier の改善に懸賞金をかければよく、Prettier 改善の動機を作るために競合プロジェクトを作る理由がよく分からない
    最終的な目標が Prettier を畳んで Rust ベースのツールへ移行させることなのかも気になるし、すでに混乱しているエコシステムを不必要にさらに分断しているように見える

    • Prettier 改善の懸賞金ではなく別プロジェクトになったのには、3つの理由がありそうだ
      まず、Rust でフォーマッターを書くことは Prettier のコードベース改善とは性質が異なる。Prettier は Rust で書かれておらず、Rust はフォーマッター実装の堅実な選択肢であることが証明されているので、目標自体が Rust フォーマッターを書くことに近い
      次に、$20k で Prettier 所有の Rust フォーマッターを書いてほしいというのは魅力的ではない。優秀な開発者にとっては100時間分程度でプロジェクト完成には足りないが、自分が所有するプロジェクトとして報われるならはるかに魅力的だ
      3つ目に、Prettier が優勝プロジェクトを所有すると、保守責任も Prettier チームに生じる。もともと作ったチームは継続保守するインセンティブが減り、競争もなくなるため、エコシステムの活発さが下がる
    • オープンソースのメンテナーの立場では、全員が自分の特定の実装を使うことよりも、問題が解決されることのほうに関心がある
      自分のコードを誰かが使ったからといって直接得をするわけでもないし、利用可能な解決策を作ろうとして取り組んだだけだ。JS コードフォーマットに情熱があるなら、誰かがより速い方法でその問題を解いてもかなりうれしいと思う
    • 「自分たちが既存の強者で、JavaScript 開発者には実用的な代替手段がない」と「Rust 側でやり遂げ、かなり viable な代替手段ができた」との間には大きな違いがある
      局所最適点から抜け出す問題に近く見える。最大の性能ボトルネックを見て改善できると言うことはできるが、客観的により良い比較対象がなければ確信しにくい
      模倣は最も真摯な賛辞であり、難しい問題を別の言語でも解けるという事実そのものが、競争の過程で価値を生み出す
      実際の代替手段がなければ完全な競争もない。Rust 実装がテストスイートの5%以下だけを切り捨ててもなお高速なら、標準実装と比べたとき、この問題の理論的限界について多くのことを教えてくれる
      この領域に深く詳しいわけではないが、別言語の類似実装があれば得られる無形の価値は常にあると思う
    • 異なる観点や意図を持つ人々が実装すれば、新しい改善の方向性が見えてくることがある
      https://biomejs.dev/formatter/#differences-with-prettier
      Biome は Prettier と同じ判断には従わず、分岐した複数の不便な点を見つけ出しており、これだけでも並行開発の価値は十分にある
    • 制約や背負うものが異なるアプローチは、元のプロジェクトでは見えなかった改善領域を見つけられることがある
      いわゆるPrettier 的な考え方に縛られていないからかもしれない

  • 多くの人が理由を述べている一方で、この部分を一緒に見ていないように思える。「すべてのテストを合わせる中で、Biome プロジェクトは Prettier の多くのバグや疑わしい判断を発見し、それを改善できるようになった」
    私には、別実装を通じて自分たちの実装を sanity check できるようになった、という意味に見える

  • このニュースは本当に楽しみだ
    Biome チームが Prettier との95%互換性を達成した速さは驚くほどだった https://github.com/biomejs/biome/issues/720
    Rust のおかげで JavaScript フォーマット速度を大きく引き上げられ、Python フォーマッター ruff の流れに沿うことになる
    記事にはないが、Wasmer も Biome を WASIX にコンパイルすることに $2,500 の懸賞金をかけており、そのチームがそのために作業している様子を見るのもよかった
    近いうちに Biome が Wasmer で動くことを期待している: https://wasmer.io/, https://wasix.org/, https://console.algora.io/challenges/prettier

    • WASIX は初めて見たが、読んでみると JVM の生まれ変わりのように見える
      この理解で合っているのか気になる。システムにアクセスでき、実際のサンドボックスではないなら、WASIX でコードを実行する利点が何なのか分からない
    • WASIX にコンパイル可能にしようとしている理由を知っている人はいるだろうか

  • 速度改善はいつでも歓迎だけど、Prettier がもう少し独断的でなければいいのにと思う
    特に 行の長さ に関して、こちらのフォーマットをそのままにしてくれない。Prettier でフォーマットされたコードは、フォーマットしていないコードよりずっと読みにくく、rustfmt のような他のフォーマッタでは経験しない問題だ

    • Prettier のコードがずっと読みにくい例があるのか気になる
      自分はそういう問題をあまり経験しておらず、Prettier にはかなり満足してきた
    • print width オプションは試したのか気になる: https://prettier.io/docs/en/options.html#print-width
    • Prettier の本当の問題は、ほぼ 事実上の標準 になってしまったことにある
      個人的には Prettier はまったく好きではないが Svelte は好きで、Svelte の公式フォーマッタは私の知る限り Prettier を使っている。だから Svelte では Prettier を使っているし、他のいくつかも同様だ
      ユーザーがツールを選べる状況なら、「非常に独断的で、設定したいなら他へ行け」という原則は素晴らしいかもしれない。しかし特定のユーザー層にとって事実上唯一の選択肢になるなら、もう少し設定可能であるべきだ
    • 行の長さに関して、Prettier にはもっと巧妙な副作用があり、だから独断的なフォーマッタを避けている
      Prettier は意図しない形で diff を変えてしまう
      分割代入でメンバーを1つ削除して行の長さ制限を下回ると、diff が 0/-1 ではなく +1/-5 になることがある。レビュー担当者は、5行削除と1行追加の間で何が正確に抜けたのかをすぐには見分けにくい
      Git のインタラクティブ rebase で以前のコミットのタイポを直そうとすると、Prettier がコードブロック全体を再フォーマットして、後続のコミットが適用されないこともある
      pre-commit フックで Prettier を走らせたうえで、ファイルの変更の一部だけを stage してみると、また面白い問題が起きる。自分は遠慮しておく
    • 同意する。さらに言えば、Prettier がそもそも存在しなかったほうが よかったとまで言いたい

  • いまだに複数の eslint プラグインがまともなリンターを廃止して Prettier に置き換えたことにいら立つ
    Prettier はあまりにも 強制的 で推論しにくく、自分が望んだこともない余計なツールだ

    • 廃止されたスタイル規則は新しいプロジェクトへ移植された: https://eslint.style/guide/why
    • そういうツールの目的はまさに スタイル論争 を終わらせることにある
    • どういう場合に Prettier を「推論」する必要があるのかよく分からない
      たまにマージコンフリクトの問題が起きる程度しか思いつかない

  • Rust に移植する流れはあるが、Prettier は保存のたびに実行されるので 速度向上 はかなり大きいはずだ
    近いうちに Biome を試す予定で、Biome プロジェクトにお祝いを言いたい

    • 単一ファイルで Prettier が実行されるときに遅延を感じたことはない
      性能が重要になるのはリポジトリ全体にフォーマットをかけるときだ
      インタラクティブな利用では、長く常駐してウォームアップ済みのプロセスを使うべきで、そうすれば Node の起動時間は重要ではない。理想的には、型チェック、リンティング、ハイライト、フォーマットが1つの言語サービス内で、キー入力ごとにインクリメンタル解析を行い、共有 AST を更新するべきだ
    • この取り組みは Python コミュニティにおける ruff の熱気を思い起こさせる
      広範に影響する 効率と速度の改善 が期待できる
    • Prettier が保存のたびに全体ではなく変更されたファイルだけに実行されるよう、lint-staged ツールを使うことをおすすめする
      大きなプロジェクトでは差が非常に大きい

  • 「これで次の重要な側面、性能に集中できる。Prettier は本質的に速かったことはないが、ほとんどの用途には十分速かった。この点にはずっと満足しておらず、だから何かしたかった。友好的な競争より良い方法があるだろうか。11月9日、Prettier テストスイートの95%を通過する Rust プロジェクトに $10k の懸賞金 をかけた」
    何かが Rust で書かれているという事実から、どうしてより良い性能が導かれるのか分からない。既存のコードベースを Rust に単純にトランスパイルして報酬を受け取ることもできたはずだ

    • 「単純に」という言葉を見ると、その後に来る作業は単純ではないのだろうと思ってしまう
      本当に単純なら、わざわざそう形容する必要がないからだ
      この場合、JavaScript のコードベースを Rust にトランスパイルするのが単純なのかは分からない。両言語は思考モデル、使うライブラリ、コードの書き方がかなり異なり、JS-to-Rust トランスパイラが存在するとしても、Prettier 規模のコードベースに使えるほど堅牢なのか疑わしい
    • 慣用的な Rust は、似たように見える JavaScript/TypeScript コードより、特別な最適化なしでも 5〜10倍速い ことが多い
      作業内容によって異なり、常にそうとは限らないが、文字列操作を多用するパーサー系には確実に当てはまる例だ
    • 文字列処理では Rust は JS よりはるかに速い
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fasta.html
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/knucleotide.html
    • vjeux から受け取った答えはこうだった: 「最近は Rust で書かれた高速な Web ツールが多い」
      https://twitter.com/Vjeux/status/1722769322299609565
      自分は納得できず、vjeux が Rust ブーム に乗ったように見える

  • 優勝プロジェクトの Biome は、数年前に Babel 作者の Sebastian McKenzie が始めた Rome プロジェクトのフォーク、または改名版だ
    sebmck はこの1年ほど不在だったようで、多くのプロジェクトリソースへのアクセス権が彼だけにあり、コントリビューターが更新できなかったためフォークされた
    彼が無事であることを願うし、それとは別に Biome プロジェクトが順調に進んでいるようで何よりだ

  • なぜどうしても Rust である必要があったのか分からない
    単に「より速いもの」ではダメだったのか？Rust 実装は実際に速いのか？Prettier のようなプログラムにメモリ安全性やリークのようなものが本当に重要なのかも疑問

    • 特に HN には、Rust が現在最も速く安全な言語だと考える声の大きい人が多い
      なので、ある程度は「そう言うなら自分で証明してみろ」という懸賞チャレンジだったのかもしれない

  • Biome のベンチマークがどこかにあるのか気になる
    Prettier より正確にどれくらい性能が良いのか？