Programming Languages

概要 Microsoftは2026年4月30日、Visual Studio 2026 18.6 Insiders 3にてTypeScript 7 Betaをデフォルトの組み込みSDKとして有効化したことを発表した。これは、TypeScriptコンパイラをJavaScriptからGo言語でネイティブ実装し直す大規模なアーキテクチャ刷新の成果であり、IDEから直接その恩恵を受けられるようになる重要なマイルストーンである。独自のTypeScriptバージョンを指定していないすべてのTypeScript/JavaScriptプロジェクトがこの新しいネイティブコンパイラを使用するようになる。 パフォーマンスの大幅な向上 新しいネイティブコンパイラは、従来のJavaScript実装と比較して顕著なパフォーマンス改善をもたらす。大規模コードベースにおけるコンパイル時間は最大10倍短縮され、メモリ消費量も削減される。また、プロジェクトの読み込み時間は約8倍高速化された。 IDE上での体験においても、IntelliSenseや補完候補の表示が特に大規模プロジェクトで迅速になり、ソリューション全体を対象とした「すべての参照を検索」や「定義へ移動」のナビゲーションもより高速に動作する。コードを入力しながらリアルタイムにエラー診断が更新されるため、開発者の生産性が全体的に向上する。 バージョン管理と既知の制限 従来のTypeScript 6.xを引き続き使用したい場合は、npmでtypescriptパッケージをインストールするか、特定のネイティブバージョンには@typescript/native-previewパッケージを利用できる。機能を無効化する場合は、「ツール > オプション > プレビュー機能」から「Enable JavaScript/TypeScript Native Language Service Preview」をオフにすることで切り替え可能だ。 現時点ではプレビュー段階であるため、いくつかの既知の問題がある。.cshtmlのスクリプトタグ内でのIntelliSense補完が機能しない場合があること、クイックフィックスやコードリファクタリング機能が未実装であること、ナビゲーションバーにドキュメントシンボルが表示されないこと、CodeLensの参照カウントが宣言の上に表示されないこと、JSDoc自動生成が動作しないこと、ファイル・フォルダのリネーム時にimportが一貫して更新されないことなどが挙げられる。問題に遭遇した場合は、typescript-go GitHubリポジトリまたはVisual StudioのDeveloper Communityプラットフォームへのフィードバックが推奨されている。

概要 NestJS の作者 Kamil Myśliwiec 氏は、メジャーバージョン v12 のロードマップをドラフトプルリクエスト（PR #16391）として公開した。リリース目標は2026年Q3初頭とされており、CommonJS（CJS）から ECMAScript Modules（ESM）への完全移行を中心に、テストフレームワーク・リンター・バンドラーの全面刷新、そしてモダンなバリデーションライブラリのネイティブサポートなど、エコシステム全体に及ぶ大規模な変更が含まれる。この発表はX（旧Twitter）で800件を超えるいいねを集めるなど、コミュニティから大きな注目を浴びた。 ESM完全移行——Node.jsの「require(esm)」が後押し v12 最大の変更は、全公式パッケージを CommonJS から ESM へ移行することだ。Myśliwiec 氏は「Node.js の require(esm) サポートが、この移行に必要な最後のピースだった」と述べており、CJS コードから ESM モジュールを require() で読み込める Node.js の新機能が実現の鍵となった。これにより、既存の CJS ベースのプロジェクトは大幅な書き換えなしに v12 へ移行できる見込みで、互換性への懸念を最小限に抑えながら段階的な採用が可能になる。 新機能——Standard Schema によるネイティブバリデーション v12 では @Body・@Query・@Param などのルートデコレータに schema オプションが追加され、Standard Schema に準拠したバリデーションライブラリを直接利用できるようになる。これにより、従来の class-validator に代わって Zod・Valibot・ArkType といったモダンなライブラリを公式にサポートする。型安全なスキーマ定義ライブラリが急速に普及している近年のトレンドに対応した機能追加であり、既存の NestJS プロジェクトにおけるバリデーション層の柔軟性が大幅に向上する。 ツールチェーンの刷新——Vitest・Oxlint・Rspack テスト・リンティング・バンドリングの各レイヤーでデフォルトツールが入れ替わる。ESM プロジェクトではテストフレームワークが Jest から Vitest に切り替わる（既存の CJS プロジェクトは Jest を継続利用できる）。Vitest は TypeScript デコレータの処理に OXC を採用しており、ESM 環境との親和性が高い。リンターは Rust 製の高速ツールである Oxlint が ESLint に取って代わり、バンドラーは Webpack から Rspack へ移行してビルド速度の大幅な向上が見込まれる。コミュニティからは Bun や Biome の CLI オプションへの追加を求める声も上がっており、今後の検討が期待される。 ...

概要 JavaScriptテストフレームワークVitest 4.1が2026年5月1日にリリースされた。今回のリリースは「テスト整理」「ネイティブ実行」「AIエージェント最適化」の3つを主要テーマとして掲げており、Vite 8への完全対応も同時に提供される。VoidZeroがメンテナンスするVitestは、Jestと互換性のあるAPIを維持しながら、大規模プロジェクトでのパフォーマンスや開発者体験の向上を継続的に進めている。5万件のテストを持つプロダクションモノレポを対象にしたSitePointのベンチマークでは、コールドスタート・ウォッチモードの再実行・ピークメモリ使用量のいずれにおいてもJestを上回る結果が示されている。 テストタグとライフサイクルフックの強化 2025年10月から要望が挙がっていた機能として、Pythonのpytestマーカーに着想を得たテストタグ機能が搭載された。各テストにラベルを付与し、論理演算子やワイルドカードを用いて実行対象を柔軟に絞り込める。たとえば vitest --tags-filter='frontend && !flaky' と指定することで、フロントエンド向けテストのうち不安定なものを除外して実行できる。大規模コードベースでのテスト管理に大きく貢献する機能だ。 ライフサイクルフック面では、テストをコンテキストでラップするための aroundEach と aroundAll が新たに追加された。また test.extend ビルダーパターンの型推論が改善され、カスタムフィクスチャを利用する際の型安全性が向上している。CIとの連携を強化する github-actions レポーターも導入され、テスト統計やフレイキーテストのハイライトを含むJobサマリーをGitHub Actions上で自動生成できるようになった。 ネイティブNode.js実行モード（実験的） 実験的機能として、Viteのモジュールランナーサンドボックスをバイパスする viteModuleRunner: false オプションが追加された。これを有効にすると、Node.jsのネイティブインポートが使用されるため、起動速度の向上と本番環境により近い挙動が期待できる。Node.js 22.18以降または23.6以降を使用している場合、ネイティブのTypeScriptストリッピングが追加設定なしで利用可能となる。Bunとも動作するが、現時点ではモジュールモックとカバレッジ機能はサポートされておらず、今後の対応が見込まれる。 AIエージェント向けのagentレポーター AIコーディングエージェントによる開発ワークフローへの統合を意識した専用レポーター agent が追加された。AIエージェントがテスト実行結果を解析する際に消費するトークン数を削減することを目的に設計されており、LLMベースのコーディング支援ツール内でVitestを活用するユースケースを直接サポートする。 リリース後に確認された不具合 リリース直後に2件の問題が報告されている。1つ目は、カバレッジの無視ヒントに関するリグレッションで、@preserve アノテーションが必要となる挙動が確認された。2つ目は、更新されたViteのピア依存関係の記法によってYarn Classic（v1.x）での導入が壊れる問題だ。いずれも既知の問題として追跡されており、修正が進められている。

概要 GCC 16.1が2026年4月30日に正式リリースされた。今回のメジャーリリースで最も影響の大きい変更は、C++コンパイルのデフォルト言語標準がGNU++17からGNU++20へ引き上げられたことだ。これにより、-std=オプションを明示せずにコンパイルした場合、C++20の機能セットが自動的に適用される。既存のコードベースでC++17以前の動作に依存している場合は、-std=gnu++17などのオプション指定か、コード側の修正が必要になる。 C++26の先進機能についても実験的サポートが追加されており、リフレクション（Reflection）・契約システム（Contracts）・構造化バインディングの拡張・constexpr例外処理など、次世代標準の機能を先行して試せる環境が整った。 エラーメッセージと診断機能の大幅改善 GCC 16では、開発者体験を向上させる診断機能の強化が目立つ。これまで実験的オプションとして提供されていた階層的エラーメッセージ表示がデフォルト動作となった。テンプレートを多用するC++コードでよく発生する複雑なエラーが、インデントと箇条書きによるネスト構造で表示されるようになり、問題箇所の特定が格段に容易になった。従来の表示形式に戻す場合は-fno-diagnostics-show-nestingオプションを使用できる。 診断出力の形式も拡充されており、実験的機能としてHTML形式の出力（-fdiagnostics-add-output=experimental-html）が追加された。ブラウザで視覚的に制御フローや状態遷移を確認できるため、静的解析器のデバッグ作業などで効果を発揮する。また、機械可読なJSON形式のSARIF出力も強化され、名前空間・クラスの階層関係を保持する論理的ロケーション構造や、例外処理・longjmpを含む制御フロー情報の表現が追加されてSARIF 2.2標準に対応した。 静的解析器とその他の変更 静的解析器（-fanalyzer）では、C++言語のサポートが進み、例外処理とNRVO（Named Return Value Optimization）への対応が加わった。内部データ構造であるsupergraphの再設計やメモリバッファ追跡の改善も行われ、Rangerとの統合による値の範囲追跡機能の活用も開始している。ただし、複雑なC++コードに対するスケーリング問題は依然として残存しており、本番環境での使用はまだ推奨されていない段階だ。 互換性に関しては、Solaris環境でint8_t等がsigned charとなりC99標準準拠となったものの、非互換変更として注意が必要だ。C++20デフォルト化とあわせて、既存プロジェクトをGCC 16に移行する際には事前の動作確認を推奨する。

概要 Spring Modulithは2026年4月24日、バージョン2.1のリリース候補1（RC1）を公開した。2.1 RC1は最終GA（一般提供）リリースに向けた候補版であり、最近追加された機能の改良、バグ修正、プラットフォームのアップグレードに重点を置いている。同時に、現行安定ブランチの2.0.6および旧バージョンの1.4.11も、依存関係のアップグレードを中心としたバグフィックスリリースとして公開された。 2.1 RC1の主な変更点 2.1 RC1では複数の改善が施されている。 モジュールスライシングの強化（GH-1644）：@ModuleSlicingアノテーションが、明示的に宣言されたクラスの@SpringBootApplicationを優先するよう改善された。これにより、スライス境界の検出がより正確になり、テスト時のモジュール分離が意図どおりに機能しやすくなる。 JobRunrインテグレーションの改善（GH-1655）：JobRunrを利用した非同期ジョブ処理において、トランザクション処理が改善された。イベント駆動のバックグラウンドジョブとトランザクション境界の整合性が向上している。 イベントパブリケーションレジストリの改善（GH-1652, GH-1650, GH-1647）：イベント処理に関連する複数のissueが修正され、より堅牢なイベントパブリッシュ・受信の仕組みが実現された。 バグフィックスリリース（2.0.6・1.4.11） 安定版の2.0.6と旧安定版の1.4.11は、主に依存関係のアップグレードを含むバグフィックスリリースとして提供される。新機能は含まれていないが、セキュリティや互換性の観点から既存ユーザーへのアップグレードが推奨される。 今後の展望 2.1 RC1は最終的な2.1 GAリリースに向けた候補版であり、今後はコミュニティからのフィードバックを取り込みながら安定化が進められる見通しだ。各バージョンの詳細なチェンジログはGitHubのリリースページで確認できる。

概要 Astral社が開発するRustベースのPythonパッケージマネージャー「uv」は2026年4月27日、バージョン0.11.8をリリースした。本リリースでは、Astralミラーを介したself-updateサポートや、任意のミラーからPythonをダウンロード可能にする新フラグの追加など、使い勝手を向上させる複数の機能強化が含まれている。また、環境変数による設定オプションの拡充や、細かなバグ修正も行われた。 新機能と機能強化 最大の目玉の一つは、python pinコマンドへの--python-downloads-json-urlフラグの追加だ。これにより、デフォルト以外の任意のミラーから特定のPythonバージョンをダウンロードできるようになり、ネットワーク制限のある環境や社内ミラーを利用する場面での柔軟性が高まった。また、uv self updateがAstralミラーからuvそのものを取得する仕組みに対応し、更新の信頼性と速度が改善されている。 その他の機能強化としては、pip uninstall -y構文のサポート追加、uv self version --shortでバージョン番号のみを表示するオプションの追加、空のSSL_CERT_DIRディレクトリに対する不要な警告の抑制、exclude-newer-spanが存在する場合にexclude-newerの省略を許容するロックファイル処理の改善などがある。相対的なexclude-newer/exclude-newer-package値に対してはセンチネルタイムスタンプが使用されるようになった。 環境変数と設定の拡充 設定面では、新しい環境変数が3つ追加された。UV_PYTHON_NO_REGISTRYはWindowsレジストリを通じたPythonの自動検出を無効化し、UV_NO_PROJECTはプロジェクトファイルの探索を無効化する。さらにUV_PYTHON_SEARCH_PATHを使うことで、Pythonインタープリタの探索パスをカスタマイズできるようになった。これらの環境変数は、CI環境での動作の予測可能性を高めたい場合や、特定のPythonバイナリを確実に指定したいケースで役立つ。 バグ修正 バグ修正では、uv-buildのソースディストリビューションにrust-toolchain.tomlが含まれていなかった問題が修正された。uvからgitコマンドを呼び出す際にリポジトリの環境変数を引き継いでしまう問題も解消された。また、詳細ログに事前署名済みアップロードURLが平文で表示される問題が修正され、セキュリティが向上している。その他、PEP 517ビルド要件における推移的なURL依存関係の処理の修正、dependency-groupsのみを持つpyproject.tomlでのuv lockの動作改善、パッチバージョン指定時のPython自動アップグレードの無効化なども含まれる。なお、uv-buildのパッケージメタデータにPython 3.14のclassifierが追加され、PyTorchドキュメントもバージョン2.11向けに更新された。

概要 C++向けの高速シリアライズライブラリ「Glaze」がバージョン7.2をリリースし、C++26のP2996リフレクション仕様への対応を正式に取り込んだ。P2996は2025年6月にC++26への採択が決定した標準コンパイル時リフレクション機能で、Glazeはこれを従来の__PRETTY_FUNCTION__解析や構造化バインディングに依存したハックの置き換えとして活用する。JSON、YAML、CBOR、MessagePack、TOMLなど幅広いフォーマットのシリアライズに対応するGlazeにとって、今回のアップデートはコンパイル時メタデータ取得の根本的な刷新となる。 P2996リフレクションで何が変わるか 最も大きな変化は、これまでシリアライズ不可能だった非集約型の自動処理が可能になった点だ。カスタムコンストラクタ・仮想関数・継承を持つクラスは、従来は手動でglz::metaによるメタデータ記述が必要だったが、P2996対応環境ではそれが不要になる。また、従来は構造化バインディングの制約から128メンバーが上限だったが、この制限も撤廃された。 さらに列挙型の自動文字列化にも対応した。これまではglz::metaの手書きが必要だったが、P2996環境ではreflect_enums = trueオプションを有効化することでColor::Greenが"Green"としてシリアライズされる（後方互換性維持のためデフォルトは従来通り整数値）。アクセス修飾子も無視できるため、privateメンバーを含む型も追加設定なしでリフレクション可能となった。内部実装ではstd::meta::nonstatic_data_members_ofとaccess_context::unchecked()を組み合わせて標準APIのみでメンバー情報を取得する。 特性 従来方式 P2996対応 最大メンバー数 128 無制限 非集約型対応 手動記述が必要 自動 列挙型文字列化 glz::meta必須 自動 メンバー名取得 __PRETTY_FUNCTION__解析 標準API 対応コンパイラと有効化方法 現時点でP2996リフレクションを利用するには、GCC 16以降（-std=c++26 -freflection）またはBloomberg clang-p2996（-fexpansion-statements -stdlib=libc++）が必要となる。GCC 16はまもなく正式リリースが予定されている。CMakeではglaze_ENABLE_REFLECTION26オプションをONにするか、コンパイラに-DGLZ_REFLECTION26=1を渡すことで有効化できる。コンパイラが__cpp_lib_reflectionまたは__cpp_impl_reflectionマクロを定義している場合は自動で有効になる。 APIに破壊的変更はなく、既存のglz::metaによるカスタマイズも完全に維持される。ただし一点注意すべき変更として、型名の形式が変わった。従来は"mylib::MyEnum"のように修飾名が出力されていたが、P2996環境では"MyEnum"と非修飾名になる。自動生成されたキー名に依存するコードでは出力形式が変化する可能性があるため、移行時には確認が必要だ。 今後の展望 P2996対応はオプトイン形式であり、標準コンパイラによるビルドには影響しない。GCC 16の正式リリースとともに利用者が増えることが予想され、C++26リフレクションのエコシステム全体における実用的な先行事例となる。Glazeは今回の更新でYAMLの処理改善やストリームリクエストのバッファサイズ設定も取り込んでおり、シリアライズライブラリとしての対応範囲を引き続き拡充している。

概要 Pythonの標準パッケージマネージャーであるpipが2026年4月26日にバージョン26.1をリリースした。最大の目玉は、PEP 751で標準化されたロックファイル形式「pylock.toml」の実験的サポートだ。pip lock datasette llm のようなコマンドで依存関係ツリー全体をTOML形式のロックファイルとして生成できるようになった。例えば datasette と llm の依存関係を解決すると519行の pylock.toml が生成される。このロックファイルは -r / --requirements オプションで通常の要件ファイルと同様に読み込むことができる。開発チームは「実験的機能であり、将来のバージョンで変更・廃止される可能性がある」と明記しており、フィードバックをイシュートラッカーで募っている。 依存関係クールダウン機能（--uploaded-prior-to） 新たに追加された --uploaded-prior-to オプションは「依存関係クールダウン」とも呼ばれ、指定した期間より前にアップロードされたパッケージバージョンのみを解決対象とする機能だ。ISO 8601の期間形式（日数のみ対応）で指定し、たとえば --uploaded-prior-to P4D を指定すると4日以上前にリリースされたバージョンのみが候補となる。これにより、リリース直後のパッケージに含まれる可能性のある不具合を避け、ある程度実績のあるバージョンを優先して取得できる。pip 26.1リリース告知記事の著者であるSimon Willisonは、自身のLLM v0.31（3日前リリース）に対してこのオプションを使用し、意図的により安定したv0.30を取得する実例を紹介している。 その他の変更点 pip 26.1ではPython 3.9のサポートが廃止された。Python 3.9は2025年10月にEOL（サポート終了）を迎えており、今回の廃止はそれに合わせた対応となる。そのほか、ピン留めされていない要件がconstraintsのハッシュを活用できるようになったほか、URLベースのconstraintsがextrasを持つ要件にも適用されるようになるなど、2020年の依存関係リゾルバー刷新以来の長年の制限がいくつか解消された。パフォーマンスとメモリ使用量の改善、バグ修正、セキュリティ改善も含まれている。 今後の展望 pylock.tomlはPoetryやuvといったサードパーティツールが独自形式で提供してきたロックファイル機能をPythonの標準エコシステムに取り込む試みであり、採用が広まればプロジェクト間の再現可能ビルドの互換性が向上することが期待される。実験的フラグが外れて安定化するまでにはさらなるコミュニティフィードバックと仕様の精査が必要となる見込みだ。

概要 JetBrainsは2026年4月23日、IntelliJ IDEA 2026.1.1をリリースした。本バージョンは新機能の追加ではなく、2026.1系における安定性向上とバグ修正に特化したメンテナンスリリースである。WSL（Windows Subsystem for Linux）環境でのPython SDK設定、リモート開発のEmmetサポート、Gradleの同期クラッシュなど、多くの開発者が直面していた問題が解消されている。アップデートはIDE組み込みの更新機能、Toolbox App、Ubuntu Snap、またはJetBrainsの公式サイトからのダウンロードで適用できる。 主な修正内容 開発環境に関連する修正として、WSL上でのPython SDK設定が再び正常に動作するようになった。加えて、WSL 2上にインストールされたJDKをIDEが正しく検出できるようになり、WSLを活用したJava開発のセットアップが改善されている。リモート開発環境ではEmmetのサポートが修正され、HTMLやCSSのコード展開が正常に機能するようになった。 ビルドツールとデプロイ周りでは、InternalIdeaModuleのクラスキャスト問題に起因するGradleの同期クラッシュが修正された。また、WildFlyの管理プロセスへの接続が復元され、デプロイ操作やブラウザ起動オプションが利用可能になった。WebLogicの実行構成の作成も正常化されている。 その他の改善点 Antツールウィンドウでターゲットをダブルクリックした際にビルドが実行されてビルド出力が正しく表示されるよう修正された。「検索と置換」機能でEnterキーが正常に動作するようになったほか、Springプロジェクトにおけるコンテキストアクションの検索とコード補完の応答速度が向上している。特に大規模なSpringプロジェクトでは、検索や補完機能において顕著なパフォーマンス改善が見られるとJetBrainsは報告している。

概要 Git 2.54が2026年4月20日に正式リリースされた。137名のコントリビューター（うち66名が新規）の貢献によるリリースで、目玉機能として設定ファイルでフックを定義できる「Configuration-Based Hooks」と、インタラクティブリベースより手軽にコミット履歴を書き換えられる実験的コマンド git history が追加された。また、Git 2.52で導入された幾何学的再パック（Geometric Repacking）がデフォルト化されるなど、パフォーマンスと利便性の両面で多くの改善が施されている。 Configuration-Based Hooks 従来のGitフックは .git/hooks/ 配下にシェルスクリプトを置く方式のため、複数リポジトリへの展開や共有が難しかった。Git 2.54で導入された Configuration-Based Hooks は、~/.gitconfig などの設定ファイルに直接フックを定義できる仕組みだ。 [hook "linter"] event = pre-commit command = ~/bin/linter --cpp20 この方式では同じイベントに複数のフックを登録でき、git hook list で一覧確認が可能。hook.<name>.enabled = false で個別に無効化もできるため、プロジェクトごとの設定上書きも柔軟に行える。グローバル設定として共有できる点は、チームやマシンをまたいだ開発環境の統一に役立つ。 実験的コマンド「git history」 git history はインタラクティブリベースほどの複雑さを要しないシンプルな履歴書き換えに特化した実験的コマンドだ。現在 reword と split の2つのモードが提供されている。 reword モードは指定コミットのメッセージを編集し、そのコミットから派生する全ブランチを自動更新する。ワーキングツリーやインデックスには一切影響しないため、安全に実行できる。split モードはコミットをインタラクティブに分割でき、取り込む変更をハンク単位で選択できる。ただし、マージコミットを含む履歴は対象外で、マージコンフリクトを引き起こす操作は拒否される点に注意が必要だ。 その他の主な改善点 Geometric Repacking のデフォルト化: Git 2.52で導入された幾何学的再パック戦略が今回からデフォルトになった。全体 repack の代わりに段階的統合を実施することで、大規模リポジトリのメンテナンスコストが軽減される。 HTTP 429 への自動対応: レート制限（HTTP 429）を受けた際に Retry-After ヘッダーを解釈して自動リトライする機能が追加された。大量のリモート操作を行う環境での信頼性が向上する。 その他にも、git add -p でのハンク選択状況の可視化、git log -L と pickaxe 検索（-S/-G）の組み合わせ対応、git rebase --trailer による全 rebase 済みコミットへのトレーラー自動付与、git blame --diff-algorithm による差分アルゴリズムの選択、git alias での ASCII 以外の文字サポートなど、日常的なワークフローを改善する多数の機能追加・修正が含まれている。内部的にはオブジェクトデータベース（ODB）がプラガブルバックエンド設計に移行しており、将来の拡張性が高まっている。