Deno 2.4 リリース

 (deno.com)
2 ポイント 投稿者 GN⁺ 2025-07-08 | 1件のコメント | WhatsAppで共有
  • deno bundle が esbuild ベースで再導入され、サーバー・ブラウザーの両方で単一ファイルのバンドル生成と自動 ツリーシェイキング、最適化 が可能に
  • テキスト/バイトインポート のサポートや OpenTelemetry 組み込みの 安定化 により、可観測性と外部ファイル活用の体験が強化
  • 新しい --preload フラグ、依存関係の利便性を高める deno update、スクリプトのカバレッジ計測、権限管理、Node.js API 互換性まで幅広く改善
  • LSP、Jupyter、bench/coverage、tsconfig のサポート向上と、さまざまな使い勝手の改善も提供

Deno 2.4 の主な変更点と新機能のまとめ

deno bundle の復活

  • Deno 2.4 では、単一ファイルの JavaScript バンドルを生成する deno bundle サブコマンドが esbuild エンジンとともに再搭載
  • サーバー、ブラウザーの両方をサポートし、npm、JSR 依存関係も問題なくバンドル可能
  • 自動 ツリーシェイキング と コード最適化（minify） のサポートにより、管理しやすい環境を提供
  • 今後は ランタイム API と プラグイン を通じて、バンドルプロセスのプログラム的な拡張やカスタマイズ機能が追加される予定

テキストおよびバイトインポートのサポート

  • JavaScript モジュールグラフに テキスト、バイナリ、画像などの外部データファイル を埋め込めるようにするため、--unstable-raw-imports フラグを提供
  • 従来はファイル入出力（I/O）で外部ファイルを読み込む必要があったが、今後はインポート構文でファイルタイプを指定して 直接バイト/テキストデータ を利用可能
  • この機能はバンドル時、コンパイル時にも動作し、成果物への アセット埋め込み を簡単に実装できる
  • JSON、Wasm など既存のインポートサポートとあわせて、複数のファイル形式を 仕様に沿った形 で管理できる
  • まだ仕様策定中ではあるものの、Deno は機能の進化と標準化の動向をバランスよく反映している

OpenTelemetry 組み込みの安定化

  • 2.2 で導入された OpenTelemetry 組み込みサポート が、2.4 で完全に安定化
  • OTEL_DENO=1 環境変数を設定するだけで、追加フラグなしに ログ、メトリクス、トレース収集 を自動化可能
  • Node.js との 設定不要の互換性 と、Deno Deploy のデプロイ環境まで一括してサポート
  • console.log ログと HTTP リクエストの 自動関連付け/観測 も可能
  • リソース使用の特性上、環境変数による制御が必要

実行前の環境設定用 --preload フラグ

  • メインスクリプト実行前に グローバル環境の変更、データ読み込み、依存モジュール登録など のためのコードを先に実行できる --preload フラグを追加
  • プラットフォームのカスタマイズやグローバルオブジェクトの再設定など、さまざまな プラットフォーム構築 に役立つ
  • deno run、deno test、deno bench など主要コマンドで利用可能

依存関係管理の簡素化: deno update

  • npm、JSR 依存関係を 最新バージョンへ自動更新 する deno update サブコマンドを導入
  • 複数の依存関係を一度に更新し、Semver 互換性 に基づく精密なアップデートをサポート
  • 既存の deno outdated --update のエイリアスも提供し、使い勝手を向上

スクリプトカバレッジ: deno run --coverage

  • 各テストだけでなく、subprocess を含む実行全体 のカバレッジ収集が可能に
  • DENO_COVERAGE_DIR 環境変数など、さまざまな方法で柔軟にデータ管理が可能
  • HTML カバレッジレポートの ダークモード サポートを追加

Deno 互換環境変数 DENO_COMPAT=1

  • npm エコシステムおよび package.json ベースのプロジェクトにおける 利便性 と互換性を高めるため、DENO_COMPAT=1 変数を導入
  • 複数の不安定（Unstable）フラグを自動適用し、今後は npm prefix 省略などサポート範囲をさらに拡大する予定

権限管理とセキュリティの改善

  • --allow-net フラグで サブドメインのワイルドカードおよび CIDR 範囲 をサポート
  • コードがインポート可能なホストを制限する --allow-import、明示的に遮断する --deny-import フラグを新設
  • Deno.permissions API で "import" 型クエリを正式サポート
  • Deno.execPath() 使用時に 読み取り権限が不要 となり、実行ファイルパスを活用しやすくなった

条件付き package.json exports

  • npm パッケージで 条件付き exports をサポートし、特に React サーバー構成など幅広いエコシステム対応を強化
  • ユーザー条件フラグにより、柔軟にカスタム import 動作を実装可能

deno run での bare specifier サポート

  • deno.json の "imports" に設定したエイリアス（bare specifier）でコマンドのエントリーポイントを実行可能
  • 開発生産性と モジュール管理の自動化 の面で大きな利便性を提供

XML、SVG などの形式におけるコード整形の改善

  • deno fmt で .xml、.svg、.mustache など多様なテンプレートファイルの自動整形をサポート

tsconfig.json サポートの強化

  • references、extends、files、include、exclude など各種オプションの認識精度を改善
  • Vue、Svelte、Solid、Qwik など最新フロントエンドフレームワークとの互換性を向上

Node のグローバル変数および API 互換性の向上

  • Buffer、global、setImmediate、clearImmediate など Node.js のグローバルオブジェクト がユーザーコードでも常に存在するよう変更
  • npm パッケージ専用だったグローバルも コマンドフラグなしですぐに利用可能 に
  • node:buffer、node:events、node:querystring、node:quic、node:wasm などで 95% 以上の互換性 を達成し、今後も継続的に拡大予定
  • @types/node の型のデフォルトバージョンも 22.15.14 に更新

ローカル npm パッケージ管理の変更

  • npm ローカルパッケージ接続オプション名を patch から links に変更し、npm link の意味に一致
  • 既存オプション使用時には 非推奨警告 を表示し、より明確なパッケージ管理が可能に

LSP と開発生産性の改善

  • LSP の性能・機能改善に加え、fetch の Unix/Vsock ソケット対応、サーバーの onListen コールバック、Jupyter カーネル管理、lint プラグインでのコメント読み取り、bench/coverage テーブルの Markdown 互換性など、さまざまな利便性を提供
  • Windows での Ctrl+Close シグナル認識（windows SIGHUP）や、bench/coverage テキスト出力の Markdown フォーマットなども新たに改善

コミュニティと貢献者への謝辞

  • Deno 2.4 の発展には、多様なコミュニティ貢献者 の参加とフィードバックが大きな役割を果たした
  • 詳細や追加の変更点は GitHub リリースページ を参照可能

結論

  • Deno 2.4 は バンドル、外部ファイルインポート、可観測性、権限/セキュリティ、互換性、生産性 など多方面で大きな進化をもたらす
  • 開発フローや最新フロントエンド、Node エコシステムのプロジェクトで 簡単かつ強力な統合開発環境 を体験できる
  • 追加情報や最新ニュース、全変更履歴は公式ドキュメント、ブログ、GitHub リリースページで確認できる

関連記事

1件のコメント

 
GN⁺ 2025-07-08
Hacker Newsの意見

  • Denoのコンセプトがとても気に入っていて、Next.js、Hono、そしてプライベートパッケージを含むモノレポプロジェクトに deno.json、JSR、モダンな import、Deno Deploy などをできる限り適用してみた経験を共有。Honoはきれいにうまく動いたが、Next.jsはそうではなく、型まわりの問題も微妙に壊れることがあった。デプロイ先（Vercel など）の選択も問題だった記憶。例として遭遇した小さな問題を イシューリンク で共有。一方で Bun は Deno ほど使用感が洗練されてはいなかったものの、考えることが少なく、とにかく「動く」という印象だった。ただし Bun も Vercel で Bun ランタイムが未対応であるなど、完璧ではない

    • 選んだスタックが依然として npm 中心で、特にプライベート npm パッケージが多い環境では無理があった、という助言。Deno的な方式の魅力は、Deno あるいは ESM に親和的なスタックを自前で選べる点にあると思う。Lume を使ったり、Deno Deploy をターゲットにした経験は良かった。（JSR スコアのおかげで、興味深く ESM 互換性の高いライブラリを探す助けにもなった）もちろん、完全に新しいスタックで始めろというのは現実的に難しく、既存の Next.js などへの投資も大きいため、Deno を勧めるのは負担がある。しかし Deno の強みが現れるのは、Deno-native、ESM-native なツール群でゼロから始める環境だと思う。ちなみに Deno の npm 互換性は徐々に良くなっており、2.4 リリースノートにも関連する改善内容がある。フルスタック環境では deno.json より package.json 優先のアプローチのほうがむしろ互換性が高いので、長期的には deno.json に寄せるとしても、package.json ベースの設定もおすすめ

    • npm 互換モードで Deno を使ってみると、意外とうまく動く印象。Bun の使い方とかなり似ている。package.json があるディレクトリで deno install を実行すると、スリムな node_modules を作ってくれ、deno task something コマンドで package.json に定義されたスクリプトを実行できる。ただし Deno 独自のやり方は時間がかかることが多くてもどかしく、再び node/npm 環境に戻ろうとすると余計に面倒になる。結論として、Deno を package.json と一緒に使うほうが楽

    • 最初は Deno に全振りしていたが、些細な問題があまりにも多くてつらかった経験。それに比べると Bun は特に気を遣うことなくうまく動く

  • Deno の node 互換性は過小評価されがち。compat 環境変数の導入が普及の助けになることを期待。denon などのコマンドが自動で有効化してくれる形ならもっと便利そう

    • 自分の経験では、Deno の node 互換性は期待以下だったという失望。100〜200 行ほどの簡単なプロジェクトを Deno に移すのに 1 時間ほどかかったが、本来なら 5〜10 分で終わるべきだった。node の一部メソッドが未対応で、関連ドキュメントも不十分だったし、基本機能ですら obscure な URL から直接ダウンロードしなければならなかった。テストスイートの移植では結局断念。特に CommonJS（CJS）から ESM への移行は思ったよりはるかにつらく、Deno の公式ドキュメントが説明するほど簡単に移行できるものでは決してなかった。ライブラリ全体を移植できなかった経験

    • 以前は Deno にかなり好意的だったが、今では Bun の代わりに Deno を使う理由を特に感じない

  • Deno の最近の変更リストは良いという評価。ランダムなスクリプトやグルーコードを書く用途で Deno を満足して使っており（機械学習などは Python/uv を活用）、今後の gRPC サポートや bundle コマンドにも期待

  • いまだに Deno が FreeBSD でまともに動かないのが不思議だという話。Rust ベースの V8 バインディングがまだ移植されていない

    • 現代の JavaScript 開発者で FreeBSD ユーザーが実際どれくらいいるのか気になる

    • 昔は Unix 間の移植性がコードの清潔さの尺度だったのに、今ではさまざまな Unix 系システム間の互換性があまり重視されていないのが意外

    • FreeBSD 向けポートには登録されているように見える

    • FreeBSD サポートに大きな労力を割いていない理由は十分納得できる

  • Deno が本番環境でより広く使われない理由は、標準化された脆弱性 DB がないからだという意見。npm 100% 互換性で補うことは可能だが、その場合は大半の人気 deno パッケージが対象外になってしまう。根本的には中央パッケージマネージャがない点（意図された設計）が課題。関連する進展があったのか質問

    • もし脆弱性 DB の欠如が本当に本番環境で大きな問題になるなら、C/C++ も同じように使えないはずだという反論。実際、C/C++ では言語中立の CVE/GHSA DB などを参照してセキュリティ問題を確認する。ちなみに C は単に外部ファイルをベンダリングして使い、バージョン追跡すらしないことが多い。また deno.lock ファイルがあるので、気にする人はこれに基づいて使用バージョンに対する脆弱性 DB チェックが可能

    • URL（GitHub など）から直接パッケージを取得する構造は Go も似ているので、同じ問題は Go にも当てはまる

  • bundle サブコマンドが再び追加されたのがうれしい。面倒な回避策が不要になって満足

  • バンドル作業に Rust ベースの Rolldown ではなく esbuild を採用したのは意外。Rolldown はもうすぐ v1 になる予定なのに

    • esbuild は現在とても安定して成熟している一方、Rolldown はまだ急速に変化しているため、esbuild を選ぶほうが無難

  • Deno の方向性は本当に気に入っていて、Node は本来こうあるべきだったと思う。ただ懸念しているのは、競合の「ハイプ」に流されて Deno まで主体性なく追随してしまうこと

    • Deno 自体もこれまで Node.js の「ハイプ」ベースの競合として見られていた気もする

  • Deno について良い評価を聞き続けている。そのおかげで、js を一度使ってみようかという気にもなってきた

    • 今なら最初から TS で始めるのも良い選択

  • セキュリティの観点から Deno を応援しているが、公式サイトでユーザーに curl mywebsite.com/foo.sh | sh 形式のインストールを勧めている点が気になった経験を共有。もちろんリスク許容度は人それぞれだが、少なくともファイルをダウンロードしてから実行すれば、自分やアンチウイルスが点検できる。Node/Deno + npm エコシステムは基本的にかなりの信頼を要求する構造。公式ガイドでは curl | sh のほかに npm install -g deno オプションも提供しているが、npm には最低限のファイル完全性チェックと簡単なマルウェア検査があるので相対的には安全。deno.land の Web サイトも codebase レベルでは安全でも、運用面で 100% 保証はできないため、curl | sh はセキュリティのベストプラクティスではないと思う

    • この論理には同意しない立場。ほとんどのインストールスクリプトは、結局のところ同じ作者が作った数百〜数百万行のバイナリを取得して実行する役割しかない。もし作者をまったく信頼できず、サーバーが特定の IP にだけマルウェアを配布するかもしれないと想定するほどなら、バイナリレベルでもマルウェアを仕込めるので、そもそもそのプロジェクトを使うべきではないと思う。curl | sh 論争が広まったのは、簡単で繰り返しやすい論点だからで、むしろ数百万行のコードレビューこそが本当のセキュリティ問題。もし政府機関による MITM 攻撃まで心配するレベルなら、そもそもインターネット外部への信頼を断つしかない

    • 新規ユーザーのオンボーディングに難しさがあるという指摘。npm を使えと勧めても、まず npm 自体がインストールされている必要があるが、npm 公式サイトは nvm のインストールを案内し、nvm ですら curl | sh を使う。結局 npm ルートも間接的には同じ問題

    • npm install -g deno が curl | sh より実際に安全かという議論では、核心は「npm サーバーと独自サーバーのどちらにハッカーが侵入しやすいか」にある。もし独自サーバーが侵害されていないと確信できるなら、curl | sh が npm install より安全性で劣る理由もない。結局セキュリティ観点では両方とも同じように脆弱になりうるので、極端に言えばインターネットを使うこと自体が問題になる

    • Deno のサンドボックス実装は 90 年代の技術っぽく、使うこと自体が良いセキュリティ習慣ではないという批判

    • 実際に curl | sh インストール方式への攻撃が実戦で成功した事例があるのか気になる