Saltar al contenido principal

El Estado de Babel

· 27 min de lectura
Henry Zhu
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 →

Incidencias anteriores: Hoja de ruta de Babel #4130, 6.0 #2168

Por favor, consulta la sección de Comunidad como mínimo.

¡También publicado como parte del Calendario de Adviento Web 2016 de Mariko Kosaka!

Un poco de historia​

Sebastian creó "6to5" en septiembre de 2014. Curiosamente, lo hizo para satisfacer una necesidad personal de entender cómo funcionan los lenguajes de programación. Podrías haber asumido que quien creó el proyecto ya sabía cómo funcionaban los compiladores y entendía JavaScript perfectamente... ¡pero te equivocarías! Lee su publicación para conocer su historia: ~2015 en retrospectiva.

6to5 hacía exactamente eso: convertir fácilmente código ES6 a ES5. Cuando 6to5 se convirtió en Babel como se menciona en Not Born to Die, se transformó en una plataforma: un conjunto de herramientas diseñadas para crear la próxima generación de utilidades JavaScript. Ya no solo compilaba ES6 a ES5, sino que permitía a los desarrolladores construir herramientas sobre él.

Estos son algunos de nuestros hitos:

  • En 5.0.0, Babel se alineó más con el proceso TC39 al introducir stages, añadir la opción de configuración .babelrc y crear un sistema de plugins para transformaciones personalizadas.

  • En 6.0.0, Babel se volvió modular (una idea bastante controvertida en su momento). Este fue un cambio radical que llevó a funcionalidad opcional (sin valores predeterminados) y al concepto de Presets y Opciones de Plugin.

    • Como se menciona en su artículo, Sebastian se unió a Facebook en julio de 2015 y trabajó en todo el desarrollo de Babel 6 en horario laboral.

  • En 6.3.13, Sebastian extrajo nuestras herramientas de construcción/publicación de monorepo en lo que ahora es Lerna. (Lo curioso es que James lo reescribió 3 veces y tuve que revisarlo todo).

    • Después de esto, tanto Sebastian como James sufrieron desgaste con Babel, y algunos colaboradores asumieron el liderazgo.
    • Tuvimos dificultades para encontrar dirección y manejar los errores/solicitudes entrantes, ¡pero logramos hacer muchas cosas!

  • 6.13.0 finalmente añadió Preset Options.

  • 6.14.0 añadió un latest-preset que se mantiene al día con la especificación anual de JavaScript.

  • 6.16.0 permitió cambiar el parser o el generador de código.

  • En agosto, lanzamos Babili, un minificador basado en Babel.

  • En septiembre, lanzamos la primera versión de babel-preset-env (sigue leyendo para más detalles).

  • Después de un año en Phabricator, volvimos a GitHub issues gracias únicamente a @danez y su increíble (y poco apreciado) trabajo.

Si estás usando Babel, ¡haznos saber con una PR en nuestra página de usuarios!

Actualmente babel-core se descarga más de 5 millones de veces al mes y casi 60 millones de veces en total, y se utiliza en grandes empresas como Facebook/Netflix/Airbnb y otros proyectos de código abierto como React/Yarn.

¡Gracias a todos por su continuo apoyo! Queremos seguir siendo la base de la cadena de herramientas de JavaScript: compilación, linting, minificación, codemods, cobertura de código, etc.

Estado actual​

Si estás interesado en ayudar, ¡por favor, revisa los issues enlazados a continuación!

Mantener los plugins de Babel para cada propuesta en TC39 a partir de la Etapa 0​

TC39 es la sigla de Ecma International, Comité Técnico 39: es el comité que crea JavaScript.

Babel utiliza el concepto de etapas de TC39 para categorizar sus plugins experimentales. Los usuarios deberían poder usar fácilmente características antes de que sean implementadas en los navegadores en la etapa 4 del proceso de TC39.

Babel es fundamental en el proceso dada su posición en el ecosistema: es significativamente más fácil para un desarrollador actualizar un archivo .babelrc que una bandera del navegador y mucho más rápido escribir un plugin de Babel que implementar la característica de forma nativa en el navegador. Este es el núcleo de Babel.

Pero el proceso de propuestas implica una iteración significativa: las propuestas pueden cambiar en sintaxis o incluso ser descartadas. Debido a que TC39 se reúne cada 2 meses, los plugins deben actualizarse al menos tan a menudo como cada cambio de etapa para que los usuarios puedan estar sincronizados.

La retroalimentación temprana al campeón de la propuesta y al comité es extremadamente valiosa, aunque se recomienda usar características de las Etapas 0/1/2 con precaución. Aunque empresas como Facebook aprovechan este tipo de características, han creado codemods para permitir cambios fáciles.

No hay suficiente tiempo o recursos para mantener cada plugin, especialmente cuando hay actualizaciones de la especificación.

  • Algunas transformaciones simplemente están desactualizadas, como los decoradores. Logan tuvo que adaptar la especificación anterior babel-plugin-transform-decorators-legacy para Babel 6 y no hemos tenido a nadie que pueda reescribirlo para la especificación actualizada.

  • babel/babel#3473 - Async iteration proposal no se fusionó durante tanto tiempo porque simplemente no teníamos tiempo para revisarlo. Para cuando se fusionó, ya había pasado de la etapa 2 a la etapa 3.

A continuación vamos a trabajar con:

Issues relevantes:

Consulta thefeedbackloop.xyz para más información sobre TC39!

Mantenimiento de otros plugins del ecosistema: JSX/Flow​

Babel es vital para los ecosistemas de React y Flow, y trabajamos estrechamente con los equipos relevantes en Facebook.

Etiquetas de issues relevantes:

babel-preset-env ("autoprefixer" para Babel)​

La compilación de JavaScript es un objetivo móvil: hay actualizaciones anuales de la especificación, los navegadores se actualizan constantemente para cumplirla, y los usuarios pueden dejar de dar soporte a navegadores antiguos. A primera vista, no parece haber un objetivo fijo para determinar a qué versión debemos compilar nuestro JavaScript.

La compat-table se actualiza constantemente y se utiliza para este preset.

Aquí es donde entra babel-preset-env: es un preset de Babel que determina automáticamente los plugins necesarios según los entornos objetivo proporcionados.

Su objetivo es tanto la simplicidad de uso como la eficiencia en la salida: solo necesitas preocuparte por tus entornos objetivo para aprovechar el código nativo. El preset decide por ti los plugins requeridos.

Algunos ejemplos de configuración​

Dirigido a Chrome 55 + las últimas 2 versiones de otros navegadores mediante browserslist

JavaScript
{
  "presets": [
    ["env", {
      "targets": {
        "chrome": 55,
        "browsers": ["last 2 versions"]
      }
    }]
  ]
}

Dirigirse a la versión actual de Node.js (usa process.versions.node)

JavaScript
{
  "presets": [
    ["env", {
      "targets": {
        "node": "current"
      }
    }]
  ]
}

Chrome 55 useBuiltIns + webpack 2

JavaScript
{
  "presets": [
    ["env", {
      "targets": {
        "chrome": 55
      },
      "modules": false,
      "useBuiltIns": true
    }]
  ]
}

Entrada

JavaScript
import "babel-polyfill";

Salida (diferente según el entorno)

JavaScript
import "core-js/modules/es7.string.pad-start";
import "core-js/modules/es7.string.pad-end";

Issues relevantes:

Análisis estático mediante babel-eslint​

example of eslint

ESLint no admite nuevas características del lenguaje hasta que alcanzan la Etapa 4 del proceso de propuestas. Por esta razón mantenemos babel-eslint (un parser personalizado para ESLint) para que puedas seguir analizando JavaScript con sintaxis experimental.

Este proyecto fue uno de los más difíciles de mantener: al ser solo una capa de compatibilidad entre Babel y ESLint, existe una necesidad constante de actualizaciones cuando cualquiera de los proyectos cambia y un alto riesgo de cambios inesperados debido al monkey-patching. Fue desafortunado encontrar problemas como babel/babel-eslint#243 o babel/babel-eslint#267.

Con ese fin, queremos reducir la carga de mantenimiento de este proyecto mejorando nuestra interoperabilidad de alcance y recorrido con ESLint. ¿Quizás incluso sería interesante poder escribir reglas de ESLint usando APIs de Babel o viceversa?

Issues relevantes:

Minificación​

Babili es nuestro nuevo minificador basado en Babel, que permite producir código minificado dirigido a navegadores modernos.

Entrada

JavaScript
class Mangler {
  constructor(program) {
    this.program = program;
  }
}
new Mangler();

Salida

JavaScript
// ES2015 code -> Babili -> Minified ES2015 Code
class a{constructor(b){this.program=b}}new a;

Consulta nuestra entrada de blog para más información.

Al ser un lanzamiento reciente, ¡buscamos nuevos colaboradores! Hay muchos errores menores y mejoras posibles para quienes busquen un nuevo proyecto donde contribuir.

Codemods / Refactorización / eslint --fix​

Un codemod es una modificación de código asistida por herramientas; una búsqueda-reemplazo avanzada.

Si quisieras cambiar merge({}) por Object.assign({}) (y quizás luego object rest), podrías usar reemplazo por regex. Pero no querrás afectar otras partes del código que también contengan merge como importaciones/exportaciones, cadenas, comentarios o variables locales. Para hacerlo de forma segura necesitas algo más potente que solo modifique el código específico.

Aunque Babel ya transforma código, como compilador no preserva el formato del código fuente original. Tras usar Babel con opciones predeterminadas para un codemod, git diff muestra cambios muy desordenados.

Entra Recast: una herramienta que preserva el formato del código no modificado mientras aplica un formateo limpio a los nuevos nodos del AST.

recast

En la captura superior, el panel superior izquierdo es el código de entrada y el inferior derecho es el resultado tras ejecutar el plugin de Babel. En este caso, preserva los espacios del código original cuando es posible.

Al pasar Recast en las opciones, Babel puede impulsar el futuro de los codemods.

.babelrc

JavaScript
{
  "parserOpts": {
    "parser": "recast"
  },
  "generatorOpts": {
    "generator": "recast"
  }
}

Ejecutar las transformaciones de Babel relevantes sobre el código fuente y sobrescribirlo:

Shell
babel src -d src

Esta funcionalidad acaba de ser habilitada, así que esperamos facilitar su uso y ver las transformaciones que permite. ¡Consulta la publicación de la versión 6.16.0 para más detalles!

Otros proyectos relevantes: JSCodeshift, js-codemod, Lebab.

Issues relevantes:

Cobertura de Código / Instrumentación​

Queremos dar soporte a herramientas como nyc y babel-plugin-istanbul.

Ecosistema de Plugins​

Gracias a nuestra vibrante comunidad, constantemente se crean nuevos plugins: ya sea una nueva forma de escribir CSS en JSX o reconfigurar pruebas.

Actualmente existen >1200 plugins de Babel en npm.

Hemos debatido cómo impulsar y apoyar el ecosistema de plugins. Podríamos intentar monitorear todos los repositorios, pero sería abrumador.

Sería interesante crear bots para automatizar tareas: desarrollar plugins de Babel/reglas ESLint específicas, escribir codemods para actualizar APIs, e integrar plugins en nuestras pruebas de humo.

  • ¿Deberíamos crear un boletín sobre plugins nuevos/útiles?

  • ¿Cómo enseñar sobre plugins y su desarrollo?

  • ¿Cómo mejorar ASTExplorer?

Documentación (¡este sitio web!)​

Las contribuciones a la documentación han sido escasas en el último año.

Sin embargo, recientemente hemos logrado avances importantes:

También sumamos nuevos colaboradores:

  • @STRML: Integró Discourse en todas las páginas de GitHub vía #875

  • @xtuc: Implementó soporte para leer el README del repositorio de Babel para evitar sincronizar dos copias de la documentación mediante #990

  • @fredericmarx: Agregó un botón de copiar al portapapeles para fragmentos de código mediante #998

  • @seedofjoy: Incorporó capacidad de redimensionado para el REPL mediante #1003

Algunas ideas

  • Todos los plugins deben incluir ejemplos. También se pueden integrar RunKit o el REPL.

  • Actualizar el FAQ con errores comunes

  • Documentación de API / mejorar el babel-handbook

Issues relevantes:

El futuro​

NOTA: Todo lo que sigue puede modificarse o descartarse. Algunas propuestas ya están en desarrollo y otras son solo sugerencias que requieren discusión formal o un responsable.

La prioridad debe determinarse según las necesidades de la comunidad, no por conveniencia.

Cambios en la API de plugins​

Existe mucha confusión sobre cómo interactúan plugins y presets en cuanto al orden. Esto genera errores y problemas de configuración que obligan a los usuarios a colocar plugins antes/después de otros de forma poco intuitiva.

Actualmente discutimos cambios en la API que podrían reducir esta confusión. Sin embargo, al tratarse de una modificación fundamental en el núcleo de Babel, podría llevar tiempo definir el mejor enfoque.

Control de versiones​

Desde Babel 6 usamos un sistema de versionado "fijo" mediante Lerna. Esto permite publicar múltiples paquetes simultáneamente bajo la misma versión (si un paquete cambia). Es ventajoso porque evita establecer versiones manualmente para cada paquete, manteniendo todo sincronizado. El único riesgo ocurre cuando un paquete introduce cambios rompedores: entonces todos los paquetes incrementan su versión mayor.

Esto se explica mejor en babel/notes, pero aún debemos definir el mejor plan de acción para el proyecto.

¿Qué ocurre cuando necesitamos actualizar una especificación en Etapa 0 a Etapa 1 y eso implica un cambio incompatible en el parser? ¿Simplemente incrementaremos la versión mayor, esperaremos para agrupar varios cambios, o encontraremos cómo hacerlo mediante múltiples versiones de plugins?

Issue de discusión

Cambiando la mentalidad sobre los presets de Etapa X​

Issues relevantes:

Velocidad​

¡El rendimiento es una característica! A veces otras cosas pueden tener mayor prioridad (corrección de errores, cumplimiento de especificaciones, etc.), pero sigue siendo importante en varios aspectos.

  • ¿Cómo podemos reducir el tamaño/tiempo de instalación, especialmente para proyectos con múltiples paquetes? (esto es ayudado por yarn)

  • ¿Cómo podemos parsear más rápido?

  • ¿Cómo podemos crear plugins más rápidos (y medirlos individualmente)?

  • ¿Cómo podemos generar el código transformado más rápido?

  • ¿Cómo podemos generar código que se ejecute rápido en el navegador (https://fhinkel.github.io/six-speed/)?

Si lees el resultado compilado y encuentras problemas, ¡reporta el problema y pide ayuda para hacer un PR!

Issues anteriores:

¿Posible soporte para TypeScript?​

¿Quizás Babel podría aprender a entender la sintaxis de TypeScript (como hacemos con Flow)? Podríamos añadir un plugin para eliminar los tipos de TypeScript y mejorar la interoperabilidad.

Esto implicaría parsear sintaxis específica de TypeScript y eliminarla. Sin embargo, TypeScript tiene sintaxis no relacionada con tipos, como enum, donde necesitaríamos más discusión.

¿Utilizar información de tipos?​

Integración con sistemas de tipos como Flow/TypeScript para realizar optimizaciones. Esto significa que Babel podría obtener conocimiento a través de estas herramientas para determinar si un identificador arr es realmente un Array o no.

Existen algunos plugins que realizan comprobación de tipos: babel-plugin-typecheck y babel-plugin-tcomb

¿Recibir un gráfico de dependencias / Operar con múltiples archivos?​

Esto permitiría mejor integración con herramientas como Webpack. Facilitaría transformaciones entre archivos u optimizaciones de todo el código base. El objetivo principal sería para el minificador (poder eliminar propiedades verificando su uso en toda la aplicación) o proporcionar errores sobre import/export faltantes o inválidos.

Errores del parser​

Mejores mensajes de error del parser, como en Errores de compilador para humanos.

¡Es evidente que todos queremos errores útiles!

Podemos mejorar la inferencia/detección de intenciones del usuario para evitar errores vagos. ¡Infórmanos en qué casos ocurre esto!

Issues relevantes:

babel-init​

Básicamente, una forma de configurar Babel fácilmente como lo hace create-react-app.

  • Crear un .babelrc desde cero mediante preguntas interactivas

Posible idea:

  • Especificar los entornos objetivo (navegadores, node) y pasarlos a babel-preset-env

  • Preguntar sobre características experimentales (añadir plugins específicos)

  • Actualizar el paquete npm babel para que vuelva a ser funcional: Convertirlo en el babel predeterminado/opt-in/opinionado que era Babel 5. Podría usar env por defecto con soporte para latest 2 browsers (sin configuración adicional).

Issues relevantes:

Ejecutar tc39/test262​

test262 verifica el cumplimiento del borrador continuo del estándar ECMAScript futuro disponible en tc39.github.io/ecma262, junto con cualquier propuesta TC39 en Etapa 3 o superior. Es mantenido por Tom Care (@tcare) con contribuciones significativas de la comunidad ECMAScript.

Ejecutar las pruebas oficiales de especificación contra Babel asegura nuestro cumplimiento o al menos identifica desviaciones. Necesitamos implementar filtros para funcionalidades no compilables (proxy, TCO, etc.) y crear un sistema para verificar pruebas fallidas, reportar issues y enviar PRs.

Issues relevantes:

Pruebas de humo/integración​

Sería útil tener un Greenkeeper inverso o ejecutar pruebas con la rama principal de Babel para detectar regresiones antes de los lanzamientos (Node.js tiene el proyecto citgm para esto). Idealmente, probaríamos los proyectos open source más grandes que usan Babel.

¡motiz88/babel-smoke-tests es un buen comienzo! Sería excelente si ya existiera una solución similar.

Análisis de programas​

La charla de Alan Shreve "Registros de commits idealizados: Simplificación de código mediante segmentación de programas" inspiró a @kentcdodds a implementarlo en JavaScript con slice-js.

La idea principal es que tenemos muchas herramientas para escribir código pero pocas para comprender/leer código. La segmentación de código puede verse como una eliminación dirigida de código muerto.

slice-js

Un segmento de programa básicamente elimina del código fuente las partes no utilizadas en un caso de prueba ejecutado. Si hay muchas sentencias if y bucles que no se ejecutan durante tu caso de uso, no aparecerán en el segmento de programa.

  • ¿Herramienta de búsqueda semántica (consciente del AST)?

Similar a graspjs, sería interesante poder hacer búsquedas-reemplazos usando un AST como entrada. Esto permitiría crear otras herramientas de análisis: encontrar todas las IIFE en nuestro código, contar cuántas veces se llama un método, o incluso cuántas Clases hay en nuestra base de código.

babel --settings​

Este comando mostraría toda la información (incluso durante errores). También incluiría métricas de rendimiento sobre el tiempo que toma cada plugin.

Unidad del analizador sintáctico​

También ha habido discusiones sobre la unificación de analizadores sintácticos/AST, en TheLarkInn/js-parser-discussions y previamente con ESTree.

Lamentablemente con Babel 6, hemos "bifurcado" y tenemos algunas diferencias en nuestro AST respecto a ESTree. Babel busca soportar características en etapa x mientras otros analizadores solo soportan etapa 4. Priorizamos aspectos diferentes: cumplimiento de especificaciones, rendimiento, características en etapa x, mensajes de error, extensibilidad, lanzamientos, etc. Pero es crucial estar abiertos a cambios disruptivos que mejoren la interoperabilidad y comunidad.

¿Interoperabilidad con Sweet.js?​

Issue anterior. ¿Quizás podríamos lograr mejor interoperabilidad directamente?

Soporte para Node.js​

¿Deberíamos eliminar soporte según el EOL de versiones de Node.js? ¿Cuánto tiempo debemos esperar generalmente?

  • ¿Queremos seguir dando soporte a usuarios que no han actualizado?

  • Ciertas transformaciones/PRs están bloqueadas porque herramientas relacionadas ya dejaron de soportar versiones antiguas.

  • Muchos proyectos de construcción como ESLint ya lo hicieron.

  • ¿Haremos una versión mayor solo por esto o planearemos otros cambios adicionales?

  • Issue de discusión

Transición Babel 5 a 6 / Rutas de actualización​

Babel 6 fue muy difícil de adoptar para la comunidad. El lanzamiento inicial fue algo apresurado. Aunque publicamos un post de lanzamiento 6.0, una guía de configuración luego, e incluso una herramienta (ahora obsoleta), los usuarios aún tuvieron dificultades para entender los cambios.

Aún hay muchos usuarios en Babel 5 que no queremos dejar atrás. ¿Cómo ayudarlos a actualizar? ¿Qué pasos tomar para evitar que esto ocurra con Babel 7? ¿A qué otros proyectos/comunidades deberíamos acercarnos para ayudar?

Issues relevantes:

¿Qué más?​

¿Algo más que no se haya mencionado aquí? ¡Envíanos un tweet @babeljs, un mensaje en nuestro Slack (únete en https://slack.babeljs.io/), comenta esta publicación o crea un issue de discusión en nuestro repositorio!

¿Hay proyectos o comunidades con los que deberíamos asociarnos más? ¿Cómo podemos hacer que la experiencia de contribución sea más acogedora? ¿Qué podemos hacer para que el proceso de desarrollo sea más transparente?

Comunidad​

Issues antiguos:

Podrías pensar que a medida que un proyecto se usa más ampliamente, más personas aparecerían para ayudar. Pero como la mayoría de proyectos OSS no respaldados por empresas, existe un problema constante de mantenimiento y sostenibilidad; las personas sufren burnout, pasan a otros proyectos interesantes o se ocupan con trabajo/familia/etc.

Como James describe en Dear JavaScript, el equipo actual de Babel es bastante reducido.

Babel no es una empresa, un equipo especial en Facebook, ni un proyecto OSS financiado corporativamente. Es un esfuerzo impulsado por la comunidad sostenido actualmente por pocas personas, y queremos que eso crezca.

¡Así que si te interesa contribuir a una herramienta que usas, esperamos que esta pueda ser la indicada!

¿Qué issues debo revisar o en qué contribuir?​

Muchos proyectos tienen etiquetas beginner-friendly y help-wanted. También puedes revisar discussion.

Equipo​

Nuestro equipo central:

Y solo en los últimos 3 meses, muchos más colaboradores:

Equipo central de Babili:

Como mencionamos antes, tenemos muchos colaboradores en el sitio web:

Inactivos pero aún como recurso:

¿Cómo puedo contactar al equipo?​

GitHub​

Para informes de errores o PRs, visita nuestros repositorios.

Twitter​

Mencionanos en Twitter con @babeljs o directamente a los miembros individuales.

Yo mismo me uní a Twitter para interactuar con usuarios y ayudar. Publicar novedades y changelogs es útil para recibir feedback.

Slack​

¡Tenemos una comunidad bastante activa aquí!

Encontrarás miembros dispuestos a ayudar como Jordan Harband, @ljharb, Jessica Franco, @Jessidhia, Jimmy Jia, @taion, Denis Pushkarev, @zloirock ¡y más!

Para dudas únete a #discussion; para colaborar o seguir desarrollos visita #development.

Evitamos discusiones privadas innecesarias: suelo publicar issues/PRs en los que trabajo para revisión colectiva.

Otros canales​

¿Cómo más podemos interactuar? ¿Deberíamos organizar meetups, asistir a conferencias o gestionar hackathons?

¿Cómo hacer sostenible Babel? ¿Crear un Open Collective, buscar una fundación o contratar un gestor de proyecto?

¡Comparte tus ideas! ¿Qué esperas de Babel?

¿Ves errores tipográficos? Envía un PR o comenta en babel/babel.github.io#1014

Queremos destacar que muchos empezamos con Babel para aprender JavaScript, no por ser expertos. Personalmente, desconocía los compiladores y apenas descubría ES6 al unirme. Llegué por curiosidad y el apoyo de la comunidad. Aspiro a mantener ese espíritu para que todos crezcamos juntos.

¡Muchas gracias por leer!

Henry Zhu (@hzoo) (@left_pad)

Agradecimientos a demasiadas personas por sus revisiones y aportes: @DrewML, @mrjoelkemp, @kentcdodds, @existentialism, @jdalton, @gaearon, @nolanlawson, @jayphelps, @montogeek, @TheLarkInn, @jasonLaster, @benjamn, @addyosmani, @Daniel15, @loganfsmyth, @gr2m, @mathiasbynens, @chicoxyzzy, @bvaughn, @bcoe.