🧬

フロントエンド開発環境のエコシステムを線で捉える

に公開
JavaScript
Node.js
TypeScript
Web
frontend
idea

JavaScript 生誕 30 周年を記念して

今日は 2025 年 12 月 4 日ということで、 1995 年 12 月 4 日、今から 30 年前のこの日に、 JavaScript が発表されたらしい（Wikipedia に 当時のプレスリリースのアーカイブが残っていた）。自分自身が JavaScript より 1 年 後輩の 29 歳なので、このときの JavaScript の評価がどうだったかは分からないが、歳月を経て TypeScript に派生し、 JavaScript と TypeScript は 2025 年現在で世界で最も使われるプログラミング言語となっている（Octoverse 2025 で発表された言語ごとのコントリビュータ数ランキングでは TypeScript が 1位、JavaScript が 3位）。

今や Web の標準言語としての地位を確立し、サーバサイドやモバイル／デスクトップアプリ、今だと AI エージェントまで作れる万能性が認められ、推しも押されもせぬ人気を博している。そんな JavaScript の万能性を裏付けているのはやはり強固なエコシステムの数々だ。特に、Web フロントエンドはツールの新陳代謝が激しく、開発者がゆっくりとキャッチアップする暇もないほど日々新しいツール、新しいバージョンが登場している。


現代のフロントエンドのエコシステムマップ（出展）

今日は JavaScript の 30 周年を記念して、ゆっくりと Web フロントエンド開発環境のエコシステムの「流れ」を辿ってみたい。

はじめに

先週末に開催されていたフロントエンドカンファレンス関西 2025 というイベントに運営スタッフとして参加し、スタッフ業務の傍ら後ろの方でこっそり基調講演を聞いていた。「なぜフロントエンド技術を追うのか？なぜカンファレンスに参加するのか？」というタイトルの基調講演の内容がめちゃくちゃ良かった。オンライン配信のないイベントだったので、会場にお越しいただけなかった方はぜひ下記の資料をご覧ください。

https://speakerdeck.com/sakito/nazehurontoendoji-shu-wozhui-unoka-nazekanhuarensunican-jia-surunoka

登壇者であるサイボウズの @__sakito__ さんは「ビルドツールに興味を持ち、そこからフロントエンドにのめり込んでいった」と仰っていてビルドツールの変遷について語り始めていたとき、「あー自分も同じ感じだったな」と自分のエンジニア人生をこっそりと振り返っていた。

基調講演を聞きながら、私がまだ学生の頃に Web エンジニアのインターンとして初めて Web フロントエンドに触れた 2017 年頃を勝手に思い出していた。当時は jQuery 最強！みたいな時代から、ようやく「 React ってやつがいいらしい」みたいな話をしていた時期で、もちろんまだまだ素の JavaScript を書いていたので、何度も Uncaught TypeError: Cannot read property 'xxx' of undefined みたいな実行時エラーを引きまくって、画面を真っ白にしていた記憶がある。

React を触り始めた頃も、create-react-app しておけばいいんでしょ、簡単じゃんと高を括っていたら、npm run eject した瞬間に webpack だ Babel だ ESLint といろんなツールが出てきてなんて面倒だと思ったが、一つずつツールを理解して導入していくうちにそれらのありがたみに気づいていったことを覚えている。

コードレビューで喧嘩しないように ESLint を入れたらいいとか、Prettier を入れたら保存するときに自動で整形してくれるんだとか、Sketch のデザインファイルと UI の差分がでないように Storybook を入れたらいいのかなとか、型がなくてバグだらけだから FlowType を入れたらいいのかなとか、やっぱり Flow だとライブラリの型定義がなくてしんどいから TypeScript を少しずつ入れようかなとか、アプリ全体で管理したい情報が出てきたから Redux を入れたらいいのかなとか、非同期処理が複雑だから Redux-Saga を入れたけどチームメンバーが誰一人理解できないだとか。

登壇を聞きながらそういうツール一つひとつを使い始めた頃を思い出して、その当時プロダクトに関わっていたチームの人たちやどんなコミュニケーションをしてたかまで思い出してしまった。

登壇の中で、技術を学ぶときに「流れ」を楽しむべき、技術を「点」でなく「線」で捉えるべきと仰っていたが、自分もただ単に技術の使い方を学ぶよりも、背景や成り立ちまで理解できていた方が楽しいと感じられるタイプなので、歴史から最新状況までを知っておきたいと思った。

この記事は、フロントエンドが好きな若手懐古エンジニアが、先人の足跡を辿りながら、さらなる後進の開発者の理解の助けとなることを目指して執筆した記事です。歴史や最新の状況についてはなるべく詳細に調べているがここの使い方などについてはまったく言及していないのでご注意ください。クリスマスのお供に「そんな時代もあったね」と温かい目で見ていただけると幸いです。また、内容に誤りがあればいつでもご指摘いただけますと幸いです。

フロントエンド開発環境のエコシステム

今回は、フロントエンドの開発時によく使われている技術を

  1. Runtime
  2. Package manager
  3. Build tool (Bundler & Transpiler)
  4. Linter & Formatter

の 4 つのカテゴリに分けて紹介していきたい。

Runtime

Runtime は、日本語では「実行環境」などと訳されているのを見ることが多い。とりわけフロントエンド開発環境においての Runtime は、後述する Package manager や Build tool 、Linter 、Formatter などのツール群をブラウザの外（開発者のローカル環境や CI 環境）で実行させるための土台のような役割と理解している。Runtime は、JavaScript の解釈と実行を担う JavaScript Engine （V8, JavaScriptCore など）と、モジュールシステムや API を提供する Runtime API によって構成されていて、単に JavaScript を解釈・実行できる環境だけでなく、ネットワークリクエストやファイルの読み書きなども機能として有している。

State of JavaScript 2024 によると、ブラウザ以外の Runtimeは依然として Node.js が圧倒的なシェアを誇っており、Bun, Deno がそれに続いている。この記事に、 State of JavaScript 2022 の結果が載っていたのだが、2022 年時点では Bun よりも Deno の方がシェアを獲得していたが、ここ 2 年ほどで Bun のシェアが拡大していることが分かる。

Node.js

そもそも Node.js の 0.1 バージョンがリリースされたのは 2009 年のことで、それまではブラウザ内で JavaScript を実行することが当たり前だった。自分が高専に入学して情報工学を学び始めた 2012 年くらいに JavaScript を少しかじっていたが、当時は <script> タグで読み込んだ JavaScript をブラウザで直接実行していた。

当時はビルドの概念もないし、もちろんホットリロードもないし、 JavaScript はクライアントサイドで動く言語という見方が一般的だったように思う。

Node.js （や、その後の npm）の誕生によって、フロントエンド開発環境は革新的に変化していくのだけれど、もともと Node.js は、 Chrome に積まれた V8 Engine が異常なパフォーマンスだったために Ryan Dahl が JavaScript をサーバサイドで動かせるようにするために作られたという経緯がある。

Node.js のドキュメンタリー動画で "My goal with Node.js was to force developers to easily build optimal servers by only exposing async I/O" と Ryan Dahl 自身が述べていましたが、当時 C10K 問題と呼ばれる、クライアント数がある一定増加するとサーバのスレッド数が増えてパンクしてしまうという問題に対処するために、シングルスレッドの JavaScript を非同期 I/O で実行するために作られたらしい。このあたりについては下記の記事がわかりやすいのでご参照ください。

https://techblog.recruit.co.jp/article-1115/

めちゃくちゃ余談ではあるが、現在の nodejs/node リポジトリに移行する前の nodejs/node-v0-archive リポジトリに最初期の Node.js のコードが残されており、このコミットログ - Commit 19478ed (Major refactoring: program name now "node") が、 "node" という名前をつけた記念すべきコミットらしい、ということを調べている中で知り、ちょっとだけ感動した。

Deno

Node.js のエコシステムが成熟してきた 2018 年に、Ryan Dahl 自身による 10 Things I Regret About Node.js という JSConf EU 2018 の発表で Node.js に変わる新たな Runtime である Deno が発表された。

https://www.youtube.com/watch?v=M3BM9TB-8yA

「10 の後悔」というタイトルの割に発表の中では 7 つくらいしか失敗として挙げられていなかったのはさておき、 Deno は Node.js におけるそれらの反省点を克服するための Runtime として設計されていた。例えば TypeScript をネイティブでサポート[1]してたり、デフォルトでファイルシステムやネットワークへのアクセスが制限されるなどセキュリティが強固だったり、Linter や Formatter などのツールチェーンがデフォルトで組み込まれていたりと、 Node.js のように色んなツールを選定しなくてもそのままの状態である程度はサポートされている。

発表からもう7年くらい既に経っている訳ではあるが、 Deno をフロントエンドの開発環境に実践投入したという事例はほとんど見かけないよなと思って調べてみたら ほぼ唯一くらいの（？）採用事例を見つけた。

https://speakerdeck.com/lycorptech_jp/why-we-chose-deno-for-production

Node.js の環境設定（tsconfig.json の設定、 ts-node や tsx を追加する必要がある、リンターの設定など）が面倒だということがやはり課題として挙げられており、Deno は開発環境のツールチェーンがデフォルトで整備されていることが採用理由だと語られていた。

一方で、lock ファイルの運用を巡って Deno 社とミーティングを重ねて仕様のフィードバックをしているなどしている言及があり、結構馬力や体力のあるチームではないと採用するのは厳しいなと感じた。現時点では、 Deno には魅力的な部分はいくつかあれど、過去の Node.js の資産だったりチームメンバーの学習コストだったりを考えると、乗り換えるメリットはそこまで大きくないと感じているチームが多いよう。

Bun

最近 Anthropic に買収されたことでも話題の Bun は、圧倒的な速度を引っ提げて 2023 年の 9 月に v1.0 がリリースされた。

https://youtu.be/BsnCpESUEqM?si=091LGf4HjFCE15_L

Bun の開発が始まったのは、 Bun の作者である Jarred Sumner が、2021 年頃に Next.js で Minecraft っぽいゲームを作っていたときに、Next.js の dev server のホットリロードを待つのがしんどすぎて開発を始めたと、ブログに書かれている。esbuild の JSX & TypeScript transpiler を Go から Zig に移植し、WebKit のソースコードを読みながら Safari の JavaScript Engine に使われている JavaScriptCore を 1 ヶ月で埋め込むことに成功し、最初期の runtime が 2022 年 7 月頃にリリースされた。

Bun は Deno と同様に all-in-one なランタイムを目指しており、Package manager や Bundler 、Test runner はもちろんのこと、PostgreSQL のクライアントや Amazon S3 のクライアント機能など API は結構やりたい放題好き勝手に機能拡張している印象。

今年から、Prettier のメインメンテナとして知られる sosukesuzukiさんも入社したことでも話題になった（所属は Anthropic になるのだろうか）。

https://sosukesuzuki.dev/posts/joining-bun/

また、Bun は Node.js のリプレースをマイルストーンとして開発されており、多くの Node.js API と Web API が標準でサポートされており、Deno よりも Node.js から移行しやすいと思う。まだまだサポートが足りていない場面もあって、自分が普段扱っているプロダクトだと、 Electron のサポートはまだされていないのとモノレポのサポートがイマイチだったので、Bun の採用は見送った（が、使ってみたかった）。

Web 検索してもあまりヒットしないので、まだまだ Bun は大規模なサービスで使われている事例はないのかも（※ 以下はバックエンド環境での採用事例）。

https://www.ai-shift.co.jp/techblog/4234

Package manager

Package manager は、その名の通り package を管理するツールのことだ。「package」は様々な定義があると思うが、プログラムを別のプロジェクトでも利用できるように配布可能な状態にしたもの、と私個人としては理解している。

npm

Node.js に Package manager がない頃の時代の話が Node.js のドキュメンタリー動画 の 08:20 あたりから語られているが、とあるパッケージを使うためにGitHub から Zip ファイルをダウンロードして、プロジェクト内の特定のフォルダに配置し、 make コマンドを実行して、さらにファイルをコピーし ――― といったように煩雑で手間の多い作業が課せられていたことが語られていた。

https://youtu.be/LB8KwiiUGy0?si=wW9EhSccvw9QoCB6&t=500

そんな中で Node.js 初の Package manager である npm がリリースされたのは 2010 年で、 Isaac Z. Schlueter により開発された。npm の初期設計には、Yahoo が開発のために内部で使用していた yinst が参考にされ、当初は Node から使用できるシンプルな bash スクリプトに過ぎなかったが、 package.json によって定義された package を、公開されたレジストリに登録でき、 CLI ツールで別の開発者がインストールできるという基本的な構成は 15年以上たった 2025 年の現在でもまだ健在である。npm のレジストリには現在 210 万以上のパッケージが登録されていて、日々増加している。

npm の話題だと、今年 9月と 11月に発生した Shai-Hulud と呼ばれるワームによるサプライチェーン攻撃は記憶に新しいが、このあたりの問題にプラットフォーマーとしてどのように対処していく方針なのかはとても気になるところ。

Yarn

Yarn は Facebook（現在の Meta） により、2016年頃から開発されている Package manager で、私自身も「どうやら npm より速いらしい！」というだけで一昔前までは Yarn （v1）を好んで使っていた。あとは私個人的には、キーボードで p の文字を打つのが苦手なので、若干 npm よりも yarn の方が若干打ちやすいし、npm install --save-dev よりも yarn add --dev の方が打ちやすいというのもあった。

pnpm

pnpm (Performant npm) は、その名の通り効率的な npm を目指して、主にウクライナの Zoltan Kochan 氏によって作成されている Package manager である。日本においては最近、採用数が伸びているように感じていた pnpm だが、GitHub の Release を最初から見てみると、v0.1.0 が 2016年の8月21日に公開されており、Yarn が出始めてきたくらいの頃から開発がスタートしている。メジャーバージョンの v1.0.0 が公開されているのが 2017年6月28日であり、リリースの文章やブログを見るとシンボリックリンクで package を効率的に管理するアイデアはこの頃からあったが、node_modules の構造を既存の npm パッケージで動作させるのがめちゃくちゃ大変だったと言っている。

https://medium.com/pnpm/pnpm-version-1-is-out-935a07af914

めちゃくちゃ余談だが p をキーボード打つのが苦手な私にとって pnpm はあまりにも打ちづらいので、 alias p="pnpm" で一文字で実行できるようにしている。

Bun

Node.js の代替を目指す Bun は built-in の Package manager を機能として有しており、 npm とほぼ同じ使い心地で使える。ただし bun install は爆速すぎて npm に慣れている人だと不安になるレベルと思う（私は不安になる）。最近リリースされた Bun 1.3 で yarn.lock や pnpm-lock.yaml から bun.lockb へマイグレーションする機能がサポートされたので、 yarn や pnpm を使っている人はお試しで使ってみてもいいのかもなと。

https://bun.com/blog/bun-v1.3#pnpm-lock-yarn-lock-migration-support

Build tool (Bundler & Transpiler)

Bundler や Transpiler や Build tool の説明に入る前に、まずは用語の整理をしておきたい。これらの用語は個人的にかなり説明が難しいと感じる。なぜなら、１つのツールでも複数の役割を兼ね備えていたり、他のツールを内包していたりと複雑な事情があり明確な線引きがどうしても難しくなってしまうためだ。

例えば、Rsbuild というツールのドキュメント内では、下記の図のように Bundler と Build tool の関係性を表現している。ここで Build tool と分類されている Rsbuild も Vite も create-react-app も Vue CLI も、機能としては CLI を持ち、 Dev Server を起動して HMR (Hot Module Replacement) で開発でき、内包した Bundler (Rspack, Rollup, webpack) を使って production 向けにビルドができるという点で共通している。


Rsbuild で説明されている Bundler と Build Tools の区別（出展）

純粋な Bundler は、複数の module を bundle する（ = 束ねる）ためのツールである。Bundler の説明は wozhuiebpack 公式のトップページにある図がかなりわかりやすいが、いろんな依存関係にあるファイルをまとめて一つ（あるいは少数）のファイルに束ねるという役割を主に担っている[2]。


Bundler の動作（出展）

それから、Transpiler（または Compiler や Transformer と呼ばれることもある）は、あるプログラミング言語から、別のプログラミング言語へと変換する（transpile する）ためのツールで、とりわけフロントエンド開発においては、TypeScript から JavaScript へ変換したり、新しい規格の JavaScript から古い規格の JavaScript へと変換をしたりする。

なぜこんな面倒なことをしているかというと、開発環境（開発者のローカル PC）と実行環境（ブラウザ）で JavaScript を動かす環境（JavaScript Engine）が異なるためで、Transpier があるお陰で開発者は新しい規格の言語機能を使ったとしても、いろんなバージョンのブラウザでプログラムを動作させることができる。

Transpiler は基本的に、前述した build tool や bundler と組み合わせて使う。webpack の場合は Loader という名前で、Rollup の場合は Plugin という名前で、ファイル群が bundle される前に様々なファイルタイプに対して変換をかけることができる。

ここまでをまとめると、下記の図のようになると思う。すべてのツールに当てはまるとは限らないが概ねこのような枠組みで動作していると思う（実際には minify や tree shaking や code splitting などもっと複雑なことをやってるが割愛）。

  • build tool: CLI 等でコマンドを受付け、bundler や transpiler を利用して、ブラウザで実行可能な JavaScript ファイルを生成する
  • bundler: 依存関係にある複数のファイル群をまとめて一つのファイルに結合する
  • transpiler: ブラウザで実行可能な JavaScript ファイルに変換する

ただし、 webpack は公式でも "bundler" を名乗っているものの、進化の過程で dev server で起動したり transpiler を内部で利用できたりするので、 build tool とも見なせるし、 esbuild というツールは bundler と transpiler の両方の機能を有していたりといろいろあるので、そこまで厳密な定義にはこだわらなくてよいと思われる。

webpack

webpack は 2012 年に v1 がリリースされて、現在までも一番使われている build tool。State of JavaScript 2024 の、「仕事でどのビルドツールを使っていますか？（複数回答可）」という質問に対しては webpack が未だに首位をキープと、根強い存在感を示しているが、後発の Vite とほぼ同票なので、おそらく今年あたりに Vite には抜かれてそうな予感。


仕事でどの build tool を使うか - State of JavaScript 2024（出展）

2025 年 12 月現在の最新は v5.103.0 となってメンテナンスは継続的に続いてはいるが、 v5 が発表されたのは 2020 年 10 月のことなので、5 年以上もメジャーバージョンを上げていない。v5 のリリース時に「破壊的変更はユーザにとってよろしくない」と述べていた通りインフラとしての矜持もあるだろうが、v6 のロードマップは特に計画がなさそうだし、メイン開発者の Tobias Koppers 氏のブログによると "webpack was built 10 years ago—with the needs of 10 years ago in mind" と言って webpack の開発をやめて Vercel で Turbopack というさらに別の bundler の開発に向いている。

一応、webpack 以前にも言及しておくと 2011 年に v1 がリリースされた Browserify があるが、自分はほぼ触ったことない。README は "require('modules') in the browser" と言及されているように、 var module = require('module') のような CommonJS 形式のファイルを読み込み、require を辿って依存関係を解析する bundler である。Browserify は当時 Node.js 上でしか動かせなかった CommonJS をブラウザ上で動かせるようにする画期的なツールだったそうだが、良くも悪くも JavaSciprt に特化していて他の CSS や画像などのアセットを扱おうとすると Grunt や Gulp といった別のツールを組み合わせなければいけないという煩雑さがあったために webpack が Browserify に代わってシェアを拡大していったという経緯があるそうだ。

逆に、webpack はあまりにたくさんのことが出来るあまりに、設定が複雑化しやすく、チーム内で webpack 職人が必要になりがちという欠点がある。また、開発サーバやビルド時のスピードについても、サービスが大規模化すると顕著に問題が現れる。

一時代を築いた webpack だけれども、そこからたくさんのツールが生み出されて今日に至る。技術の「流れ」という目線で見ると、

  1. webpack の設定が複雑すぎるので設定の単純な Rollup やゼロコンフィグの Parcel
  2. dev server の起動や HMR が遅すぎるので、ブラウザの Native ESM 利用して高速化した Snowpack や Vite
  3. 本番向けのビルドも遅いから Go や Rust で構築しなおした esbuild や Turbopack 、Rspack 、Rolldown

みたいな bundler のタイプみたいなものが見えてきた。すべてを紹介する時間がないのでいくつかを簡単に紹介する。


bundler の派生

Vite

長きに渡る webpack の牙城を崩しにかかっているのが Vite で、Vue.js の作者である Evan You 氏らによって開発され、2020 年頃にリリースされた。webpack と全く違うのは開発サーバの体験で、開発サーバを起動するときの速度も、ファイルを更新したときの HMR の速度も高速化することで webpack の負債を解消していた。

Bundle based (webpack) Native ESM based (Vite)

起動速度については、まず esbuild で高速に node_modules 配下の依存関係を事前に bundle しておき、node_modules に含まれない自身のソースコードについては、ブラウザからリクエストがあったときに始めて必要部分のみを処理するという構成を取っている。

また更新時の速度についても、HMR をブラウザの Native ESM 上で実行するために変更したモジュール外に影響を及ぼさないようになっているため高速化を実現できている。

同時期に開発されていた Snowpack も同じアイデアにたどり着いており、そのあたりも含め Vite が誕生した歴史や背景は Vite: The Documentary というめちゃくちゃカッコイイ動画にまとめられているので、一度はぜひご覧いただきたい。

Vite は長年、開発時には esbuild を使っており、本番時には Rollup でビルドするという構成だったのが、ちょうど昨日 Vite 8 Beta リリースのアナウンスで Rolldown を搭載した Vite がベータ版で利用可能になったことが発表された。

https://vite.dev/blog/announcing-vite8-beta

Vite の進化は目覚ましく、Evan You は VoidZero という会社を立ち上げて、殺伐としたフロントエンド開発環境のエコシステムの統一、包括的なツールチェーンの開発を目指している。今後、どういう方向性になっていくのかはしっかりチェックしておきたい。

Turbopack

Turbopack は webpack で長年開発を務めていた Tobias Koppers 氏が転職先の Verel で開発している Rust 製の高速 bundler。Next.js v16 では長年使われてきた webpack に代わって Turbopack がデフォルトの bundler になった。

https://nextjs.org/blog/next-16

現状、Turbopack は Vercel らしく Next.js でだけ唯一利用でき、他のライブラリやメタフレームワークからは利用できないという認識（間違ってたらすみません）なので、他の bundler とは少し毛色が違う感じがあって自分は少し敬遠しがち。ただ、新規プロジェクトで Next.js v16 以降で使いたい場合は否が応でも使わなければいけない（next dev --webpack で回避は可能だし、next-rspackを使うという手も残されてはいそう）ので、たくさんフィードバックが送られてコミュニティが今より発展することを願うばかり。

Rspack

Rspack は 2024年 8 月に v1.0.0 がリリースされた比較的新しい bundler で、こちらも Rust 製。TikTok の ByteDance 社にある Web Infra チームが中心に開発を推進している。

webpack 互換を謳っているため、これまで webpack を使っていた大企業も移行先としてよく選んでいるということが State of JavaScript 2024 で、アンケート結果から言及されていた。

実際、周りの日本企業でも今年に入って webpack → Rspack の移行はいくつか事例が増えてきていそう。大規模アプリケーションで webpack を使用していてパフォーマンスが気になるという方は移行のチャンスかもしれない。

Linter & Formatter

Linter とは、問題のありそうなコードパターンやガイドラインに沿っていないコードを静的解析により検出するツールで、「マジックナンバーは他の開発者が意味を把握できないから良くないよ」とか「条件文の中で代入したらバグを引く可能性が高いよ」とか、開発者にうっかりやってしまいそうなミスを他のレビュワーに代わって教えてくれる。

一方で Formatter は、コードを整形（format）してくれるツールで、「' を使うか " を使うか」「文の最後には ; をつけるかつけないか」「JSON が複数行になったときの最後の要素に , をつけるかつけないか」みたいな不毛な議論を回避してくれる。Linter 界隈では ESLint が、 Formatter 界隈では Prettier がそれぞれ長らくデファクトスタンダードとして使用されてきていて、現在もその地位は揺るぎない。

Linter と Formatter がセットで語られやすいのは、それぞれを単一で使うことはほとんどなく、ほぼ例外なく一緒に使われるためで、Linter がコードの品質を担保し、Formatter がコードの見た目みたいな役割分担をしているがコードの品質を高める上ではどちらも必要になる。

ESLint

ESLint の v1 がリリースされたのは 2015 年 7 月のことだったそうで、私が開発者をし始めた頃にはもう既に多くのプロジェクトで使われており、今でも JS/TS Linter のデファクトスタンダードになっている。もうすぐ v10 をリリースする予定だが、ほとんど機能的な変更はなく、成熟期に入りつつある。

https://eslint.org/blog/2025/10/whats-coming-in-eslint-10.0.0/

Oxc の oxlint や Rstack の rslint [3] がいずれも Rust 製の ESLint 互換爆速 Linter を目指して開発が進められている。いずれもサポートがまだ限定的なのですぐに置換するのは難しいかもしれないが ESLint に速度で不満がある方はウォッチしておくと良さそう。

Prettier

Prettier は、2017 年に v1 がリリースされ、2025 年現在では v4 がリリースされている。Prettier の歴史を知る上では欠かせない、長らく Prettier の開発を支えていた @vjeux 氏の Birth of Prettier という記事が生々しくてとても面白かった。

https://blog.vjeux.com/2025/javascript/birth-of-prettier.html

Formatter はリリース当初から 80% の完成度ではなく 99.999% の完成度を求められるから誰もやり遂げられなかったが、たまたまリリース前に Jest がスナップショットテストをサポートしてテストが効率的になったことが後押しとなってリリースできるようになった話とか、Ocaml の方言の Reason と JavaScript の別々の言語で書かれた2つのコードベースのうちどちらを採用するか決めるためにリーダーボードを作って毎日更新していた話など、Prettier というツールがどのように作り上げられていったのかを詳細に知ることができる。

Prettier は後述する Biome と比較するとパフォーマンスがどうしても劣るが、現在開発段階で次のバージョンの v4 ではファイル検索アルゴリズムの高速化やキャッシュを刷新することでCLI の高速化が計画されているらしいので、ウォッチしておきたい（ただし、それでも Biome の性能には及ばないことも言及されている）。

Biome

最近、話題になっていて実践環境でも徐々に投入されて始めているのは Biome だと思う。Biome は Rome の後継としても知られる。 ESLint/Prettier が長らく覇権を握っていたが、2020 年頃に Rome という JS 界のツールチェーン（bundler, linter, formatter, test runner など）を大統一するプロジェクトが始まり、 Rome Tools, Inc. という会社を設立するなど話題となったが、2023 年 1 月に調達した資金が尽きてしまい、コアメンバーに給料が支払われなくなってしまったことでプロジェクトが停止。その後、Announcing Biome というブログの中で、 Rome のプロジェクトをフォークして Biome の開発がスタートされたことが知らされた。

https://biomejs.dev/blog/announcing-biome/

Rome の資金ショートに関するニュースはとても残念ではあったが、前述した Birth of Prettier にも資金調達の難しさについて言及していた。広告もなかなかつかないし、ツール導入支援などのコンサル業も Prettier のツールが導入が簡単すぎるから必要ないし、グッズも手間の割には売れないし、など開発者のためのツールに明確な付加価値を提案することが難しかったと綴られていた。

"Biome" は、 "Bis" (ラテン語で「2つの」「2度目の」。bi-cycle や bi-lingual とかの bi- と語源は同じらしい) と "Rome" という語を組み合わせて考案されたようで、Rome の意思を継いでいこうという気概を感じる。Biome 自体は Linter と Formatter の両方の機能を持っており、 Rust で構築されているためにスピードも爆速。

おわりに

たくさんのツールの歴史を学ぶのは、情報源を見つけるのが本当に骨が折れる作業だった。「なんでこのツール・機能が作られたんだ？」とかリリースが出るたびに考えるだけでも、より一歩深く技術の流れを知ることに繋がるなと感じたので、今後はたくさん意識していきたい。

今回の記事執筆にあたり、参考にした資料を以下に上げておきます。先人たちのお陰でめちゃくちゃ勉強になった。来年はぜひ一歩勇気を出して、挙げたツールへコントリビューションしたい。

脚注

  1. Node.js も今年 v23.6.0 で Type Stripping という機能が導入され v25.2.0 で安定版になったことにより 現在では TypeScript をネイティブ実行できるようにはなっています。 ↩︎

  2. webpack は自身の Web サイトでも bundler と呼んでいるが、進化の過程で webpack-dev-server の機能を獲得したため、実質的には build tool と呼んでも差し支えないと思う。 ↩︎

  3. Rstack の rslint と同じ名前で RSLint（rslint.org）というツールがあるが、 こちらは既にメンテされていないので注意 ↩︎

Discussion