Anunciando Dart 3.5, y una actualización sobre la hoja de ruta de Dart

Es momento de otro de nuestros releases trimestrales del SDK de Dart. Tenemos mejoras en interoperabilidad, nuevas características en nuestro gestor de paquetes pub.dev, y hemos graduado nuestras nuevas APIs de integración web a estable y versión 1.0.

Una gran parte de nuestro tiempo se ha dedicado a esfuerzos más grandes, de múltiples trimestres, así que con eso también tenemos una actualización de nuestra hoja de ruta de Dart, con detalles sobre en qué esperamos progresar en los próximos trimestres.

Dart 3.5 incluye varias capacidades nuevas que se detallan a continuación. También hay un número menor de cambios en las APIs de las librerías principales, y alrededor de 10 breaking changes muy menores, cubiertos en el changelog.

En Dart 3.4 y Flutter 3.22 introdujimos soporte para compilar apps de Flutter Web a WebAssembly. La compilación a WebAssembly requiere usar nuestro nuevo modelo de interop de Dart a JS, que anteriormente estaba en preview. A partir de Dart 3.5 ahora se considera estable y completo, y hemos actualizado los bindings de las APIs del navegador en package:web (que reemplaza la librería anterior dart:html ) a la versión 1.0.

Nos gustaría animar a todos los autores de paquetes web a migrar a package:web. Planeamos deprecar las APIs de interop antiguas (dart:html, dart:js, package:js, etc.) en nuestro próximo release de Dart, y discontinuarlas por completo el próximo año. Te invitamos a dar feedback sobre este plan en el issue de seguimiento. También planeamos actualizar la puntuación en el gestor de paquetes pub.dev para otorgar puntos a los paquetes web que soporten el nuevo modelo de interop.

También hemos añadido un nuevo lint, que valida que tu código use los nuevos tipos de JS interop correctamente. Recomendamos que añadas este lint a tu archivo analysis_options.yaml como parte de la migración de tus paquetes web.

También hemos hecho una serie de mejoras a nuestra interoperabilidad nativa, que soporta llamadas directas desde Dart a C, Java, Kotlin, Objective-C, y Swift.

El interop con C está habilitado por nuestra librería FFI (Foreign Function Interface), que hemos soportado durante varios años. En Dart 3.5, hemos hecho mejoras incrementales para soportar pasar un puntero desde objetos TypedData de Dart directamente a FFI, evitando tener que copiar primero la memoria de Dart a Native (detalles).

El interop con Java y Kotlin está habilitado por el generador JNIgen (actualmente en preview), que automatiza la creación del código de bindings para llamar desde Dart a Java y Kotlin a través de Java Native Interface (JNI). Hemos mejorado el rendimiento y añadido soporte para excepciones de Java y funciones top-level de Kotlin. También hemos discontinuado los anteriores bindings basados en C, ya que los bindings alternativos solo en Dart ahora tienen rendimiento y características comparables, y son mucho más fáciles de usar. Para más detalles, consulta el changelog.

El interop con Objective-C se basa en FFI y nuestro generador FFIgen (actualmente en preview). Hemos añadido soporte para protocolos de Objective-C, y tipos comunes como NSString. Para un ejemplo grande de un paquete construido con FFIgen, consulta cupertino_http que interopera con la librería de networking URL Loading System de Apple.

Continuaremos invirtiendo en mayor interoperabilidad — tanto en completar las librerías mencionadas arriba, como en soportar Swift — en los próximos releases. Consulta la sección de hoja de ruta abajo para más detalles.

Pub.dev es nuestro repositorio de paquetes donde la comunidad puede compartir y encontrar paquetes con una gran cantidad de funcionalidades. Hemos hecho varias mejoras aquí. Primero, hemos refinado el soporte para topics: el mecanismo mediante el cual los autores de paquetes pueden etiquetar sus paquetes con la categoría a la que pertenecen (como widget). Ahora consolidamos los topics comunes que cubren la misma categoría pero usan ligeras variaciones en su redacción (por ejemplo widgets vs widget).

Segundo, hemos añadido un nuevo comando pub unpack. Este ofrece una forma rápida y fácil de descargar un paquete a tu sistema de archivos. Esto puede usarse, por ejemplo, si quieres ejecutar el programa de ejemplo de un paquete en tu máquina local:

$ 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

Tercero, hemos añadido un nuevo comando pub downgrade --tighten. Este puede usarse para verificar todas las restricciones de versión en las dependencias de un paquete. Al ejecutarse, actualiza la restricción inferior a la versión más baja para la cual pub pudo hacer una resolución.

Además de las características completadas arriba, también hemos trabajado en varias áreas para progresar en nuestra hoja de ruta a largo plazo.

Un 'monorepo' es una forma común de estructurar el código fuente de un conjunto de paquetes y apps relacionados en un único repositorio, por ejemplo como en el repositorio de packages de Flutter. Un monorepo no se trata solo de la conveniencia de tener todo el código fuente "junto", sino que también puede ser una herramienta crítica para asegurar que los paquetes y apps individuales del repo sean mutuamente compatibles.

Hemos recibido feedback consistente de desarrolladores que trabajan en monorepos grandes, de que el rendimiento de nuestras herramientas, y específicamente del analyzer, puede ser insuficiente. Nuestro análisis de estos problemas sugiere que el problema raíz es que terminamos cargando múltiples contextos de análisis superpuestos para cada paquete y TODAS sus dependencias, llevando a varias copias del análisis de cada paquete en el monorepo en memoria al mismo tiempo. Creemos que la solución fundamental es crear una única resolución compartida de las versiones de cada dependencia en tales repos, y estamos trabajando en esa capacidad a través de una nueva característica de pub llamada workspaces. Tendremos mucho más que compartir sobre esto en nuestro próximo release de Dart, pero por ahora puedes ver cómo esto fue aplicado recientemente al repositorio del motor de Flutter.

Los usuarios del repositorio de paquetes pub.dev han solicitado durante mucho tiempo métricas mejoradas sobre cuánto se usa/descarga cada paquete. Esto puede ser útil tanto para los autores de paquetes como señal de cuántos usuarios se benefician de su trabajo, y para los consumidores de paquetes como señal de qué paquetes están consumiendo otros desarrolladores. Estamos felices de compartir que estamos haciendo buen progreso en esta capacidad, y esperamos tenerla en preview para fin de año.

Para el interop con Java y Kotlin con JNIgen, esperamos finalizar el soporte principal y graduar de experimental a una versión estable 1.0 en los próximos dos trimestres. Para más detalles, consulta el tracker de JNIgen. Para el interop con ObjectiveC, tenemos un objetivo similar; consulta el tracker de Objective-C.

A continuación estamos investigando el interop directo con código Swift. La experimentación inicial luce prometedora, y esperamos tener soporte experimental añadido a principios del próximo año.

En muchos casos el interop directo se usa para llamar a APIs que están presentes en el sistema operativo, lo que significa que las APIs siempre están disponibles en esas plataformas host. Sin embargo, en algunos casos el código con el que Dart está interoperando es código fuente nativo no incluido directamente en el host, lo que presenta un desafío práctico para los autores de paquetes que usan tal interop: ¿Cómo haces que ese código fuente nativo se incluya y compile sin tener que imponer un montón de pasos manuales a los consumidores del paquete? Para soportar esto, estamos explorando un sistema de native assets, que podría soportar la publicación de paquetes Dart que contienen código fuente nativo, junto con un protocolo estandarizado para permitir que las herramientas CLI dart y flutter automaticen la compilación y el empaquetado de ese código fuente. Envisionamos que esto habilitará un nuevo conjunto de casos de uso de interoperabilidad, al mismo tiempo que ofrece una experiencia de usuario sencilla para los desarrolladores que usan paquetes que dependen de código fuente nativo.

La mayor parte de nuestro tiempo en los equipos de lenguaje y compilador de Dart se dedica actualmente a progresar en la gran característica del lenguaje macros, que introdujimos en el post del blog de Dart 3.4. Como dijimos en ese momento, esto es una empresa enorme, con el potencial de causar regresiones en algunos de nuestros casos de uso principales como hot reload, por lo que estamos tomando un enfoque exhaustivo, y probablemente necesitemos varios trimestres más de trabajo antes de poder compartir detalles del siguiente paso.

Además de las macros, también estamos explorando concurrentemente varias otras características de lenguaje menores, como se documenta en el funnel del lenguaje Dart.

Desde el otoño pasado, hemos estado reescribiendo el formateador de Dart. El diseño anterior funcionó bien durante muchos años, pero con el éxito de Flutter, queremos pasar a un nuevo estilo que funcione mejor para el tipo de código declarativo que los usuarios de Flutter suelen escribir. El formateador anterior no podía producir ese tipo de salida. La reescritura está casi terminada y se lanzará pronto. Si quieres probarlo, pasa el flag experimental tall-style (instrucciones del flag). Agradecemos tu feedback si ves resultados extraños.

Eso es todo por hoy. Agradecemos tu feedback, tanto sobre los elementos de la hoja de ruta discutidos, como sobre las nuevas características de Dart 3.5, disponible desde Dart.dev o incluido en el release de Flutter 3.24 de hoy.