Saltar al contenido principal

Lanzamiento de Babel 7

· 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 →

Tras casi 2 años, 4k commits, más de 50 pre-lanzamientos y mucha ayuda, nos complace anunciar el lanzamiento de Babel 7. ¡Han pasado casi 3 años desde el lanzamiento de Babel 6! Hay muchas partes móviles así que por favor tengan paciencia durante las primeras semanas. Babel 7 es una versión enorme: lo hemos hecho más rápido, creamos una herramienta de actualización, configuraciones JS, "overrides" de configuración, más opciones para tamaño/minificación, JSX Fragments, TypeScript, nuevas propuestas y más.

Si valoras nuestro trabajo en Babel, puedes patrocinarnos en Open Collective, apoyarme en Patreon, o involucrar a tu empresa con Babel como parte de su trabajo. ¡Agradecemos la propiedad colectiva de este proyecto vital en la comunidad JavaScript!

¡Está ocurriendo! 🎉​

El software nunca será perfecto pero estamos listos para publicar algo que ya se ha usado en producción desde hace tiempo. ¡@babel/core ya alcanza 5.1 millones de descargas/mes gracias a su uso en herramientas como Next.js 6, vue-cli 3.0, React Native 0.56 e incluso el frontend de WordPress.com! 🙂

El papel de Babel​

Quiero comenzar este post reintroduciendo el papel de Babel en el ecosistema JavaScript durante los últimos años.

El problema inicial era que, a diferencia de los lenguajes de servidor, no había forma de garantizar que cada usuario tuviera el mismo soporte para JavaScript porque podían usar navegadores distintos con niveles de soporte variables (especialmente versiones antiguas de Internet Explorer). Si los desarrolladores querían usar nueva sintaxis (ej. class A {}), los usuarios en navegadores antiguos simplemente verían una pantalla en blanco debido al SyntaxError.

Babel proporcionó una forma para que los desarrolladores usaran la última sintaxis de JavaScript sin preocuparse por cómo hacerla compatible con versiones anteriores, traduciéndola (class A {} a var A = function A() {}).

Gracias a su capacidad para transformar código JavaScript, también puede usarse para implementar nuevas características: así se ha convertido en un puente para ayudar a TC39 (el comité que especifica el lenguaje JavaScript) a obtener retroalimentación sobre propuestas y para que la comunidad participe en el futuro del lenguaje.

Babel es fundamental para el desarrollo JavaScript hoy. Actualmente hay más de 1.3 millones de repositorios dependientes en GitHub, 17 millones de descargas mensuales en npm y cientos de usuarios incluyendo frameworks importantes (React, Vue, Ember, Polymer) y empresas (Facebook, Netflix, Airbnb). Se ha convertido en tal base para el desarrollo JavaScript que mucha gente ni siquiera sabe que se está usando. Incluso si tú no lo usas directamente, es muy probable que tus dependencias usen Babel.

Los mantenedores son personas​

Babel tiene una enorme influencia no solo en el futuro del lenguaje sino también en su comunidad y ecosistema. Pero aun con toda esta responsabilidad, Babel es solo un proyecto comunitario impulsado por un par de voluntarios.

Fue apenas el año pasado que algunos miembros del equipo pudieron conocerse en persona por primera vez:

Aunque este es un anuncio, me gustaría aprovechar la oportunidad para recordarles a todos el estado actual de este proyecto.

Yo mismo me uní unos meses antes del lanzamiento de la versión 6.0, que tuvo su propia cuota de controversia y rechazo. Gran parte de la recepción en ese momento provocó agotamiento en los mantenedores existentes (incluyendo a Sebastian, el creador de Babel) y algunos de los que quedamos tomamos las riendas.

Como muchos mantenedores, llegamos a este rol por casualidad. Muchos de nosotros no teníamos formación formal sobre cómo funcionan los compiladores o cómo mantener un proyecto de código abierto. Irónicamente, incluso evité deliberadamente estudiar Ciencias de la Computación en la universidad porque no quería tomar clases sobre compiladores o temas de bajo nivel, ya que me parecían poco interesantes y difíciles. Sin embargo, me vi atraído por las herramientas, los linters, Babel y JavaScript como lenguaje.

Me gustaría animar a todos a que revisen los proyectos de código abierto de los que dependen y los apoyen (tanto con tiempo como con apoyo monetario si es posible).

Muchos mantenedores no son inherentemente expertos en las cosas en las que trabajan; y hay mucho que lograr simplemente comenzando a trabajar primero. Llegarás con curiosidad y humildad, ambos son grandes atributos para un mantenedor. Mi deseo es tener esperanza en la visión del proyecto en lugar de que todos simplemente hagamos "tareas".

Babel no es una empresa, ni un equipo de código abierto en una gran empresa como Facebook. Solo hay un puñado de voluntarios trabajando en Babel, y solo han pasado unos meses desde que di el salto para dejar mi trabajo y ser el único hasta ahora en trabajar en código abierto a tiempo completo. Pero las personas pueden ir y venir, tener vidas fuera de este "hobby", criar familias, pasar a otras cosas, cambiar de trabajo o buscar empleo, etc. ¿Estamos haciendo colectivamente lo que podemos para sostener las cosas que son tan fundamentales para nuestra forma de trabajar, o vamos a permitir que los cimientos se desmoronen lentamente? ¿Cómo mantenemos el código abierto acogedor e inclusivo pero con límites claros? ¿Podemos aprender de las experiencias de otros mantenedores?

Aunque el código abierto claramente ha dominado el software, ¿realmente podemos considerarlo en un estado saludable sin tener en cuenta a las personas detrás de él?

#BabelSponsorsEverything​

La sostenibilidad del código abierto se siente como pasar una canasta de ofrendas en este momento. No es difícil afirmar el valor que los proyectos brindan a miles de personas y empresas que usan código abierto, pero aún no vemos que ese valor se muestre a los pocos que están dispuestos a trabajar. Puede haber muchas formas de apoyar el código abierto, pero no todos los enfoques funcionan para cada proyecto o persona.

¡Ahora vayamos a los cambios!!

Cambios importantes con ruptura de compatibilidad​

Estamos documentando estos cambios en nuestra Guía de Migración. Muchos de estos cambios se pueden realizar automáticamente con nuestra nueva herramienta babel-upgrade, o se pueden agregar en el futuro.

  • Eliminar el soporte para versiones de Node no mantenidas: 0.10, 0.12, 4, 5 (detalles)

  • Migración al espacio de nombres @babel mediante el uso de paquetes "scoped" (detalles). Esto ayuda a diferenciar los paquetes oficiales, por lo que babel-core pasa a ser @babel/core (y evita el squatting)

  • Eliminación (y cese de publicación) de los presets anuales (preset-es2015, etc) (detalles). @babel/preset-env reemplaza su necesidad al incluir todas las adiciones anuales y la capacidad de dirigirse a un conjunto específico de navegadores

  • También eliminamos los presets de "Stage" (@babel/preset-stage-0, etc) en favor de activar propuestas individuales. De manera similar, eliminamos las propuestas de @babel/polyfill por defecto (detalles). Recomendamos leer la publicación completa para más explicaciones.

  • Renombramiento de paquetes: cualquier plugin de propuesta TC39 ahora usará -proposal en lugar de -transform (detalles). Por ejemplo, @babel/plugin-transform-class-properties pasa a ser @babel/plugin-proposal-class-properties.

  • Introducción de peerDependency en @babel/core para paquetes orientados al usuario (como babel-loader, @babel/cli, etc) (detalles)

babel-upgrade​

babel-upgrade es una nueva herramienta que hemos desarrollado para realizar automáticamente los cambios de actualización: actualmente maneja dependencias en package.json y configuración de .babelrc.

Recomendamos ejecutarla directamente en un repositorio git con npx babel-upgrade, o instalarla globalmente con npm i babel-upgrade -g.

Si deseas modificar los archivos, puedes pasar --write junto con --install.

Shell
npx babel-upgrade --write --install

¡Por favor considera contribuir reportando issues o enviando PRs para ayudar a todos en la transición a Babel 7! Nuestra visión es usar esta misma herramienta para futuros cambios disruptivos y crear un bot que envíe PRs para actualizar proyectos.

Archivos de Configuración JavaScript​

Presentamos babel.config.js. No es un requisito ni un reemplazo de .babelrc, pero puede ser útil en ciertos casos.

Los archivos de configuración *.js son comunes en el ecosistema JavaScript. ESLint y Webpack permiten archivos .eslintrc.js y webpack.config.js, respectivamente.

A continuación, un ejemplo para compilar solo con un plugin en "producción" (esto ya es posible con la opción "env" en un archivo .babelrc):

JavaScript
var env = process.env.NODE_ENV;
module.exports = {
  plugins: [
    env === "production" && "babel-plugin-that-is-cool"
  ].filter(Boolean)
};

babel.config.js tiene una resolución de configuración diferente a .babelrc. Siempre resuelve la configuración desde ese archivo, a diferencia del comportamiento original de Babel que buscaba la configuración hacia arriba desde cada archivo. Esto permite aprovechar la siguiente característica: overrides.

Configuración Selectiva con overrides​

Recientemente publiqué un artículo con reflexiones sobre la publicación de paquetes ES2015+ y su compilación/consumo.

Hay una sección que explica cómo usar una nueva clave en la configuración de Babel llamada overrides que permite especificar configuraciones diferentes por patrón glob.

JavaScript
module.exports = {
  presets: [
    // default config...
  ],
  overrides: [{
    test: ["./node_modules"],
    presets: [
      // config for node_modules
    ],
  }, {
    test: ["./tests"],
    presets: [
      // config for tests
    ],
  }]
};

Esto permite que una aplicación que requiere configuraciones de compilación diferentes para sus pruebas, código cliente y código servidor pueda evitar tener que crear un archivo .babelrc nuevo por carpeta.

Velocidad 🏎​

El propio Babel es más rápido ¡así que debería tardar menos tiempo en construir! Hemos hecho muchos cambios para optimizar el código además de aceptar parches del equipo de v8. Nos alegra ser parte del Web Tooling Benchmark junto con otras grandes herramientas de JavaScript.

Opciones de Salida​

Babel ha soportado opciones para presets y plugins desde hace algún tiempo. Para recapitular, puedes envolver el plugin en un array y pasar un objeto de opciones al plugin:

{
  "plugins": [
-   "pluginA",
+   ["pluginA", {
+     // options here
+   }],
  ]
}

¡Hemos hecho algunos cambios en la opción loose de ciertos plugins y añadido nuevas opciones para otros! Ten en cuenta que al usar estas opciones estás adoptando un comportamiento que no cumple con la especificación y deberías saber lo que haces; esto puede convertirse en un problema cuando dejes de compilar para usar la sintaxis de forma nativa. Este tipo de opciones son mejores usadas en una librería, si es que se usan.

  • Para clases, class A {} ahora no incluirá el helper classCallCheck.
JavaScript
class A {}
var A = function A() {
-  _classCallCheck(this, A);
};
  • Hay una nueva opción si cada uso de un bucle for-of es solo para arrays: ["transform-for-of", { "assumeArray": true }]
JavaScript
let elm;
for (elm of array) {
  console.log(elm);
}
JavaScript
let elm;

for (let _i = 0, _array = array; _i < _array.length; _i++) {
  elm = _array[_i];
  console.log(elm);
}
  • Excluimos el plugin transform-typeof-symbol en modo loose para preset-env #6831

Hemos encontrado muchas bibliotecas que ya hacen esto, así que decidimos hacerlo por defecto.

Ten en cuenta que el comportamiento predeterminado es ser lo más compatible posible con la especificación para que dejar de usar Babel o usar preset-env sea sin problemas, frente a permitir una salida más pequeña solo para ahorrar bytes (hay un compromiso que cada proyecto puede tomar). Planeamos trabajar en mejor documentación y herramientas para facilitarlo.

Soporte para anotaciones "Pure"​

Tras #6209, las clases ES6 transpiladas se anotan con un comentario /*#__PURE__*/ que da una pista a minificadores como Uglify y babel-minify para la eliminación de código muerto. Estas anotaciones también se añaden a otras funciones helper.

JavaScript
class C {
  m() {}
}
JavaScript
var C =
/*#__PURE__*/
function () {
  // ...
}();

¡Puede haber más oportunidades para pistas y optimizaciones en minificadores, háznoslo saber!

Sintaxis​

Soporte para propuestas de TC39​

Me gustaría reiterar que hemos eliminado los presets de etapa en favor de una política que pide a los usuarios que expliciten su uso de propuestas anteriores a la Etapa 4.

La preocupación es que estábamos optando automáticamente a la gente por una sintaxis que no está fija o terminada, con la expectativa de que no cambiaría. Pero este no es el caso, especialmente para propuestas en Etapa 0 o 1. Este artículo explica un poco el tipo de pensamiento detrás de las ideas más nuevas.

Aquí tienes una pequeña lista de algunas nuevas sintaxis que Babel admite (ten en cuenta que este conjunto de características es un objetivo móvil que podría añadirse, eliminarse o estancarse) y cuáles se han añadido en la v7:

Es difícil para cualquiera seguir todas las propuestas, por lo que intentamos hacerlo en babel/proposals.

Soporte para TypeScript (@babel/preset-typescript)​

Trabajamos con el equipo de TypeScript para que Babel pueda analizar/transformar sintaxis de tipos mediante @babel/preset-typescript, similar a cómo manejamos Flow con @babel/preset-flow.

Para más detalles, consulta esta publicación del equipo de TypeScript!

Antes (con tipos):

interface Person {
  firstName: string;
  lastName: string;
}

function greeter(person : Person) {
  return "Hello, " + person.firstName + " " + person.lastName;
}

Después (tipos eliminados):

function greeter(person) {
  return "Hello, " + person.firstName + " " + person.lastName;
}

Tanto Flow como TypeScript son herramientas que permiten a los usuarios de JavaScript aprovechar el tipado gradual, y queremos habilitar ambos en Babel. Planeamos seguir colaborando estrechamente con sus respectivos equipos en FB y Microsoft (además de la comunidad en general) para mantener la compatibilidad y dar soporte a nuevas características.

Esta integración es bastante nueva, así que es posible que alguna sintaxis no esté totalmente soportada. Agradecemos tu ayuda reportando problemas y quizá enviando un PR!

Soporte para fragmentos JSX (<>)​

Como se mencionó en el Blog de React, el soporte para fragmentos JSX ha estado disponible desde beta.31.

JSX
render() {
  return (
    <>
      <ChildA />
      <ChildB />
    </>
  );
}

// output 👇

render() {
  return React.createElement(
    React.Fragment,
    null,
    React.createElement(ChildA, null),
    React.createElement(ChildB, null)
  );
}

Cambios en los helpers de Babel​

El PR de babel-upgrade está en progreso

@babel/runtime se ha dividido en @babel/runtime y @babel/runtime-corejs2 (PR). El primero solo contiene funciones auxiliares de Babel, mientras que el segundo incluye además funciones de polyfill (ej. Symbol, Promise).

Babel puede necesitar inyectar ciertas funciones en el código que pueden reutilizarse. Simplemente llamamos a estas "funciones auxiliares" (helpers), al igual que las funciones compartidas entre módulos.

Un ejemplo de esto es al compilar una class (sin el modo loose):

La especificación indica que debes llamar a una clase con new Person(), pero si se compila a una función, técnicamente podrías hacer solo Person(), por lo que incluimos una verificación en tiempo de ejecución.

JavaScript
class Person {}
JavaScript
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }

var Person = function Person() {
  _classCallCheck(this, Person);
};

Con @babel/plugin-transform-runtime y @babel/runtime (como dependencia), Babel puede extraer las funciones individuales y simplemente requerir las funciones modulares para permitir una salida más pequeña:

JavaScript
var _classCallCheck = require("@babel/runtime/helpers/classCallCheck");

var Person = function Person() {
  _classCallCheck(this, Person);
};

Lo mismo puede hacerse con external-helpers y rollup-plugin-babel. Estamos investigando si podemos hacer esto automáticamente en el futuro. Estate atento a una publicación independiente sobre los helpers de Babel próximamente.

Polyfilling automático (experimental)​

Los polyfills son necesarios para habilitar características como Promise o Symbol en entornos que no las soportan. Esto es importante al diferenciar lo que hace Babel como compilador (transforma sintaxis) frente a un polyfill (implementa funciones/objetos incorporados).

Es bastante fácil importar algo que cubra todo, como @babel/polyfill:

JavaScript
import "@babel/polyfill";

Pero incluye todo el polyfill, y puede que no necesites importar todo si los navegadores ya lo soportan. Este es el mismo problema que @babel/preset-env intenta resolver con la sintaxis, así que lo aplicamos aquí con polyfills. La opción useBuiltins: "entry" hace esto dividiendo la importación original en solo las importaciones necesarias.

Pero podemos hacerlo mejor importando solo los polyfills utilizados en la base de código. La opción "useBuiltIns: "usage" es nuestro primer intento de habilitar algo así (docs).

Recorrerá cada archivo e inyectará una importación en la parte superior si ese built-in se "usa" en el código. Por ejemplo:

JavaScript
import "core-js/modules/es6.promise";
var a = new Promise();

La inferencia no es perfecta, por lo que pueden producirse falsos positivos.

JavaScript
import "core-js/modules/es7.array.includes";
a.includes // assume a is an []

Otras ideas en este ámbito son usar polyfill.io si te parece bien depender de un servicio (o lee cómo Kent C. Dodds lo usó para construir un servicio alojado en PayPal).

Misceláneos​

Macros de Babel 🎣​

Una de las mejores características de Babel es su capacidad de extensión mediante plugins. A lo largo de los años, Babel pasó de ser un simple compilador "6to5" a una plataforma de transformación de código, permitiendo optimizaciones fantásticas tanto para la experiencia del usuario como del desarrollador. Se han desarrollado numerosos plugins de Babel para bibliotecas y casos de uso específicos que mejoran el rendimiento y capacidades de las APIs (algunas "bibliotecas" se transpilan completamente eliminando cualquier runtime).

Desafortunadamente, añadir estos plugins a tu proyecto requiere modificar la configuración (algo que herramientas como create-react-app no permiten) y añade complejidad porque los desarrolladores deben conocer qué plugins operan sobre un archivo. ¡Estos problemas los resuelve babel-plugin-macros de Kent C. Dodds!

Una vez instalado babel-plugin-macros y añadido a tu configuración (viene incluido en create-react-app v2), no necesitas tocar la configuración para usar macros. Además, es más fácil crear tus propias transformaciones para casos específicos de tu aplicación.

Aprende más sobre babel-plugin-macros en nuestra publicación original: "Transformación de código sin configuración con babel-plugin-macros".

Orientación de Módulos​

Babel siempre ha buscado equilibrar el impacto en tamaño de las transformaciones con las capacidades que ofrecen. En Babel 7 es más fácil configurar el soporte para el creciente patrón module/nomodule.

Cabe destacar que varias herramientas CLI para frameworks populares (1, 2) ya aprovechan esta compatibilidad, reduciendo un ~20% el JavaScript enviado en aplicaciones transpiladas por Babel.

Metadatos de Llamador y Mejores Defaults​

Hemos añadido una opción caller en @babel/core para que las herramientas pasen metadatos a presets/plugins. Por ejemplo: babel-loader puede añadir algo como esto para que preset-env deshabilite automáticamente la transformación de módulos (igual con rollup):

JavaScript
babel.transform("code;", {
  filename,
  presets: ["@babel/preset-env"],
  caller: {
    name: "babel-loader",
    supportsStaticESM: true,
  },
});

Es emocionante porque permite que las herramientas ofrezcan mejores valores predeterminados con menos configuración. Para webpack/rollup: podemos usar automáticamente su transformación de módulos en lugar de la de Babel (igual con import("a")). ¡Espera que más herramientas aprovechen esto!

class C extends HTMLElement {}​

Uno de nuestros problemas más antiguos tiene su propio encabezado (detalles)

¡Babel siempre tuvo la limitación de no poder extender elementos nativos (Array, Error, etc.) y ahora sí puede! Hemos recibido muchos informes sobre este problema; 🎉 ¡deberían celebrar como Andrea!

Este cambio se implementó en el plugin de clases, por lo que se activará automáticamente si usas preset-env.

Cambios en el sitio web 🌏​

¡Hemos migrado nuestro sitio de Jekyll a Docusaurus!

Seguimos configurando las traducciones con Crowdin, y con Babel 7 publicado, estaremos en mejor posición para iniciar ese proceso.

REPL​

Hemos reescrito el REPL como un componente de React, trabajando con Ives para mejorar su integración con CodeSandbox. Esto permite instalar cualquier plugin o preset desde npm en el REPL y recibir actualizaciones de CodeSandbox.

¡Participamos nuevamente en Rails Girls Summer of Code! Esta vez, Gyujin y Sujin trabajan intensamente para integrar babel-time-travel de Boopathi en el REPL, ¡ya disponible para pruebas!

¡Hay muchas oportunidades para contribuir a mejorar Babel, los AST y otras herramientas!

Tenemos una canción 🎶​

Hallelujah—In Praise of Babel

Un día, Angus generosamente nos regaló una canción que nos pareció increíble, ¿por qué no hacerla nuestra "oficial"? Shawn creó una versión brillante aquí.

Pueden encontrarla en nuestro repositorio en SONG.md. ¡Esperamos que otros proyectos sigan este ejemplo!

¿Qué sigue?​

  • Babel está intrínsecamente ligado a lo que compila: JavaScript. Mientras haya nuevas adiciones para proponer/trabajar, habrá trabajo por hacer. Esto incluye el tiempo/el esfuerzo para implementar y mantener la sintaxis incluso antes de que se vuelva "estable". Nos importa todo el proceso: la ruta de actualización, la educación sobre nuevas características, la enseñanza de estándares/diseño del lenguaje, la facilidad de uso y la integración con otros proyectos.

    • Relacionado: casi hemos terminado de implementar la nueva propuesta de decoradores en Babel gracias a Nicolò. Ha sido un largo camino (¡ha tomado más de un año!) porque la nueva propuesta es completamente diferente y mucho más poderosa que la anterior, pero ya casi está 🎉. Puedes esperar que se lance en una de las próximas versiones menores, junto con una publicación de blog que explicará los cambios en detalle.

  • Boopathi ha mantenido diligentemente babel-minify, ¡así que haremos una versión 1.0 para eso próximamente!

  • Hay muchas nuevas características en desarrollo: orden de plugins, mejor validación/errores, velocidad, repensar opciones loose/spec, caché, uso asíncrono de Babel, compilación contra sí mismo desde CI, pruebas de humo, ejecución de test262. ¡Consulta este documento de hoja de ruta para más ideas posibles!

No tenemos planes secretos: estamos haciendo lo mejor que podemos con lo que tenemos para servir a esta comunidad.

El Código Abierto es un Espejo​

Me encantaría que tuviéramos el tiempo y los recursos para lograr todas estas ideas y hacerlo bien. Pero como hemos mostrado con este lanzamiento actual, ¡las cosas toman mucho más tiempo del esperado!

¿Por qué estos lanzamientos tardan tanto? ¿Es por la acumulación de funciones, tanto de nosotros como de nuestros usuarios? ¿Porque no sabemos priorizar entre todas las cosas posibles para agregar o corregir? ¿Decidir arreglar problemas sencillos frente a problemas fundamentales hasta el final? ¿O "distracciones" ayudando a otros en GitHub, Slack, Twitter? ¿Simplemente somos malos estimando nuestro tiempo, comprendiendo las complejidades de estos problemas, comprometiéndonos demasiado como voluntarios?

¿O simplemente nos ponemos expectativas demasiado altas, o nos sentimos presionados por otros para desempeñarnos y satisfacer sus necesidades en detrimento propio? Solo puedo describirlo como temor al ver un mensaje de alguien preguntando por qué algo no se ha lanzado mientras otro pregunta por qué este error aún no está solucionado. Quiero apresurarme y terminarlo, pero también tengo el deseo de tomarlo en serio.

He intentado expresar algunos de estos pensamientos y luchas en mi charla la semana pasada en React Rally: A través del espejo (del código abierto), que espero puedas escuchar. La pregunta que me hago: ¿Qué puedo hacer sobre el ciclo inevitable de agotamiento del mantenedor, ansiedad constante y expectativas poco realistas?

Como gran parte de la vida, las cosas que hacemos reflejan nuestro carácter y muestran cómo somos realmente. Las acciones que tomamos pueden cambiarnos, para bien o para mal. Si vamos a tomar nuestro trabajo en serio, debemos responsabilizarnos mutuamente de estos hábitos tan arraigados en nuestra cultura: gratificación instantánea, éxito medido en métricas, derecho vs. gratitud y orgullo en el exceso de trabajo.

Pero a pesar de todo, trabajar hacia este lanzamiento ha valido tanto la pena.

Agradecimientos​

Este es realmente un lanzamiento emocionante, no solo por mirar hacia atrás lo que hemos logrado y habilitado, sino mucho más solo sabiendo cuánto tiempo y corazón se dedicó para hacerlo realidad durante el último año. Es difícil creer las oportunidades y experiencias que han ocurrido en el camino: interactuar y ayudar a empresas de todo el mundo, encontrar amigos en casi cualquier ciudad que he visitado y hablar honestamente sobre el viaje increíble que este grupo ha emprendido juntos.

Personalmente, nunca había dedicado tanta energía mental a algo de esta magnitud y quiero agradecer a todas las personas que nos han apoyado en el camino. Un reconocimiento especial para Logan Smyth, quien dedicó innumerables horas a transformar el funcionamiento del núcleo y siempre encuentra tiempo para ayudar en nuestro Slack mientras trabaja como freelance, y para Brian Ng, quien dio un paso adelante de manera extraordinaria para mantener Babel además de revisar todas mis publicaciones de blog y charlas. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo y Justin Ridgewell han sido fundamentales para hacer posible esta versión y que trabajar en ella fuera un placer.

Reconocimiento también a todos los miembros de la comunidad en Slack, Twitter y los diversos proyectos de GitHub que deben comprender nuestro trabajo para sus propios usuarios. Un enorme agradecimiento a mis colegas en Behance/Adobe por patrocinarme casi un año para trabajar en Babel a medio tiempo antes de dedicarme completamente (además de probar Babel 7 en producción durante todo ese período). Gran agradecimiento a todos nuestros patrocinadores de Open Collective, especialmente Trivago y Handshake. Y gracias a nuestros amigos y familia por todo su amor y apoyo.

Estamos bastante agotados en este punto, pero ha sido un verdadero honor y privilegio servir de esta manera, ¡esperamos que valoren esta versión!