A medida que Bazel continúa evolucionando en respuesta a tus necesidades, queremos compartir la actualización de nuestra planificación para 2025.
Tenemos previsto ofrecerte la asistencia a largo plazo (LTS) de Bazel 9.0 a fines de 2025.
Transición completa a Bzlmod
Bzlmod ha sido el sistema de dependencias externas estándar en Bazel desde Bazel 7, y reemplazó el sistema WORKSPACE heredado. A partir de marzo de 2025, el Bazel Central Registry aloja más de 650 módulos.
Con Bazel 9, quitaremos por completo la funcionalidad de WORKSPACE, y Bzlmod será la única forma de introducir dependencias externas en Bazel. Para minimizar el costo de migración para la comunidad, nos enfocaremos en mejorar aún más nuestra guía y herramienta de migración.
Además, nuestro objetivo es implementar una caché de repositorio compartido mejorada (consulta #12227) con la recolección de elementos no utilizados y, posiblemente, realizar una adaptación para versiones anteriores a Bazel 8. Bazel Central Registry también admitirá la verificación de las certificaciones de SLSA.
Migración de reglas de Android, C++, Java, Python y Proto
Con Bazel 8, migramos la compatibilidad con las reglas de Android, Java, Python y Proto desde la base de código de Bazel a las reglas de Starlark en sus repositorios correspondientes. Para facilitar la migración, implementamos las funciones de carga automática en Bazel, que se pueden controlar con --incompatible_autoload_externally y --incompatible_disable_autoloads_in_main_repo marcas.
Con Bazel 9, nuestro objetivo es inhabilitar las cargas automáticas de forma predeterminada y requerir que cada proyecto cargue explícitamente las reglas necesarias en los archivos BUILD.
Volveremos a escribir la mayor parte de la compatibilidad con el lenguaje C++ en Starlark, la separaremos del objeto binario de Bazel y la moveremos al /rules_cc repositorio. Esta es la última compatibilidad con lenguajes principales que aún forma parte de Bazel.
También estamos transfiriendo pruebas unitarias para las reglas de C++, Java y Proto a Starlark, y las movemos a repositorios junto a la implementación para aumentar la velocidad de los autores de reglas.
Mejoras de Starlark
Bazel tendrá la capacidad de evaluar macros simbólicas de forma diferida. Esto significa que una macro simbólica no se ejecutará si no se solicitan los objetivos que declara, lo que mejora el rendimiento de los paquetes muy grandes.
Starlark tendrá un sistema de tipos experimental, similar a las anotaciones de tipo de Python. Esperamos que el sistema de tipos se estabilice después del lanzamiento de Bazel 9.
Configurabilidad
Nuestro objetivo principal es reducir el costo y la confusión de las marcas de compilación.
Estamos experimentando con un
nuevo modelo de configuración de proyectos que no obliga a los usuarios a saber qué marcas de compilación
y prueba configurar y dónde. Por lo tanto, $ bazel test //foo establece automáticamente las
marcas correctas según la política del proyecto de foo. Es probable que esto siga siendo experimental en la versión 9.0, pero se agradecen los comentarios orientativos.
El alcance de las marcas te permite quitar las marcas de Starlark cuando salen de los límites del proyecto, de modo que no interrumpan el almacenamiento en caché en dependencias transitivas que no las necesiten. Esto hace que las compilaciones que usan transiciones sean más económicas y rápidas. Este es un ejemplo. Estamos ampliando la idea para controlar qué marcas se propagan a las configuraciones de ejecución y estamos considerando una compatibilidad aún más flexible, como Starlark personalizado, para determinar qué bordes de dependencia deben propagar marcas.
Estamos priorizando el esfuerzo para quitar las marcas de lenguaje integradas de Bazel y pasarlas a Starlark, donde pueden vivir con las definiciones de reglas relacionadas.
Mejoras de la ejecución remota
Tenemos previsto agregar compatibilidad con la ejecución asíncrona, lo que acelerará la ejecución remota mediante el aumento del paralelismo.
Para seguir las actualizaciones de la planificación y analizar las funciones planificadas, únete al servidor de Slack de la comunidad en slack.bazel.build.
El objetivo de esta planificación es informar a la comunidad sobre las intenciones del equipo para Bazel 9.0. Las prioridades están sujetas a cambios en respuesta a los comentarios de los desarrolladores y clientes, o a nuevas oportunidades de mercado.