訳者 はじめに
Michael Thomsenさんによる「Announcing Dart 3.5, and an update on the Dart roadmap」(原文)の日本語訳です。勝手に訳して、後から許可を取ります(笑)
本編
四半期ごとのDart SDKリリースの時期がやってきました。今回は、相互運用性の向上、pub.devパッケージマネージャーの新機能、そして新しいWeb統合APIの安定版およびバージョン1.0への移行が含まれています。
私たちの時間の大部分は、より大規模で複数四半期にわたる取り組みに割かれているため、Dartのロードマップの更新も行い、今後の四半期に進展させたい内容の詳細をお伝えする。
Dart 3.5の新機能
Dart 3.5には、以下に詳述する新機能がいくつか含まれています。また、コアライブラリAPIに対する少数の変更や、約10件の非常に軽微な破壊的変更もあります。これらの詳細については変更ログで確認できます。
WebプラットフォームとJS相互運用性
インターロップ: 相互運用性
Dart 3.5の新機能
Dart 3.4およびFlutter 3.22で、Flutter WebアプリのWebAssemblyへのコンパイルのサポートが導入されました。WebAssemblyへのコンパイルには、新しいDart to JSインターロップモデルの使用が必要です。以前はプレビュー版でしたが、Dart 3.5ではこれが安定版および完成版とされました。また、package:webのブラウザAPIバインディングが更新され、バージョン1.0となりました。このパッケージは従来のdart:htmlライブラリに代わるものです。
すべてのウェブパッケージの作者に対し、package:webへの移行を奨励します。次のDartリリースで古いインターロップAPI（dart:html、dart:js、package:jsなど）を非推奨にし、来年以降に完全に廃止する予定です。この計画に関するフィードバックをトラッキングイシューで提供するようお願いします。また、pub.devパッケージマネージャーのスコアリングを更新し、新しいインターロップモデルをサポートするウェブパッケージにポイントを付与する予定です。
また、新しいlintが追加され、コードが新しいJSインターロップタイプを正しく使用していることを検証します。ウェブパッケージを移行する際には、このlintをanalysis_options.yamlファイルに追加することをお勧めします。
Dartネイティブ相互運用性
また、Dart から C、Java、Kotlin、Objective-C、Swift への直接呼び出しをサポートするネイティブ相互運用性についても、さまざまな改善を行いました。
C との相互運用は、FFI (Foreign Function Interface) ライブラリによって実現されています。Dart 3.5では、DartのTypedDataオブジェクトからFFIに直接ポインタを渡すことができるように改良され、DartからNativeにメモリをコピーする必要がなくなりました(details)。
JavaとKotlinの相互運用は、JNIgenジェネレーター（現在プレビュー中）によって可能になります。このジェネレーターは、DartからJava Native Interface（JNI）を経由してJavaとKotlinに呼び出すためのバインディングコードの作成を自動化します。パフォーマンスを改善し、Java例外とKotlinトップレベル関数のサポートを追加しました。また、以前のCベースのバインディングは廃止しました。代替のDartのみのバインディングは同等のパフォーマンスと機能を持ち、より使いやすくなっています。詳細は変更履歴をご覧ください。
Objective-C interopはFFIと私たちのFFIgenジェネレータ(現在プレビュー中)の上に構築されます。Objective-Cのプロトコルや、NSStringのような一般的な型のサポートを追加しました。FFIgen を使ってビルドされたパッケージの大きな例として、Apple の URL Loading System ネットワーキングライブラリと相互運用する cupertino_http を参照してください。
上記のライブラリを完成させるという意味でも、Swift をサポートするという意味でも、私たちは今後のリリースに向けてさらなる相互運用性への投資を続けていきます。詳細は以下のロードマップのセクションをご覧ください。
Pub.devパッケージリポジトリ
Pub.devは、コミュニティが機能豊富なパッケージを共有し、見つけることができるパッケージリポジトリです。ここで多くの改善を行いました。まず、パッケージの著者が所属するカテゴリ（例：ウィジェット）でパッケージにタグを付けるメカニズムであるトピックのサポートを改良しました。同じカテゴリをカバーするが表現がわずかに異なる一般的なトピック（例：widgets vs widget）を統合しました。
次に、新しいpub unpackコマンドを追加しました。これにより、パッケージをファイルシステムにダウンロードする簡単で迅速な方法が提供されます。例えば、ローカルマシンでパッケージのサンプルプログラムを実行したい場合に使用できます。
$ dart pub unpack path
Downloading path 1.9.0 to `./path-1.9.0`...
$ cd path-1.9.0/example/
$ dart run example.dart
Current path style: posix
Current process path: /Users/mit/tmp/path-1.9.0/example
最後に、新しいpub downgrade --tightenコマンドを追加しました。これは、パッケージの依存関係のすべてのバージョン制約をチェックするために使用できます。このコマンドを実行すると、pubが解決可能な最低バージョンに下限制約を更新します。
Dartロードマップの更新
上記の完了した機能に加えて、長期的なロードマップに向けた進展を達成するために、さまざまな分野で作業を行いました。
大規模モノレポにおけるIDEおよびアナライザーのパフォーマンス
「モノレポ」は、関連する一連のパッケージとアプリのソースコードを単一のリポジトリに構造化する一般的な方法です。例えば、Flutterのpackagesリポジトリがその一例です。モノレポは単にすべてのソースコードを「近くに」置く利便性だけでなく、リポジトリ内の個々のパッケージやアプリが互いに互換性があることを確認するための重要なツールでもあります。
大規模なモノレポで作業する開発者からのフィードバックでは、ツールのパフォーマンス、特にアナライザーのパフォーマンスが不足していると一貫して聞いています。これらの問題の分析によると、根本的な問題は、各パッケージおよびそのすべての依存関係に対して複数の重複する分析コンテキストをロードし、メモリ内に各パッケージの複数のコピーが存在することにあります。私たちは、この問題の根本的な解決策は、これらのリポジトリ内の各依存関係のバージョンの単一の共有解決を作成することだと考えており、この機能を新しいpub機能であるワークスペースを通じて実現するために取り組んでいます。この詳細については、次のDartリリースでさらに共有しますが、現時点では、これがどのようにFlutterエンジンリポジトリに最近適用されたかを確認できます。
Pub.devパッケージリポジトリ
Pub.devパッケージリポジトリのユーザーは、各パッケージがどれだけ使用され、ダウンロードされたかに関する改善されたメトリクスを長らく要求していました。これは、パッケージの著者にとっては、彼らの作業からどれだけ多くのユーザーが利益を得ているかのシグナルとして、パッケージの消費者にとっては、他の開発者がどのパッケージを消費しているかのシグナルとして役立ちます。この機能に関しては順調に進んでおり、年末までにプレビュー版を提供できることを期待しています。
Dartネイティブ相互運用
JNIgenを使用したJavaとKotlinのインターオペについては、次の2四半期でコアサポートを完了し、実験的なものから安定版1.0に移行する予定です。詳細はJNIgenトラッカーを参照してください。Objective-Cのインターオペについても同様の目標を持っています。詳細はObjective-Cトラッカーを参照してください。
次に、Swiftコードとの直接インターオペを調査しています。初期の実験は有望であり、来年の初めには実験的なサポートを追加することを期待しています。
ネイティブの相互運用とネイティブソースコードのバンドル
多くの場合、直接相互運用はオペレーティング・システムに存在するAPIを呼び出すために使用されます。しかし、Dartが相互運用するコードが、ホストに直接含まれていないネイティブのソースコードである場合もあり、このような相互運用を使用するパッケージ作者にとっては現実的な課題となります： このような相互運用を使用するパッケージ作成者には、次のような現実的な課題があります。パッケージの消費者に多くの手動手順を押し付けることなく、ネイティブのソースコードをバンドルしてビルドするにはどうすればよいでしょうか？これをサポートするために、ネイティブアセットシステムを検討しており、ネイティブソースコードを含むDartパッケージの公開、およびそのソースコードのビルドとバンドルを自動化するための標準化されたプロトコルをサポートします。これにより、新しい一連の相互運用性のユースケースが可能になると同時に、ネイティブのソースコードに依存するパッケージを使用する開発者に、シンプルなユーザーエクスペリエンスを提供できると考えています。
Dart言語とマクロ
Dart言語とコンパイラのチームは現在、大規模な言語機能であるマクロの進展に多くの時間を費やしています。この機能はDart 3.4のブログ投稿で紹介しました。当時述べたように、これは非常に大きな取り組みであり、ホットリロードなどの主要なユースケースでリグレッションを引き起こす可能性があるため、徹底的なアプローチを取っています。次のステップの詳細を共有する前に、さらに数四半期の作業が必要になると考えています。
マクロに加えて、他のいくつかの小さな言語機能も同時に検討しています。これについては、Dart言語ファネルに記載されています。
昨年秋から、Dartフォーマッタの書き直しを行っています。旧設計は長年にわたりうまく機能していましたが、Flutterの成功に伴い、Flutterユーザーがよく書く宣言的なコードにより適した新しいスタイルに移行したいと考えています。旧フォーマッタはそのような出力を生成することができませんでした。書き直しはほぼ完了しており、近日中に出荷される予定です。試してみたい場合は、実験フラグtall-styleを使用してください（フラグの指示）。奇妙な出力が見られた場合は、フィードバックを歓迎します。
終わりに
本日はここまでです。ロードマップ項目およびDart 3.5の新機能についてのフィードバックを歓迎します。Dart 3.5はDart.devまたは本日のFlutter 3.24リリースにバンドルされています。
