Deno 2.8

• deno addとdeno install は、CLIでプレフィックスなしのパッケージ名をデフォルトで npm: パッケージとして扱うようになり、既存のNodeプロジェクトで npm install・yarn・pnpm install の代わりに使いやすくなった
• deno audit fix は、npm依存関係の脆弱なパッケージをバージョン制約を満たす最も近いパッチバージョンへ自動アップグレードし、メジャーバージョン変更が必要な項目は別途表示する
• 新しいサブコマンドとして deno ci、deno pack、deno transpile、deno why、deno bump-version が追加され、再現可能なインストール、npm配布用tarballの生成、TS→JS変換、依存関係パスの追跡、ワークスペースのバージョン更新をサポートする
• Node.js API互換性 は、Node自身のテストスイート基準でDeno 2.7の約42%からDeno 2.8では76.4%（3,405/4,457）へ向上し、多くの node: モジュールが遅延ロードされるようになったため、それらのモジュールを使わないプログラムの起動が速くなった
• 性能 は、Deno 2.7.1比でコールドnpmインストールが3,319msから906msへと3.66倍高速化し、node:buffer の base64 は3.07倍、node:http のスループットは2.21倍、node:crypto の scrypt は2.12倍改善された
• 互換性の変更 として、グローバルの setTimeout と setInterval は数値ではなくNodeの Timeout オブジェクトを返すようになり、戻り値を number として保存したり型チェックや算術に使っていたコードは NodeJS.Timeout などへ修正する必要がある
• TypeScript 6.0.3 が組み込まれ、deno check とLSPはデフォルトで lib.node を含むため、NodeJS.*、Buffer、process などのNode型を追加設定なしで解釈できる
• デバッグ では、Chrome DevToolsのNetworkタブがDenoの fetch()、node:http/node:https、WebSocket トラフィックを表示し、--cpu-prof、--cpu-prof-flamegraph、--cpu-prof-md によりV8プロファイル・SVGフレームグラフ・Markdownレポートを生成できる
• パッケージ・ワークスペース管理 では、catalog: プロトコル、deno install --os --arch、--prod、nodeModulesLinker: "hoisted"、.npmrc の min-release-age、--package-json が追加され、モノレポのバージョン統一、クロスプラットフォームインストール、本番用インストール、既存Nodeプロジェクトの移行を補完する
• deno compile は、Next.js、Astro、Fresh、Remix、SvelteKit、Nuxt、SolidStart、TanStack Start、Vite SSRプロジェクトを検出して deno task build を実行し、適切なエントリポイントを生成し、大規模なnpm依存ツリーを処理中の進行状況も表示する
• テストとWeb API では、Deno.test() の sanitizeOps・sanitizeResources のデフォルト値が false に変わり、テストごとの timeout と関数単位のカバレッジが追加されたほか、OffscreenCanvas、転送可能な Headers・Request・Response・Streams、SHA3 digest、P-521 Web Cryptoサポートが導入された
• アップグレードとランタイム基盤 では、deno upgrade が可能な場合は差分アップデートによりダウンロードサイズを約48MBから3〜6MBに削減し、deno upgrade pr <number> でPRビルドをインストールでき、V8は14.6から14.9へ更新された

[GN⁺]

Hacker Newsのコメント

• Deno はデフォルトの権限モデルがあるので便利で、Rust で書かれており、TypeScript をネイティブにサポートしている。
  Web 開発/Node/Bun のエコシステムにはそこまで深くないが、ここ数年は小さなサービスで Deno を満足しながら使ってきた。Bun が急速に成長しているように見える理由が気になる。主にバンドラとして使われていて、JavaScript ランタイムとしてはあまり使われていないのかもしれない。
  権限システムだけでも Deno は魅力的なのに、Node から Bun に移る際に Deno に行かない理由があまりよく分からない

  • Deno と Bun はリリース当時、かなり焦点が違っていた。Deno は Node の元作者である Ryan が、Node で間違っていると考えた多くの部分を直そうとしていた一方、Bun は最初から Node 互換性と Next.js のような人気フレームワークの実行に注力していた。
    長い間、多くの依存関係やフレームワークが Deno ではまともに動かなかったし、初期には npm から依存関係をインストールする機能すらなかった。npm のサプライチェーン攻撃を振り返ると、Ryan の判断は正しかったのかもしれない。
    そのため Bun は、設定がずっと少なくて済み、すぐ動く便利機能の多い、より良い Node のように見えた。Deno チームも成功するには Node 互換性が必要だと気づき、ここ数年はそこに集中してきたようだ。今では Deno のほうが Bun より Node と互換性が高いと思う
  • 小さな TypeScript のサイドプロジェクトを始めるとき、npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime の海に溺れる代わりに、Bun ひとつだけ使えばいい。
    参考までに、そのうちの一部だけが Pokémon の技で、残りは実際の JS/TS エコシステムのツールだ
  • どちらも使っていて気に入っている。Bun は Node のドロップイン代替に近い。
    テスト設定、tsconfig、ES モジュールのようなものをいじりたくないとき、だいたいそのまま動く。Deno は標準ライブラリが良く、CLI サポートも素晴らしいし、以前は deno deploy も気に入っていたが、最近はかなり面倒になった
  • 主にバックエンド開発者だが、個人プロジェクトでフロントエンドを少し触るときは Deno が最も理にかなった選択に見える。
    本当に作業しやすく、JS 界隈でもっと広まっていないのが惜しい
  • Deno を1年ほど使っていて、前述の利点のおかげで気に入っていたが、Astro、Prisma、Vite のようなパッケージとの互換性問題が多すぎた。
    そのため Bun に移行し、ずっとスムーズになった

• Deno が最近どんな状態なのか気になる。
  Node は安定した解決策で、今後も残り続けるだろう。今では TypeScript も使えるし、近いうちにネイティブ依存関係まで含めてアプリを単一実行ファイルにビルドできるようになりそうだ。
  Bun は混沌としているが速く、標準ライブラリにすべてを含めるアプローチが興味深い。しかも Anthropic に買収された。
  Deno にはサンドボックスとサードパーティ依存関係の取り込みやすさという魅力的な物語があったが、サンドボックスは今ではかなり一般化した感じがあり、import 方式も結局 npm add よりそこまで大きく優れていたのかは分からない

  • Deno は約2か月前に会社の半分ほどをレイオフした: https://news.ycombinator.com/item?id=47467746
  • Anthropic に買収されたことを前向きに見る人なんているのか?
  • エコシステムが停滞しないようにするには、選択肢が複数あることが良い
  • すでに 単一実行ファイルでの配布は可能だ。自分の製品の CLI は Node の単一実行ファイルアプリケーションだ
  • ネイティブ依存関係まで含めた単一実行ファイルのビルドが可能になるとは知らなかった。それは強力な機能だ

• Deno は素晴らしい。小規模な Web サービスや中規模の Web サービスを Deno で書いている。
  スイス時計のようにきちんと動くし、プロジェクトの哲学も Unix の精神によく合っている。
  個人的には Deno を作っている人たちは少し謙虚すぎると思う。感謝しているユーザーがプロジェクトへの寄付を申し出ても、丁重に断っている。理由は理解できるが、長期的にはプロジェクトに不要な資金面の圧力を生むかもしれない。
  プロジェクトの長期的成功に依存しているユーザー向けの「お願いだからお金を受け取ってくれ」的な月額サブスクリプションは、かなり相性が良いかもしれない

  • 本当に使っていて楽しい。ほとんど JavaScript と Go の混合のように感じる。
    高速で柔軟で、他の JS/TS 代替よりも強力な機能を持つ、少し正気なパッケージ管理、より良いセキュリティモデル、より良い標準ライブラリを提供している。そしてとても速い

• Deno という名前に馴染みのない人のために言うと、Deno は JavaScript と TypeScript のランタイムだ。
  Deno 2.6 を競合の Bun 1.3、Node.js 25 と比較したレビューがある: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

  • Bun が Web リクエスト処理でそこまでずっと速いのは驚きだ。記事では Zig を要因として挙げているが、メモリのきめ細かな管理だけで Node 比 2 倍以上の差が出るのだろうかと気になる。
    同様に、明言はしていないが、Bun はウォームなパッケージキャッシュ状態で実行したようにも見える。他のランタイムにもキャッシュがあったのか気になる

• Deno の 着実なリリースサイクルは印象的だ。今回のバージョンにどんな性能改善が入っているのか楽しみだ

• 新しい deno pack コマンドは、安全でシンプルなパッケージングのための良い追加機能だ。
  Node.js を使う場合、似たような単一コマンドは https://www.npmjs.com/package/ts-node-pack で可能だ。
  いまや Node.js は .ts モジュールの import をサポートしているので、より多くのリポジトリがビルド段階やチェックアウトにビルド成果物を含めずにこれを利用できるようになる

  • このブログ記事を見て、すぐに考え込んでしまった。deno pack は自分のオープンソースパッケージの既存の npm publish フローを置き換えるのに使えて、作業を Deno ファースト/Deno 中心へさらに移していくのにも良いかもしれない。
    一方で、Node の TypeScript サポートが強まっているので、TypeScript 専用の npm パッケージに変えることも、エコシステムに送るごく小さなメッセージになると思う。
    それでも JSR が比較的きれいなエコシステムとして存在しているのは嬉しい
  • かなり前からあった DNT(https://github.com/denoland/dnt) とかなり似ているように聞こえる。
    ただ、Deno CLI に入ることで 可視性は大きく上がる

• Deno が初期の価値観をもう少し長く保っていたら、Node 互換性への圧力は AI エージェントがある程度埋めてくれたのではないかと思う。
  その圧力のかなりの部分は習熟度の問題から来ている。express.js での設定方法しか知らないなら、その後のどんなツールやランタイムにも「スムーズな」移行のために似た抽象化が提供されるべきだと感じてしまう。最初の解決策がそもそもどれだけ悪かったかとは無関係に。
  最近では、製品と一緒に必要な技術スタックを渡しながら開発者に新技術を紹介できるし、これが実際にドキュメントの代わりになることもあり、より良い代替アプローチを示すのにかなり有効な場合もある

  • SaaS 事業者から受け取った JS/TS SDK が修正なしで Deno で動かないなら、それを直すために1秒たりとも使わないだろう

• いくつもの趣味プロジェクトで Deno を使ってきた立場から、Deno は JS エコシステムが向かうべき方向だと確信している。
  ただし、仕事で特定の、しかもたいていは範囲の狭いユースケース以外に勧めるのは難しい。プロジェクトがどこかの時点で事業上の理由により方向転換すると、結局 Node が必要になる

• Edge.js [1] の公開後、Deno が Node.js 互換性をより真剣に扱い始めたのは良いことだ。
  わずか2か月で 40%台から 75% 程度まで上がったのだから、偶然であれ何であれ、正しい方向への明確な一歩だ。
  Deno チームのみんな、お疲れさま。
  [1] https://edgejs.org/

  • 自己宣伝ばかりでうんざりしないのか?

• Node 流の慣習の大半を包みつつ、Deno をランタイムとして使っている。うまく動く。
  プロジェクトが純粋な TypeScript なら、そのまま Deno で実行する。セキュリティのための追加オプションも良いし、インストールスクリプトがデフォルトで無効になっている点も良い。
  Node を直接使っているならやめたほうがいい。少なくとも Bun を使うほうがまだ良いと思う。
  エージェントベースの作業では、Rust と TypeScript 以外を使う理由はほとんどない。異論はあるだろうが、型安全性、メモリ安全性、膨大な作業コーパスが重要だ。エージェントは厄介なエラーや組み込みパターンがあると探索しやすい。UI にはデザイン例があまりにも多いため、TypeScript が最も妥当だ