- Bun 1.0 は、JavaScriptとTypeScriptの実行、ビルド、テスト、デバッグを1つのツールで処理し、安定化されて本番利用可能な状態
- Node.jsの代替を目指し、
fs、path、net、__dirname、process、node_modules解決などのNode APIとモジュール解決をサポートし、Express、Koa、Hono、および Next.js、Remix、Nuxt、Astro、SvelteKit、Nest、SolidStart、Vite ベースのアプリケーションがBunで動作する - Windows向けネイティブビルドは今回が初提供だが、高度に実験的であり、現在はJavaScriptランタイムのみをサポートし、パッケージマネージャー・テストランナー・バンドラーは無効化されている
- Bun 0.8以降の変更として、Next.js、Astro、Nest.js のサポートが追加され、サポート終了となっていた
bun devコマンドは削除され、現在はpackage.jsonの"dev"スクリプトを実行する - 新たにサポートされたNode.js APIとして、
child_process.fork()と IPC、fs.cp()、fs.cpSync()、fs.watchFile()、fs.unwatchFile()、node:httpの Unix socket が追加された - ランタイムにJavaScriptトランスパイラが組み込まれており、
.js、.ts、.cjs、.mjs、.jsx、.tsxファイルを追加の依存関係なしで実行できる - ESMとCommonJSを同時にサポートし、ファイル拡張子や
package.jsonの"type": "module"設定がなくても、同じファイル内でimportとrequire()を使用できる fetch、Request、Response、WebSocket、ReadableStreamのような Web標準API が組み込まれており、node-fetchやwsのようなパッケージなしで利用できる--hotオプションでホットリロードを利用でき、Bun.serve()もホットリロードの対象になる- Bun APIとして
Bun.file()、Bun.write()、Bun.serve()、bun:sqlite、Bun.passwordが提供され、ファイル入出力、HTTP/WebSocketサーバー、SQLite、bcrypt・argon2 のパスワードハッシュ化と検証を処理する - パッケージマネージャーは
bun install、bun add、bun remove、bun updateを提供し、package.jsonを読み取ってnode_modulesに書き込む npm互換方式となっている - テストランナー
bun:testは Jest互換APIを提供し、@jest/globalsとvitestの import を内部的にbun:testへ再マッピングする - バンドラーはJavaScriptとTypeScriptのバンドルおよびminifyをサポートし、esbuild互換のプラグインAPIと、バンドル時にJavaScript関数を実行して値をインライン化する JavaScript macros を提供する
1件のコメント
Hacker Newsの意見
Bunの開発に参加しています。質問があれば答えられます
モデレーターがリンクをブログ記事に変えてくれるとありがたいです。GitHubのリリースページより説明がわかりやすいからです
ブログ記事: https://bun.sh/blog/bun-v1.0
同じファイル内で
importとrequire()を使え、.js/.cjs/.mjsや"type": "module"を気にしなくてよい点が一番印象的ですこれがなければNode.jsエコシステムはほぼ完全に壊れた状態に近く、Bunがそれを救うかもしれないように見えます。Bunで最も素晴らしいのは性能よりも、Jarredが一貫して行ってきた実用的で開発者に優しい選択だと思います
単に別のトレードオフを選んだだけで、その結果、また別のパッケージ群が動かなくなる可能性が高いです。他のツールが解けなかった秘密をBunが解いたと考える根拠があるのか気になります
私の基準では、これが正しいやり方です。Nodeの分断されたエコシステムは、言語とランタイム全体に大きな損害を与えました
import対requireのせいで何時間も苦労しましたReactアプリや既成の解決策を使わないなら、現代のJSエコシステムは本当に苦痛で、小さなライブラリを作る立場では特にそうです。始めたばかりの人にとってどれほど難しく、気が狂いそうになるものか想像もできません
Bunがその問題を解決するという事実だけでも、試してみる十分な理由になります。もう一つのJSランタイムやビルドツールにこんな期待感を抱くとは思っていませんでしたし、Bunチームのおかげで少しまともな気分で一日を過ごせそうで楽しみです
bundler解決戦略**が出てから、この6か月はおおむね問題ありませんでしたごくまれに問題はありましたが、プロジェクト側が直すまでは
pnpm patchとメタデータの修正で回避してきました。2023年はモジュールの年と言ってよく、状況は悪くありませんtype: moduleと.js/.cjs/.mjs/.tsをかき分けて進むときほど自分が間抜けになった気分になることはありません本番アプリでは当然、何を使っているのか明確であるべきですが、プロトタイピングではBunの寛容な動作のおかげで、まずコードを書いて残りは後で心配できます
node:全体を実装しないままの1.0リリースに、ドロップイン代替という表現より良い言い方はないものかと思います最初に試した2つのプロジェクトがドロップイン代替ではなかったことにかなり失望し、今ではBunのあらゆるコミュニケーションを疑うようになりました
背景として、どちらのプロジェクトも
dgramを必要とするoscを使っています。9か月前の機能要望の追跡チケットは見つけましたが実装計画はなく、今回の発表ページでdgramを検索しても何も出てきません簡単な提案として、Bun 1.0でサポートしないモジュールを明示し、Node.js互換性セクションに入れてくれるとよいです
追記: Node対応ドキュメントを見つけました — https://bun.sh/docs/runtime/nodejs-apis。リリースノートにリンクしてくれるとよいです
ざっと見ると、モジュール基準で実装済み17個、部分実装17個、未実装7個ほどに見えます
1.0.0というより**1.0.0-beta**に近く見えますたった今v1.0.0をインストールして
bun replを実行したところ終了コード1で失敗し、調べるとREPLがポート3000を使おうとしていて、私の環境ではすでに使用中でした。GitHubに報告されているバグを見ると、こうした小さな問題がかなり多そうなので、あらゆる主張にはある程度懐疑的でいるべきだと思いますそれでも速度と成果物には非常に強い印象を受けました。このプロジェクトがここまでこんなに早く来るとは思っておらず、もっとずっと時間がかかると思っていました。比較するとDenoはずっと先に始まったのに、今ではかなり遅れている感じがするので、個人プロジェクトではBunを試すつもりです
逸話的には、既存顧客が数百万人いる大きなアプリケーションでBunを試していますが、これまでの唯一の問題はBun自体ではなく、
patch-packageがまだbun.lockbロックファイルをサポートしていないことでしたBunは間違いなくYarnよりはるかに速いです。Yarnを本当に気に入っている立場でそう言っています
“Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.”
詳細な一覧には、サポートしていないモジュールが明記されています
レスポンス解析中にエラーが出てAWS SDK v3を使えず、
node:cryptoが完全には実装されていないためoctokitやjsonwebtokenに依存するものも使えませんでした。jest.resetAllMocks()がないのでテストを走らせられず、別のプロジェクトではbun testが共有ライブラリ呼び出しが間違っていると言って、そもそも実行されませんでしたそのためローカルのワークフローは「Bunで実行してみて、失敗したらNodeで実行し直す」です。少なくともnpmの代替としては使えそうですが、まだサービス実行に使うのは想像しにくいです。うまく動くときは本当に驚くので今後には期待していますが、売り文句がNode互換性なら、1.0と呼ぶのは難しいと思います
コミュニティチャットを Discord ではないプラットフォームへ移すことを考えたことがあるのか気になる
Discord はアクセシビリティ、プライバシー、独占プラットフォームへの依存の問題から HN で何度も取り上げられており、オープンソースの精神ともあまり合っていないように見える。[1] も参考になる
[1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...
Bun 0.6 発表のコメントでも、似た質問がほぼフラグされるほどダウンボートされていた: https://news.ycombinator.com/item?id=35970869
Bun 0.8 発表のコメントでも同じ質問はほとんど関心を集めず、「他のプロジェクトもみんな使っているし……」程度の反応だった: https://news.ycombinator.com/item?id=37244294
正直なところ、Discord は自由・オープンソースソフトウェアプロジェクトがコミュニケーションの場を置くには良い場所だ。「Discord を選ぶとそのプラットフォームを正当化し、FOSS プラットフォームから価値を奪う」という記事の主張は、かなり弱く見える。Discord は実際に正当なプラットフォームで、無料で、魅力的な機能が多く、アクセシビリティも良い。何より、Discord を選んだからといって FOSS のコミュニケーションプラットフォームの価値が消えるわけではない
「IRC を使え」という話も適切ではない。IRC はコンピューターやソフトウェアに慣れていない多くの人にとって、非常にアクセスしにくい
Bun はベンチャー投資を受けているので、収益化計画が気になる
新しい技術を見るときは、「N 年後にもこの技術が活発に開発されている可能性」を考える。Bun は何らかの形で収益を上げる必要があり、そうでなければ資金が尽きるだろう
Bun のライセンスが MIT なのは素晴らしく、会社が潰れてもプロジェクトが死なないかもしれないという希望はある。会社には成功してほしいが、Bun を導入するなら、後でどんなアップセルがあるのか気になる
Oven はバックエンドとフロントエンドの JavaScript アプリ向けに非常に高速な サーバーレスホスティングと継続的インテグレーションを提供し、Bun で動作する予定
Next.js、Vite、SvelteKit、SolidStart のようなフロントエンドフレームワークと、Express、Fastify、NestJS のようなバックエンドフレームワークをサポートする予定
世界中のデータセンターのエッジで自社サーバーを運用する計画で、Oven は JavaScript スタック全体をハードウェアまでエンドツーエンドで統合し、新しい可能性を作ろうとしている
bun deployのような形で JS アプリのホスティングから収益を上げるのだと思うまず開発者による大規模な採用を確保した後、自社のアプリケーションホスティングへ自然に誘導するという、よくある戦略だ
一人のサイドプロジェクトを追いかけようとして苦労しすぎたので、すべて Rollup に移して振り返らなかった
ベンチャー投資を受けたプロジェクトとランダムなサイドプロジェクトの懸念点は明らかに違うが、究極的なリスクはどちらも「作った人が自分をサポートできなくなったらどうするのか」だ
すべてを「オープンソース」と宣伝して、無料のバグ報告、貢献、マーケティング、採用を得た後、商用製品へ押し込むやり方だ
Node ベースのツール群が積み重なった混乱を置き換えられるという提案は非常に魅力的だ
node、ts-node、nodemon、tsc、jest、ts-jest、webpack、Babel、互いに合わない 2 つのモジュール仕様、UMD の混乱、3 つのパッケージマネージャーと、それによって爆発的に増える設定ファイルを減らせるからだJavaScript 周辺のツール環境は間違いなく最大の苦痛で、本来はかなり有能で快適な言語である ES6 + TypeScript を、完全な雑用にしてしまっている。Bun がやり遂げることを願っている
CMake から Cargo に移るときと似た感覚になりそうだ
ブログ記事は、より単純な オールインワンソフトウェアの価値提案を非常に説得力をもって示している
最近は「すべて自分で持ってこい」よりも「電池込み」のソフトウェアに惹かれるので、Bun を試すのが楽しみだ
複数のソフトウェアを、より高速な一つのものに置き換えようとした Rome ツール群のランタイム版のように感じる。Rome は失敗し、新しいチームの OSS へ移行された。Bun にはもっと成功してほしいが、確かに解くのが難しい問題だ
Apple のようにハードウェアと OS を自ら所有し制御できれば、システムを深く最適化できるし、すべてのデバイスが滑らかに動作するという安心感も与えられる。オールインワンのツールセットは、完璧な解を探し回る負担を減らし、すでに目の前にある解を使わせてくれる
Bun と Deno の両方を使ったことがある人に、実際にはどちらがより説得力のある Node の後継なのか聞いてみたい
Bun の Web サイトは Deno より性能がはるかに良いと主張しているが、実際にもそうなのか気になる。そうだとしたら、その理由も知りたい。Deno も似た目標を持っているように見える
2つのプロジェクトの間に哲学的な違いが大きいのかも気になる。たとえば Bun はあらゆるものを再実装しようとしていて、Deno は Node 以後の新しいやり方を望んでいる、というようなものなのかは分からない。両方を十分に使った人はいる？
Bun と Deno はどちらもベンチャー投資に支えられたツールなので、収益化と継続性には根本的な疑念がある
Bun の主な売りは性能に見えるが、Node で大きな性能問題に遭遇したことはあまりない。ものすごく速いわけではないにせよ、Node の速度よりも入出力の制約にぶつかる可能性のほうがはるかに高い
Deno の主な売りは、より良いパッケージング、ES6 の全面採用など、さまざまな面で「ちゃんと作った Node」だった。その主張には惹かれたが、新しいエコシステムを作ろうとする試みは諦めて、Node 互換性を追加する方向に進んだように見える
同時に、Node 自体のテストランナーや組み込みの
.envサポートのような最近の改善は心強い。だから Bun や Deno を使う強い理由を見つけにくいし、仮に乗り換えるとしても、新世代ツールが持続不能になったときに Node へ戻る具体的な経路が必要だBun はあらゆるものをまとめて非常に高速にしつつ、可能な限り Node との互換性を維持しようとしている。既存のエコシステムを捨てていない
Deno は Node エコシステムに対してあまりに対立的な見方を取っていて、今になって再びサポートを追加しているところだ
後継という観点では Bun が唯一の選択肢だと思う。Node 互換性を維持しながら新機能で革新しようとしているからだ
Deno はセキュリティを最優先原則とする代替 Node ランタイムに近く見え、TypeScript と JSX の組み込みサポート、リンターのようなツールも含んでいる。V8 ベースでもある。後になって Ryan Dahl が Node はこうあるべきだったと考えた形に近く見える
Bun は技術的には WebKit ベースだが、正確にそれがなぜなのかは分からないし、ランタイムだけでなく、より優れた オールインワンツールのように見える。既存フレームワークとの基本互換性も提供している。Deno は少し前まで npm 互換ではなく、そもそもそれが意図だったのか、それとも進行中の方向転換だったのかも気になる
先月、代替ランタイムとして Deno と Bun の両方を試した。要約すると、ある程度複雑なコードベースでは Bun はほぼ常に動作し、Deno はほぼ常に動かない
今はすべてのテストを Node.js と Bun の両方で実行しており、Deno を導入しようとする試みは諦めた
訂正: 変わりつつあるようだ。訂正してくれてありがとう
本来は昨日リリースする予定だったが、修正が必要な
fetch()本文ストリーミングのテスト失敗があったブログ記事は Bun 1.0 が GitHub に上がるまで公開される予定ではなかったが、リンクが公開アクセス可能で、RSS フィードに下書きを隠せないバグがあった
実際のバグは
fetch()本文ストリーミングではなく、プロパティが定義されていない可能性のあるオブジェクトからプロパティを取得する JavaScriptCore バインディングにあった。コードの一部は値がオブジェクトかどうかを確認せず、JSCellかどうかだけを確認していたが、JSCellは通常オブジェクトではあるものの、シンボルや BigInt のようなものはJSObjectではない昨日のスレッド: https://news.ycombinator.com/item?id=37424724
追加のヒントとして、「ディストリビューションのリポジトリではなくインターネットからダウンロードする」方式のインストールについて、適切な SHA-256 などのチェックサムを含む Ansible のプレイブック/タスクセット例を提供できる。Puppet も同様だが、少し複雑になるだろう
システム管理者の作業を少し減らせるし、名前を付けたいなら SAX、つまりシステム管理者体験と呼んでもよい
Bun が TypeScript React アプリを標準で実行・バンドルできるなら、その上で Vite.js を使うメリットは何なのか気になる
公式サイトのガイドでは、TypeScript React アプリを作る際に Bun + Vite.js を使う方法を示していて混乱する。[1]
GitHub にも関連する issue がある。[2]
Vite.js は Bun では処理できない、より複雑なシナリオや高度なユースケースを担当するものなのだろうか？ 自分の Vite.js の使い方は、基本的な TS+React 設定で開始してビルドする程度なので、何か見落としているのかもしれない
[1] https://bun.sh/guides/ecosystem/vite
[2] https://github.com/oven-sh/bun/issues/250
まだ Bun を使った経験はないが、ローカル開発サーバーの実行には Node の代わりに Bun を使い、バンドルには esbuild や tsc、Rollup、またはそれらの組み合わせの代わりに Bun を使い、変換には Babel と TypeScript の代わりに Bun を活用できる、という理解だ
Vite が提供するのは、フロントエンドアプリケーション開発を簡単に設定し、ローカル作業時に優れた開発者体験を与える構成だ
まだ設定の複雑さがあるので、両者を組み合わせるのが非常に良いとは思わない
既存エコシステムとの互換性は Bun の中核的な目標なので、人々が既存のコードベースですぐに使い始め、段階的により多くの部分へ導入できるようにしようとしているのだ
そして Nuxt、SvelteKit、Astro、SolidStart、Qwik のような新しいメタフレームワークの大半は Vite 上で動作するため、Bun 採用への道を開ける
tscがあるのになぜ Vite が必要なのか、と尋ねるのに似ているBun が「TypeScript React アプリを実行する」というよりは、JSX/TSX 変換を標準提供する程度だと思う