Bun を導入できない3つの理由

こんにちは。寒暖差でずっと喉が痛い @ishiyu です。

今回は、弊社で Bun を導入しようとして断念した理由について、書いてみようと思います。

Bun を導入しようとしたきっかけは、個人開発しているプロジェクトで Bun を導入しており、ローカルで Node.js と比較してみたら 1分以上 typescript のトランスパイルが早かったので、開発生産性やデプロイ速度の向上を目的に導入しようとなりました。

が、JavaScript Runtime の変更には色々な壁があることが分かり、今は難しいという結論に至りました。

その理由について、簡単にまとめました。

環境

今回試したフロントエンドの環境です。

現在、利用しているフロントエンドの環境

  • Node.js: v18.20.3
  • パッケージマネージャ: yarn v1.22.19
  • Vite: 5.1.5
  • TypeScript: 5.3.3
  • Vue: 3.4.21
  • vitest: 1.3.1

試した bun のバージョン

Bun v1.1.10

断念した理由

その1. Package Manager としてまだちょっと不安定

こちらは理由が解明できていないのですが、 bun install で node_modules をダウンロードする際に、たまに途中で動かなくなります。

2回目には、たいてい成功するので再実行すれば良いだけなのですが、git push 時や PR マージ時に自動で CI/CD が動くようになっているため、手動で rerun するのはストレスだなと思っています。

その2. patch-package が使えない

弊社では、おおよそ1ヶ月に1回ライブラリを最新に更新するようにしているのですが、 yarn upgrade-interactive --latest のようなライブラリ更新に便利なコマンドが bun には存在しません。

これは、ライブラリ更新頻度が多い会社ほどツライ気がします。

Issue はあるので、取り込まれることを願っています。

github.com

その3. bun でうまく使えない Node based コマンドがまだ多い

これが断念した一番の理由です。 まだ bun でうまく使えない Node based コマンドが結構あります。

今回、確認したコマンドとしては、以下が使えませんでした。

vue-tsc

github.com

vitest

github.com

histoire

github.com

まとめ

はやく、これらが対応されて、いろいろな JavaScript Runtime の選択ができる未来になってほしいですね。