Saltar al contenido principal

Hoja de ruta de Babel

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Este documento describe algunas de las mejoras que nuestro equipo desea implementar durante este año.

No es una lista exhaustiva de todas las nuevas características o cambios importantes que traeremos a Babel, pero es un buen resumen si te interesa la dirección general del proyecto. Es posible que no completemos todos los puntos enumerados o que pospongamos algunos hasta el próximo año. Algunos tienen puntos de inicio y fin claros, mientras que otros requieren más investigación o RFCs.

Si tu empresa está interesada y desea patrocinar directamente algún elemento específico, ¡contáctanos!

Hoja de ruta de Babel 2021​

Babel 8​

¡Llevamos más de un año hablando sobre el lanzamiento de Babel 8 (inicialmente lo programamos hace aproximadamente un año)! Sin embargo, ¡ahora estamos más cerca que nunca de su lanzamiento!

La mayoría de las tareas pendientes están en el issue de seguimiento, pero aún hay algunos obstáculos:

  • Queremos eliminar el soporte para Node.js 10, cuyo mantenimiento finaliza el 2021-04-30.

  • Queremos publicar Babel como un paquete puramente ESM. Actualmente estamos convirtiendo nuestras fuentes para que sean compatibles con la implementación ESM de Node.js, y durante este proceso estamos analizando cómo facilitar su uso a quienes actualmente emplean Babel para compilar ESM a CJS.

  • Estamos alineando nuestro AST de TypeScript con el proyecto typescript-eslint. Nuestros AST son casi idénticos, pero necesitamos introducir algunos cambios disruptivos menores para alinearlos completamente.

  • Nuestra infraestructura de lanzamientos aún no admite versiones preliminares ni múltiples ramas "main" (una para Babel 8 y otra para Babel 7).

  • Aún no hemos definido una política de mantenimiento para Babel 7.

Implementar nuevas propuestas de TC39​

Babel actualmente puede analizar todas las propuestas en Etapa 3, y transformar todas excepto top-level await, import assertions y módulos JSON (mejor manejados por bundlers que trabajan con el gráfico de dependencias).

Admitimos todas las propuestas en Etapa 2 excepto:

  • La nueva iteración de la propuesta de decoradores (necesitamos implementar tanto análisis como transformación);

  • Transformación para la propuesta de Module Blocks (implementamos el análisis en Babel 7.13.0).

Implementaremos soporte para decoradores e investigaremos si y cómo podemos implementar una transformación para module blocks.

Aunque no admitimos muchas propuestas en Etapa 1, ha habido actualizaciones recientes en el operador pipeline y do expressions. Dado que ya admitimos estas propuestas y la comunidad está muy entusiasmada con ellas, actualizaremos nuestras implementaciones.

También hay otras propuestas (como pattern matching) que aún no hemos implementado porque sus impulsores prevén cambios significativos en sintaxis y semántica. Sin embargo, seguimos de cerca su desarrollo y las implementaremos en Babel tan pronto se estabilicen un poco.

Integrar @babel/preset-env en @babel/core​

Una configuración mínima de transformación de Babel requiere al menos tres paquetes:

  • @babel/core

  • @babel/preset-env

  • un "ejecutor" de Babel (@babel/cli, babel-loader, @rollup/plugin-babel, etc.)

Integrar @babel/preset-env directamente en @babel/core ofrece dos grandes ventajas:

  • Facilitará la configuración de Babel en proyectos simples, solo necesitarás habilitar la opción compileJS: true en babel.config.json (o incluso podría ser el valor predeterminado en el futuro—no puede serlo ahora porque @babel/eslint-parser no compila el código fuente)

  • Garantizará que las versiones de los plugins estén sincronizadas con la versión de @babel/core, evitando la mayoría de errores causados por versiones de paquetes incompatibles

  • Al migrar a ESM, será difícil resolver y cargar plugins de forma síncrona en transformSync. Esto previene ese problema.

Ya existe un RFC para mover los plugins de características estables de ECMAScript a @babel/core, que es el primer paso en esta dirección.

Con nuestra arquitectura actual de @babel/preset-env, necesitaríamos manejar especialmente los plugins oficiales para habilitarlos o deshabilitarlos automáticamente según los targets. Sin embargo, esto tiene dos desventajas:

  • Los datos de compatibilidad para un plugin específico están completamente separados de su implementación (ni siquiera es una dependencia, sino algo como una dependencia implícita interna: plugin -> @babel/core -> @babel/compat-data);

  • Los plugins oficiales recibirían un trato especial de @babel/core, pero queremos asegurar que los plugins de terceros tengan las mismas capacidades que los oficiales.

Continuar desarrollando el proyecto babel-polyfills​

Ya decidimos eliminar la compatibilidad con core-js@2 de @babel/preset-env en Babel 8. También queremos dejar de promover un polyfill de terceros específico, lo que podría dar a nuestros usuarios la impresión de que es parte de Babel.

Esto podría ocurrir de dos maneras diferentes:

  • Simplemente eliminamos core-js@3 de @babel/preset-env en Babel 8, animando a los usuarios a migrar a babel-plugin-polyfill-corejs3 (que es lo que @babel/preset-env usa internamente desde la versión 7.10.0)

  • Podemos mantener la compatibilidad con core-js@3 en @babel/preset-env, pero no migrarla a @babel/core cuando movamos los plugins de transformación.

Cualquiera que sea el camino, nos gustaría ofrecer al menos una alternativa a nuestros usuarios cuando necesiten actualizar la integración de core-js en su configuración. core-js es un polyfill excelente que garantiza el máximo cumplimiento de especificaciones, pero los usuarios pueden preferir diferentes compensaciones.

(Nicolò) está trabajando con @ljharb para asegurar que el proyecto @es-shims admita al menos todas las características ES2015+ (en realidad apuntamos a ES5+), para que los usuarios de Babel puedan elegir libremente entre al menos dos opciones.

Esto debe ocurrir antes de eliminar la compatibilidad integrada con core-js@3, para que las personas interesadas en es-shims no tengan que migrar dos veces.

Ampliar el uso de targets para transformaciones granulares​

Desde el principio, @babel/preset-env ha usado la opción targets para habilitar o deshabilitar automáticamente plugins de transformación.

Sin embargo, no existe una correspondencia 1 a 1 entre los plugins de Babel y las características implementadas en navegadores.

Por ejemplo, tenemos un único plugin para los diferentes tipos de campos de clase (públicos y privados, estáticos y de instancia), pero los navegadores tienen matrices de compatibilidad variables:

  • Firefox 73 y Safari 14 solo admiten campos de instancia públicos

  • Firefox 75+ admite campos públicos de instancia y estáticos

  • Chrome 79+ admite campos públicos y privados, pero no admite campos privados en algunas expresiones de encadenamiento opcional

  • Chrome 84+ admite completamente campos privados, y también métodos privados

  • Safari TP 121 soporta completamente campos privados (incluso con ?.), pero no admite métodos privados

Crear un plugin para cada característica es subóptimo. Por ejemplo, podemos convertir métodos privados en campos privados y luego, si es necesario, transformarlos a sintaxis antigua. Sin embargo, podemos generar resultados mejores/optimizados al convertir directamente métodos privados a sintaxis antigua sin el paso intermedio, cuando sabemos que se necesita transpilar.

Desde Babel 7.13.0, podemos leer la opción targets directamente dentro de un plugin, lo que nos permite modificar nuestros plugins para realizar automáticamente una compilación parcial de una característica ECMAScript específica, brindando ventajas en tamaño de salida y rendimiento en tiempo de ejecución.

Antecedentes

Este enfoque no es completamente nuevo. Gracias a una colaboración con @_developit, en Babel 7.9.0 introdujimos la opción bugfixes: true para @babel/preset-env. Cuando esta opción está habilitada y se usa esmodules: true como objetivo de compilación, solo compilamos parcialmente algunas características. Esto nos hizo considerar inicialmente esta posibilidad, pero las transformaciones parciales actuales son menos útiles con objetivos más modernos (por ejemplo, defaults, not ie 11).

También usamos la opción targets para decidir si podemos emplear Object.assign al compilar el operador de propagación de objetos.

Puntos de Acción

Este objetivo se puede dividir en dos grandes tareas realizables en paralelo:

  • Identificar dónde estas optimizaciones son útiles recolectando consultas browserslist del mundo real y simulando cómo evolucionarán consultas populares (por ejemplo, defaults o >2%, not dead)

  • Implementar realmente las optimizaciones necesarias, asegurando compatibilidad con otros plugins (dado que aumentarían considerablemente las posibles combinaciones de transformaciones)

Investigar nuevas assumptions del compilador​

En Babel 7.13.0 introdujimos una nueva opción global assumptions para formalizar lo que hace el modo loose y ofrecer control más granular a los usuarios (quienes a menudo solo pueden habilitar algunas suposiciones)

Sin embargo, solo incluimos opciones para suposiciones que ya aplicábamos en modo loose. Ahora podemos investigar qué nuevas suposiciones podrían necesitar nuestros usuarios

Ya existen propuestas como:

  • #8222 - asumir que todos los imports ESM son inmutables, evitando código para enlaces en vivo

  • #11356 - asumir que las clases compiladas no extienden clases nativas, evitando el costo de rendimiento al instanciar clases potencialmente nativas

Podemos determinar qué nuevas suposiciones implementar mediante:

  • Verificación manual de características que compilamos a resultados "no obvios", causados por casos límite que a muchos desarrolladores no les importan

  • Retroalimentación comunitaria, donde desarrolladores prueben qué suposiciones funcionan en sus aplicaciones

Renovar el Babel REPL​

El Babel REPL es un entorno práctico para aprender cómo Babel transpila código fuente

Limitaciones actuales:

Características deseables:

  • AST Explorer (integrarlo con el existente)

  • stderr con seguimiento de pila completo como registro de errores

  • stdout como salida

  • Cambiar versión de Babel desde la interfaz

Al menos el 15% de los issues abiertos en babel-website están relacionados con el REPL: https://github.com/babel/website/issues?q=is%3Aissue+is%3Aopen+label%3Arepl

Herramientas Educativas/Depuración​

Relacionado con el REPL/ASTExplorer, podríamos desarrollar más herramientas para ayudar en el desarrollo de plugins tanto para nosotros como para terceros. Esto es más bien exploratorio: diferentes visualizaciones del propio AST, depuración, etc.

Algunos trabajos en los que Henry ha estado trabajando intermitentemente:

  • Un Codesandbox para crear plugins simples de Babel, similar a https://astexplorer.net pero con configuraciones personalizadas.

  • Visualización del mapeo entrada-salida para entender cómo Babel transforma el código. Útil incluso para documentación al familiarizar usuarios con nueva sintaxis o demostraciones específicas.

  • Mapeo entrada-salida similar a estructuras sourcemap. Permite mapeo inverso para identificar qué plugin generó cierto código, ayudando en depuración.

Para un ejemplo interactivo de lo que estamos considerando: https://babel-explorer.netlify.app/ (¡haz clic y mantén presionado en el sector inferior!)