Lanzamiento de Babel 7

BY admin
|

Después de casi 2 años, 4k commits, más de 50 pre-lanzamientos, y mucha ayuda, estamos contentos de anunciar el lanzamiento de Babel 7. ¡Han pasado casi 3 años desde el lanzamiento de Babel 6! Hay muchas partes en movimiento, así que por favor, tened paciencia con nosotros en las primeras semanas de lanzamiento. Babel 7 es un gran lanzamiento: lo hemos hecho más rápido, hemos creado una herramienta de actualización, configuraciones JS, «overrides» de configuración, más opciones de tamaño/minificación, JSX Fragments, TypeScript, nuevas propuestas, ¡y mucho más!

Si aprecias el trabajo que estamos haciendo en Babel, puedes patrocinar Babel en Open Collective, apoyarme en Patreon, o involucrarte tú o tu empresa en Babel como parte del trabajo. ¡Apreciaríamos la apropiación colectiva de este proyecto vital en la comunidad de JavaScript!

¡Está ocurriendo! 🎉

¡El software nunca va a ser perfecto pero estamos listos para enviar algo que ya se usa en producción desde hace tiempo! @babel/coreYa está en 5,1 millones de descargas/mes debido 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

Me gustaría empezar 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 todos los usuarios tuvieran el mismo soporte para JavaScript porque los usuarios podían estar utilizando diferentes navegadores con distintos niveles de soporte (especialmente las versiones antiguas de Internet Explorer). Si los desarrolladores querían utilizar la nueva sintaxis (por ejemplo, class A {}), los usuarios de los navegadores antiguos sólo obtendrían una pantalla en blanco debido al SyntaxError.

Babel proporcionaba una forma de que los desarrolladores utilizaran la sintaxis más reciente de JavaScript, al tiempo que les permitía no preocuparse de cómo hacerla compatible con los usuarios traduciéndola (class A {} a var A = function A() {}).

Debido a su capacidad para transformar el código JavaScript, también puede utilizarse para implementar nuevas características: así se ha convertido en un puente para ayudar al TC39 (el comité que especifica el lenguaje JavaScript) a obtener comentarios sobre las ideas propuestas para JavaScript y para que la comunidad pueda opinar sobre el futuro del lenguaje.

Babel es fundamental para el desarrollo de JavaScript hoy en día. Actualmente hay más de 1,3 millones de repos dependientes en GitHub, 17 millones de descargas en npm al mes, y cientos de usuarios incluyendo muchos de los principales frameworks (React, Vue, Ember, Polymer), y empresas (Facebook, Netflix, Airbnb). Se ha convertido en una base tan importante para el desarrollo de JavaScript que mucha gente ni siquiera sabe que se está utilizando. Incluso si no lo estás usando, es muy probable que tus dependencias estén usando Babel.

Los mantenedores son personas

Babel tiene una enorme influencia no sólo en el futuro del lenguaje en sí, sino también en su comunidad y ecosistema. Pero incluso con toda esta responsabilidad, Babel es sólo un proyecto impulsado por la comunidad por un par de voluntarios.

Sólo este año pasado algunos del equipo fueron capaces de reunirse por primera vez en persona:

El equipo original de @babeljs, por fin juntos. De izquierda a derecha: @left_pad, @jamiebuilds, @sebmck, un servidor y @loganfsmyth pic.twitter.com/XfPj6OhZfA

– Amjad Masad (@amasad) May 3, 2018

Por mucho que este sea un post de anuncio, me gustaría aprovechar para recordar a todos el estado de este proyecto.

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

Como muchos mantenedores, tropezamos accidentalmente con el papel. Muchos de nosotros no teníamos ninguna formación formal sobre cómo funcionaban los compiladores o cómo mantener un proyecto de código abierto. Irónicamente, incluso evité a propósito especializarme en Ciencias de la Computación en la universidad porque no quería tomar clases sobre compiladores ni nada de bajo nivel porque me parecía poco interesante y difícil. Sin embargo, me sentí atraído por las herramientas, los linters, Babel y JavaScript como lenguaje.

Me gustaría animar a todo el mundo a investigar los proyectos de código abierto de los que depende y apoyarlos (tanto con tiempo como con apoyo monetario si es posible).

Muchos mantenedores no son intrínsecamente expertos en las cosas en las que trabajan; y hay mucho que lograr con sólo empezar el trabajo primero. Llegarás con curiosidad y humildad, ambos son grandes atributos para tener como mantenedor. Mi deseo es una esperanza para la visión del proyecto frente a sólo todos nosotros haciendo «tareas».

Babel no es una empresa, o un equipo de código abierto en una gran empresa como Facebook. Sólo hay un puñado de voluntarios trabajando en Babel, y sólo han pasado unos meses desde que di el salto para dejar mi trabajo y ser el único hasta ahora que trabaja en código abierto a tiempo completo. Pero la gente puede ir y venir, tener vidas fuera de este «hobby», criar familias, pasar a otras cosas, cambiar de trabajo o estar buscando trabajo, 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 podemos mantener 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 se ha apoderado claramente del software, ¿podemos considerar realmente que está en un estado saludable sin tener en cuenta a las personas que hay detrás?

#BabelSponsorsEverything

Tips 4 @babeljs at @ReactRally #BabelSponsorsEverything pic.twitter.com/WCxefMOC8V

– Harry Wolff (@hswolff) August 17, 2018

La sostenibilidad del Open Source se siente como si se diera una cesta de ofrendas en este momento. No es difícil afirmar el valor que los proyectos aportan a las miles de personas y empresas que utilizan el código abierto, pero sin embargo no vemos que ese valor se muestre a los pocos que están dispuestos a ponerlo en práctica. Puede haber muchas maneras de apoyar el código abierto y, sin embargo, no todos los enfoques funcionan para cada proyecto o personas.

¡Ahora vamos a los cambios!

Cambios importantes de ruptura

Los estamos documentando en nuestra Guía de Migración. Muchos de estos cambios se pueden hacer de forma automática con nuestra nueva herramienta babel-upgrade, o se pueden añadir en el futuro.

  • Suprimir el soporte para las versiones de Node no mantenidas: 0.10, 0.12, 4, 5 (detalles)
  • Movernos al espacio de nombres @babelpasando a usar paquetes «scoped» (detalles). Esto ayuda a diferenciar los paquetes oficiales, por lo que babel-core se convierte en @babel/core (y no en cuclillas)
  • Elimina (y deja de publicar) cualquier preset anual (preset-es2015, etc) (detalles). @babel/preset-env reemplaza la necesidad de estos, ya que incluye todas las adiciones anuales, así como la capacidad de dirigirse a un conjunto específico de navegadores
  • También eliminar los preajustes de «Etapa» (@babel/preset-stage-0, etc) en favor de optar en las propuestas individuales. Del mismo modo, eliminar las propuestas de @babel/polyfill por defecto (detalles). Por favor, considere la lectura de todo el post sobre esto para más explicación.
  • Algunos paquetes han cambiado de nombre: cualquier plugin de propuesta TC39 ahora será -proposal en lugar de -transform (detalles). Así que @babel/plugin-transform-class-properties se convierte en @babel/plugin-proposal-class-properties.
  • Introduce un peerDependency en @babel/core para ciertos paquetes de cara al usuario (por ejemplo, babel-loader, @babel/cli, etc) (detalles)

babel-upgrade

babel-upgrade es una nueva herramienta que hemos iniciado que trata de hacer automáticamente los cambios de actualización: actualmente con dependencias en package.json y .babelrc config.

Recomendamos ejecutarlo directamente en un repo git con npx babel-upgrade, o puedes instalarlo globalmente con npm i babel-upgrade -g.

Si quieres modificar los archivos, puedes pasar --write así como --install.

npx babel-upgrade --write --install

¡Por favor, considera contribuir reportando problemas o PRs para ayudar a todos en la transición a Babel 7! Una esperanza para el futuro es que utilizamos esta misma herramienta para todos los futuros cambios de ruptura y crear un bot a los proyectos de PR para actualizar.

Archivos de configuración de JavaScript

Estamos introduciendo babel.config.js. No es un requisito o incluso un reemplazo para .babelrc, pero tener esto puede ser útil en ciertos casos.

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

A continuación se presenta el caso de compilar sólo con un plugin en «producción» (ya se puede hacer con la opción "env" en un archivo .babelrc):

var env = process.env.NODE_ENV;module.exports = { plugins: .filter(Boolean)};

babel.config.js tiene una resolución de config diferente a la de un .babelrc. Siempre resolverá la configuración de ese archivo, mientras que originalmente Babel hacía una búsqueda de cada archivo hacia arriba hasta encontrar una configuración. Esto permite aprovechar la siguiente característica publicada a continuación, overrides.

Configuración selectiva con overrides

Recientemente, publiqué un post con reflexiones tanto sobre la publicación de paquetes ES2015+ como sobre el consumo/compilación de los mismos.

Hay una sección que profundiza en el uso de una nueva clave en el config de Babel llamada overrides que permite especificar diferentes configs por glob.

module.exports = { presets: , overrides: , presets: , }, { test: , presets: , }]};

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

Velocidad 🏎

¡Babel en sí mismo es más rápido por lo que debería tomar menos tiempo para construir! Hemos hecho un montón de cambios para optimizar el código, así como aceptar los parches del equipo v8. Estamos contentos de formar parte del Web Tooling Benchmark junto a muchas otras grandes herramientas de JavaScript.

Opciones de salida

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

{ "plugins": , ]}

¡Hemos hecho algunos cambios en la opción loose de algunos plugins y hemos añadido algunas opciones nuevas para otros! Tenga en cuenta que al usar estas opciones está optando por un comportamiento que no cumple con las especificaciones y debe saber lo que está haciendo; esto puede convertirse en un problema cuando se deja de compilar para usar la sintaxis de forma nativa. Este tipo de opciones se utilizan mejor en una biblioteca, si es que se utilizan.

  • Para las clases, class A {} ahora no incluirá el ayudante classCallCheck.
class A {}
var A = function A() {- _classCallCheck(this, A);};
  • Hay una nueva opción si cada uso de un bucle for-of es sólo un array: 
let elm;for (elm of array) { console.log(elm);}
let elm;for (let _i = 0, _array = array; _i < _array.length; _i++) { elm = _array; 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.

Nótese que el comportamiento por defecto es ser tan compatible con las especificaciones como sea posible para que el cambio de Babel o el uso de preset-env sea perfecto frente a permitir una salida más pequeña sólo para ahorrar bytes (hay un compromiso que cada proyecto puede hacer). Planeamos trabajar en mejores documentos y herramientas para hacer esto más fácil.

Soporte de anotaciones «puras»

Después de #6209, las clases transpiladas de ES6 están anotadas con un comentario /*#__PURE__*/ que permite dar una pista a los minificadores como Uglify y babel-minify para la eliminación de código muerto. Estas anotaciones se añaden a otras funciones de ayuda también.

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

Podría haber más oportunidades para las sugerencias y optimizaciones de los minificadores, ¡háganoslo saber!

Sintaxis

Apoyo a las propuestas del TC39

Me gustaría reiterar que hemos eliminado los preajustes de la Etapa en favor de una política de pedir a los usuarios a optar explícitamente en las propuestas < Etapa 4.

La preocupación es que estamos optando automáticamente a la gente en la sintaxis que no es fija o hecha con la expectativa de que no va a cambiar. Pero este no es el caso, especialmente para las propuestas que están en la etapa 0 o 1. Este post explica un poco sobre el tipo de pensamiento detrás de las ideas más nuevas.

Aquí hay una pequeña lista de algunas de las nuevas sintaxis que soporta Babel (ten en cuenta que este conjunto de características es un objetivo en movimiento que podría ser añadido/eliminado/instalado) y cuáles se han añadido en la v7:

  • ES2018: Object Rest Spread (var a = { b, ...c })
  • ES2018 (nuevo): Regex de propiedades Unicode
  • ES2018 (nuevo): JSON Superset
  • ES2015 (nuevo): new.target
  • Etapa 3 (nueva): Class Private Instance Fields (class A { #b = 2 })
  • Stage 3 (WIP): Campos estáticos de clase, métodos estáticos privados (class A { static #a() {} })
  • Etapa 3 (nueva): Optional Catch Binding try { throw 0 } catch { do() }
  • Etapa 3 (nueva): BigInt (sólo sintaxis)
  • Etapa 3: Importación dinámica (import("a"))
  • Etapa 2 (nueva): import.meta (sólo sintaxis) (import.meta.url)
  • Etapa 2 (nueva): Separadores numéricos (1_000)
  • Etapa 2 (nueva): function.sent
  • Etapa 2: export-namespace-from (export * as ns from 'mod'), dividida de export-extensions
  • Etapa 2: Decoradores. Compruebe a continuación para una actualización de nuestro progreso!
  • Etapa 1: export-default-from (export v from 'mod'), dividido de export-extensions
  • Etapa 1 (nueva): Encadenamiento opcional (a?.b)
  • Etapa 1 (nueva): Operadores de asignación lógica (a &&= b; a ||= b)
  • Etapa 1 (nueva): Operador de coalescencia nula (a ?? b)
  • Etapa 1 (nueva): Operador de tuberías (a |> b)
  • Etapa 1 (nueva): Throw Expressions (() => throw new Error("a"))

Es difícil para cualquiera hacer un seguimiento de todas las propuestas, así que intentamos hacerlo en babel/proposals.

Soporte de TypeScript (@babel/preset-typescript)

Trabajamos con el equipo de TypeScript en conseguir que Babel analice/transforme la sintaxis de tipos con @babel/preset-typescript, de forma similar a como manejamos Flow con @babel/preset-flow.

Para más detalles, consulta este post 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 (sin tipos):

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

Tanto Flow como Typescript son herramientas que permiten a los usuarios de JavaScript aprovechar las ventajas de la tipificación gradual, y nos gustaría habilitar ambas en Babel. Tenemos la intención de seguir trabajando estrechamente con sus respectivos equipos en FB y Microsoft (además de la comunidad en general) para mantener la compatibilidad y el apoyo a las nuevas características.

Esta integración es bastante nueva, por lo que es posible que alguna sintaxis no sea totalmente compatible. Apreciaríamos su ayuda para reportar problemas y tal vez enviar un PR!

Soporte de fragmentos JSX (<>)

Como se menciona en el blog de React, el soporte de fragmentos JSX ha estado disponible a partir de beta.31.

render() { return ( <> <ChildA /> <ChildB /> </> );}// output 👇render() { return React.createElement( React.Fragment, null, React.createElement(ChildA, null), React.createElement(ChildB, null) );}

Cambios en los ayudantes de Babel

El PR de babel-upgrade está en curso

@babel/runtimese ha dividido en @babel/runtime y @babel/runtime-corejs2 (PR). El primero sólo contiene las funciones de ayuda de Babel y el segundo contiene eso, así como cualquier función de polyfill (por ejemplo, Symbol, Promise).

Babel puede necesitar inyectar ciertas funciones en el código que puede reutilizar. A éstas las llamamos «funciones de ayuda» al igual que las funciones que se comparten entre módulos.

Un ejemplo de esto es con la compilación de un class (sin el modo loose activado):

La especificación dice que hay que llamar a una clase con new Person() pero si se compila a una función, técnicamente se podría hacer simplemente Person() así que incluimos una comprobación en tiempo de ejecución para esto.

class Person {}
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 sólo requerir las funciones modulares para permitir una salida más pequeña así:

var _classCallCheck = require("@babel/runtime/helpers/classCallCheck");var Person = function Person() { _classCallCheck(this, Person);};

Lo mismo se puede hacer con external-helpers y rollup-plugin-babel. Estamos estudiando si podemos hacer esto automáticamente en el futuro. Esté atento a un post independiente sobre los ayudantes de Babel pronto.

Polyfilling automático (experimental)

Los polyfills son necesarios para habilitar características como Promise, Symbol en entornos que no tienen soporte para ellos. Esto es importante a la hora de diferenciar entre lo que hace Babel como compilador (transforma la sintaxis) frente a un polyfill (implementa funciones/objetos incorporados).

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

import "@babel/polyfill";

Pero incluye todo el polyfill, y puede que no sea necesario 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 los polyfills. La opción useBuiltins: "entry" hace esto dividiendo la importación original en sólo las importaciones que son necesarias.

Pero podemos hacerlo mejor importando sólo los polyfills que se usan en el código base. La opción "useBuiltIns: "usage" es nuestro primer intento de habilitar algo así (docs).

Ejecutará a través de cada archivo e inyectará una importación en la parte superior de cada archivo si ese built-in es «utilizado» en el código. Por ejemplo:

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

La inferencia no es perfecta por lo que puede haber falsos positivos.

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

Otras ideas en este espacio son utilizar polyfill.io si estás bien con la dependencia de un servicio (o leer cómo Kent C. Dodds lo utilizó para construir un servicio alojado en PayPal).

Misc

Macros de Babel 🎣

Una de las mejores partes de Babel es la enchufabilidad de la herramienta. Con los años, Babel pasó de ser sólo un compilador «6to5» a una plataforma de transformación de código, permitiendo algunas optimizaciones fantásticas para la experiencia del usuario y del desarrollador. Toneladas de plugins de Babel han sido desarrollados para bibliotecas específicas y casos de uso para mejorar el rendimiento y las capacidades de las APIs de las bibliotecas que no serían posibles de otra manera (algunas «bibliotecas» son completamente transpiladas resultando en ningún tiempo de ejecución).

Desgraciadamente, añadir estos plugins a su base de código requiere cambiar la configuración (lo que algunos kits de herramientas como create-react-app no permiten) y añade complejidad a su código porque los desarrolladores tienen que saber qué plugins de Babel están operando en un archivo para saber qué pasará con el código que están escribiendo. Estos problemas han sido resueltos por babel-plugin-macros de Kent C. Dodds!

Una vez que babel-plugin-macros ha sido instalado y añadido a su configuración (está incluido en create-react-app v2), no necesita molestarse con su configuración para utilizar cualquier macros. Además, es aún más fácil escribir sus propias transformaciones personalizadas para casos de uso específicos de su aplicación o de una parte de su código.

Aprenda más sobre babel-plugin-macros en nuestro post original «Zero-config code transformation with babel-plugin-macros».

Module Targeting

Babel siempre ha intentado equilibrar el impacto del tamaño de las transformaciones y las capacidades que proporcionan a los autores de JavaScript. En Babel 7, se ha hecho mucho más fácil configurar Babel para soportar la creciente popularidad del patrón módulo/nomódulo.

En particular, varias herramientas CLI para frameworks web populares (1, 2) ya están aprovechando el soporte que conduce a una reducción de aproximadamente el 20% en el JavaScript enviado a los consumidores de aplicaciones transpiladas por Babel.

Metadatos de llamada y mejores valores por defecto

Hemos añadido una opción caller a @babel/core para que nuestras herramientas puedan pasar metadatos a los presets/plugins. Por ejemplo: babel-loader puede añadir algo así para que preset-env pueda desactivar automáticamente la transformación del módulo (lo mismo con rollup:

babel.transform("code;", { filename, presets: , caller: { name: "babel-loader", supportsStaticESM: true, },});

¡Esto es emocionante ya que permite una forma de que el tooling proporcione mejores valores predeterminados y menos configuración! Para el caso de webpack/rollup: podemos diferir automáticamente el uso de su transformación de módulo en lugar de la de Babel (lo mismo con import("a")). Esté atento a más herramientas para aprovechar esto en el futuro!

class C extends HTMLElement {} ¡

Una de nuestras cuestiones más antiguas recibe su propio título (detalles)

Babel siempre ha tenido la advertencia de que no podía soportar la extensión de los build-ins nativos (Array, Error, etc) y ahora puede! Hemos recibido un montón de problemas acerca de esto; 🎉 ¡deberías celebrarlo como Andrea!

Este cambio se hizo en el plugin de clases por lo que debería estar automáticamente habilitado si estás usando preset-env.

Cambios en el sitio web 🌏

¡Hemos movido nuestro sitio de Jekyll a Docusaurus!

Todavía estamos en el proceso de configurar las traducciones con Crowdin, y con Babel 7 fuera, estaremos en un mejor lugar para comenzar ese proceso.

REPL

Hemos reescrito el REPL como un componente de React, y hemos estado trabajando con Ives en la integración mejor con CodeSandbox. Esto permite instalar cualquier plugin o preset de npm en el REPL, así como obtener cualquier actualización que CodeSandbox obtenga.

¡Volvemos a participar en el Rails Girls Summer of Code! Esta vez, Gyujin y Sujin han estado trabajando duro para integrar el babel-time-travel de Boopathi en la REPL, que ya se puede probar ahora.

¡Hay tantas oportunidades de participar para hacer que Babel, ASTs y otras herramientas funcionen mejor!

Tenemos una canción 🎶

Hallelujah-In Praise of Babel

Un día, Angus nos cedió amablemente una canción que me pareció increíble, así que ¿por qué no hacerla nuestra canción «oficial»? Y Shawn hizo una brillante portada aquí.

Puedes encontrarla en nuestro repo en SONG.md. Esperamos ver que otros proyectos sigan esto.

¿Qué es lo siguiente?

  • Babel está intrínsecamente ligado a lo que compila: JavaScript. Mientras haya nuevas adiciones que proponer/trabajar hay trabajo que hacer allí. Eso incluye el tiempo/esfuerzo de implementar y mantener la sintaxis incluso antes de que sea «estable». Nos preocupamos por todo el proceso: la ruta de actualización, la educación de las nuevas características, la enseñanza de los estándares/diseño del lenguaje, la facilidad de uso y la integración con otros proyectos.
    • Relación: casi hemos terminado de implementar la nueva propuesta de decoradores en Babel gracias a Nicolò. Ha sido un largo camino (¡ha tardado más de un año!) porque la nueva propuesta es completamente diferente y mucho más potente que la anterior, pero ya casi está 🎉. Puedes esperar que se publique en una de las próximas versiones menores, junto con una entrada en el blog que explicará los cambios en detalle.
  • Boopathi ha estado manteniendo diligentemente babel-minify, ¡así que haremos un 1.0 para eso a continuación!
  • Hay un montón de nuevas características en las obras: el orden de los plugins, mejor validación / errores, la velocidad, el replanteamiento de las opciones sueltas / spec, el almacenamiento en caché, el uso de Babel de forma asíncrona, la construcción contra sí mismo de CI, pruebas de humo, ejecutando test262. Echa un vistazo a esta hoja de ruta doc para algunas ideas más posibles!

No tenemos planes secretos: estamos tratando 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 llevar a cabo todas estas ideas y hacerlo bien. Pero como hemos demostrado con esta versión actual, las cosas tardan mucho más de lo esperado

¿Por qué tardan tanto estas versiones? ¿Es por el «feature creep», tanto de nosotros como de nuestros usuarios? ¿Es porque no entendemos cómo priorizar entre todas las cosas posibles para añadir o arreglar? ¿Decidimos arreglar la fruta que cuelga baja en lugar de los problemas fundamentales hasta el final? ¿O a las «distracciones» de ayudar a otros en GitHub, Slack, Twitter? ¿Sólo somos malos estimando nuestro tiempo, entendiendo las complejidades de estos problemas, comprometiéndonos demasiado como voluntarios?

¿O simplemente estamos poniendo una expectativa demasiado alta en nosotros mismos, o nos sentimos tan presionados por los demás para llevar a cabo y adaptarse a sus necesidades en detrimento de nosotros mismos? Sólo puedo describirlo como pavor cuando veo un mensaje de alguien en línea preguntando por qué algo no ha sido lanzado mientras otro pregunta por qué este error no está arreglado todavía. Quiero apresurarme y acabar con ello, pero también tengo el deseo de tomarme esto en serio.

He intentado expresar algunos de estos pensamientos y luchas en mi charla de la semana pasada en React Rally: Through the (Open Source) Looking Glass, que espero que puedas aprovechar la oportunidad de escuchar. La pregunta que me hago: ¿Qué puedo hacer con el inevitable ciclo de agotamiento de los mantenedores, la ansiedad constante y las expectativas poco realistas?

Como gran parte de la vida, las cosas que hacemos reflejan nuestro carácter y nos muestran cómo somos realmente. Las acciones que realizamos pueden en sí mismas cambiarnos, para bien o para mal. Si nos tomamos en serio nuestro trabajo, deberíamos hacernos responsables de estos hábitos que parecen tan arraigados en nuestra cultura: de la gratificación instantánea, del éxito en términos de métricas, del derecho frente a la gratitud y del orgullo de trabajar en exceso.

Pero a pesar de todo, trabajar para esta liberación ha merecido tanto la pena.

Gracias

Este es un lanzamiento realmente emocionante, no sólo por mirar hacia atrás en lo que hemos logrado y habilitado, pero mucho más por saber cuánto tiempo y corazón se puso en hacer que suceda en el último año. Es difícil de creer las oportunidades y experiencias que han sucedido a lo largo del camino: interactuar con y ayudar a las empresas de todo el mundo, encontrar amigos en casi cualquier ciudad que he visitado, y hablar con honestidad sobre el increíble viaje que este grupo ha emprendido juntos.

Personalmente, nunca he puesto tanto de mi energía mental en algo de esta magnitud y me gustaría dar las gracias a tanta gente por levantarnos a lo largo del camino. Agradezco especialmente a Logan Smyth, que ha dedicado mucho tiempo a cambiar gran parte del funcionamiento del núcleo y siempre se toma el tiempo para ayudarnos en nuestro Slack mientras trabaja como freelance, y a Brian Ng, que ha dado un gran paso para seguir manteniendo Babel y revisando todas mis publicaciones en el blog y las charlas. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo, y Justin Ridgewell han sido fundamentales para hacer esta versión posible y agradable de trabajar.

Saludos a todos los muchos miembros de la comunidad en Slack, Twitter, y en todos los proyectos en GitHub que también tienen que entender lo que estamos haciendo por sus propios usuarios. Me gustaría dar un enorme agradecimiento a mis amigos de Behance/Adobe por patrocinarme durante casi un año para trabajar en Babel a media jornada antes de decidirme a trabajar a tiempo completo (además de ayudar a probar Babel 7 en producción durante todo el tiempo que estuve allí). Muchas gracias a todos los patrocinadores de nuestro Open Collective, especialmente a Trivago y Handshake. Y gracias a nuestros amigos y familia por todo su amor y apoyo.

Todos estamos bastante cansados en este punto, pero ha sido realmente un honor y un privilegio servir de esta manera, así que esperamos que aprecien el lanzamiento!