Babel 7 Released

BY admin
|

Après presque 2 ans, 4k commits, plus de 50 préversions, et beaucoup d’aide, nous sommes heureux d’annoncer la sortie de Babel 7. Cela fait presque 3 ans depuis la sortie de Babel 6 ! Il y a beaucoup de choses qui bougent, alors soyez indulgents avec nous pendant les premières semaines de la sortie. Babel 7 est une énorme version : nous l’avons rendu plus rapide, créé un outil de mise à niveau, des configs JS, des « surcharges » de configuration, plus d’options pour la taille/minification, des fragments JSX, TypeScript, de nouvelles propositions, et plus encore !

Si vous appréciez le travail que nous faisons sur Babel, vous pouvez sponsoriser Babel sur Open Collective, me soutenir sur Patreon, ou vous impliquer, vous ou votre entreprise, dans Babel dans le cadre du travail. Nous apprécierions la propriété collective de ce projet vital dans la communauté JavaScript !

C’est en train de se produire ! 🎉

Les logiciels ne seront jamais parfaits mais nous sommes prêts à expédier quelque chose qui est déjà utilisé en production depuis un certain temps maintenant ! @babel/core est déjà à 5,1 mil téléchargements/mois en raison de son utilisation dans des outils comme Next.js 6, vue-cli 3.0, React Native 0.56, et même le frontend de WordPress.com 🙂!

Le rôle de Babel

J’aimerais commencer ce post en réintroduisant le rôle de Babel dans l’écosystème JavaScript au cours des dernières années.

Le problème initial était que, contrairement aux langages serveurs, il n’y avait aucun moyen de garantir que chaque utilisateur dispose du même support pour JavaScript, car les utilisateurs pouvaient utiliser différents navigateurs avec des niveaux de support variables (notamment les anciennes versions d’Internet Explorer). Si les développeurs voulaient utiliser une nouvelle syntaxe (par exemple class A {}), les utilisateurs sur les anciens navigateurs obtiendraient simplement un écran vide en raison de la SyntaxError.

Babel a fourni un moyen pour les développeurs d’utiliser la dernière syntaxe JavaScript tout en leur permettant de ne pas se soucier de la façon de la rendre rétrocompatible pour leurs utilisateurs en la traduisant (class A {} en var A = function A() {}).

En raison de sa capacité à transformer le code JavaScript, il peut également être utilisé pour mettre en œuvre de nouvelles fonctionnalités : il est ainsi devenu un pont pour aider le TC39 (le comité qui spécifie le langage JavaScript) à obtenir des commentaires sur les idées JavaScript proposées et pour que la communauté ait son mot à dire sur l’avenir du langage.

Babel est fondamental pour le développement JavaScript aujourd’hui. Il y a actuellement plus de 1,3 million de dépôts dépendants sur GitHub, 17 millions de téléchargements sur npm par mois, et des centaines d’utilisateurs, y compris de nombreux frameworks majeurs (React, Vue, Ember, Polymer), et des entreprises (Facebook, Netflix, Airbnb). Il est devenu une telle fondation pour le développement JavaScript que beaucoup de gens ne savent même pas qu’il est utilisé. Même si vous ne l’utilisez pas vous-même, il est fort probable que vos dépendances utilisent Babel.

Les mainteneurs sont des personnes

Babel a une énorme influence non seulement sur l’avenir du langage lui-même, mais aussi sur sa communauté et son écosystème. Mais même avec toute cette responsabilité, Babel n’est qu’un projet dirigé par la communauté par un couple de volontaires.

C’est seulement l’année dernière que certains membres de l’équipe ont pu se rencontrer pour la première fois en personne :

L’équipe originale de @babeljs, enfin ensemble. De gauche à droite : @left_pad, @jamiebuilds, @sebmck, votre serviteur, et @loganfsmyth pic.twitter.com/XfPj6OhZfA

– Amjad Masad (@amasad) 3 mai 2018

Tout autant que ce soit un post d’annonce, j’aimerais profiter de l’occasion pour rappeler à tous l’état de ce projet.

Je me suis moi-même joint quelques mois avant la sortie de la version 6.0, qui a eu sa propre quantité de controverse et de contrecoup. Une grande partie de la réception là-bas a conduit à l’épuisement des mainteneurs existants (y compris Sebastian, le créateur de Babel) et quelques-uns d’entre nous qui restaient ont pris les rênes.

Comme beaucoup de mainteneurs, nous avons accidentellement trébuché dans le rôle. Beaucoup d’entre nous n’avaient pas de formation formelle sur le fonctionnement des compilateurs ou sur la façon de maintenir un projet open source. Ironiquement, j’ai même délibérément évité de me spécialiser en informatique à l’université parce que je ne voulais pas prendre de cours sur les compilateurs ou tout autre sujet de bas niveau, car cela me semblait inintéressant et difficile. Pourtant, je me suis retrouvé attiré par l’outillage, les linters, Babel, et JavaScript en tant que langage.

J’aimerais encourager tout le monde à se pencher sur les projets open source dont vous dépendez et à les soutenir (à la fois avec du temps et un soutien monétaire si possible).

De nombreux mainteneurs ne sont pas intrinsèquement des experts dans les choses sur lesquelles ils travaillent ; et il y a beaucoup à accomplir en commençant simplement le travail en premier. Vous arriverez avec à la fois de la curiosité et de l’humilité, qui sont deux grands attributs à avoir en tant que mainteneur. Mon désir est un espoir pour la vision du projet par rapport à juste nous tous faisant des « tâches ».

Babel n’est pas une entreprise, ou une équipe open source dans une grande entreprise comme Facebook. Il n’y a qu’une poignée de volontaires qui travaillent sur Babel, et cela ne fait que quelques mois que j’ai fait le saut pour quitter mon emploi et être le seul jusqu’à présent à travailler sur l’open source à plein temps. Mais les gens peuvent aller et venir, avoir une vie en dehors de ce « hobby », élever une famille, passer à d’autres choses, changer d’emploi ou en chercher un, etc. Faisons-nous collectivement ce que nous pouvons pour maintenir les choses qui sont si fondamentales à notre façon de travailler, ou allons-nous laisser les fondations s’effriter lentement ? Comment faire pour que l’open source reste accueillant et inclusif, mais avec des limites claires ? Pouvons-nous apprendre des expériences des autres mainteneurs ?

Bien que l’Open Source ait clairement pris le dessus sur les logiciels, pouvons-nous vraiment considérer qu’il est dans un état sain sans prendre en compte les personnes derrière ?

#BabelSponsorsEverything

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

– Harry Wolff (@hswolff) 17 août 2018

La durabilité de l’Open Source ressemble à la distribution d’un panier d’offrandes en ce moment. Il n’est pas difficile d’énoncer la valeur que les projets apportent aux milliers de personnes et d’entreprises qui utilisent l’open source, mais pourtant nous ne voyons pas cette valeur se manifester pour les quelques personnes qui sont prêtes à faire le travail. Il peut y avoir tellement de façons de soutenir l’open source et pourtant toutes les approches ne fonctionnent pas pour chaque projet ou chaque personne.

Maintenant passons aux changements !

Modifications majeures de rupture

Nous les documentons dans notre guide de migration. Beaucoup de ces changements peuvent être effectués automatiquement avec notre nouvel babel-upgrade outil, ou peuvent être ajoutés à l’avenir.

  • Supporter le support des versions non maintenues de Node : 0.10, 0.12, 4, 5 (détails)
  • Nous déplacer vers l’espace de nom @babel en passant à l’utilisation de paquets « scoped » (détails). Cela permet de différencier les paquets officiels, ainsi babel-core devient @babel/core (et pas de squat)
  • Supprimez (et arrêtez de publier) tout préréglage annuel (preset-es2015, etc) (détails). @babel/preset-env remplace le besoin de ceux-ci car il comprend tous les ajouts annuels ainsi que la possibilité de cibler un ensemble spécifique de navigateurs
  • Aussi abandonner les préréglages « Stage » (@babel/preset-stage-0, etc) en faveur de l’opting dans les propositions individuelles. De même, supprimer les propositions de @babel/polyfill par défaut (détails). S’il vous plaît envisager de lire l’ensemble du post sur ce sujet pour plus d’explications.
  • Certains paquets ont des renoms : tout plugin de proposition TC39 sera maintenant -proposal au lieu de -transform (détails). Ainsi @babel/plugin-transform-class-properties devient @babel/plugin-proposal-class-properties.
  • Introduire un peerDependency sur @babel/core pour certains paquets faisant face à l’utilisateur (par exemple babel-loader, @babel/cli, etc) (détails)

babel-upgrade

babel-upgrade est un nouvel outil que nous avons commencé qui essaie de faire automatiquement des changements de mise à niveau : actuellement avec des dépendances dans package.json et .babelrc config.

Nous recommandons de l’exécuter directement sur un repo git avec npx babel-upgrade, ou vous pouvez l’installer globalement avec npm i babel-upgrade -g.

Si vous souhaitez modifier les fichiers, vous pouvez passer --write ainsi que --install.

npx babel-upgrade --write --install

Veuillez envisager de contribuer en signalant des problèmes ou des PR pour aider tout le monde à passer à Babel 7 ! Un espoir pour l’avenir est que nous utilisons ce même outil pour tous les futurs changements de rupture et de créer un bot pour PR projets à mettre à jour.

Fichiers de configuration JavaScript

Nous introduisons babel.config.js. Ce n’est pas une exigence ou même un remplacement pour .babelrc, mais avoir cela peut être utile dans certains cas.

*.js fichiers de configuration sont assez communs dans l’écosystème JavaScript. ESLint et Webpack autorisent tous deux les fichiers de configuration .eslintrc.js et webpack.config.js, respectivement.

Voici le cas de la compilation uniquement avec un plugin en « production » (vous pouvez déjà le faire avec l’option "env" dans un fichier .babelrc):

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

babel.config.js a une résolution de config différente de celle d’un .babelrc. Il résoudra toujours la configuration de ce fichier, alors qu’à l’origine, Babel effectuait une recherche à partir de chaque fichier vers le haut jusqu’à ce qu’il trouve une configuration. Cela permet de tirer parti de la prochaine fonctionnalité postée ci-dessous, overrides.

Configuration sélective avec des surcharges

Récemment, j’ai publié un post avec des réflexions à la fois sur la publication des paquets ES2015+ et aussi sur leur consommation/compilation.

Il y a une section qui va dans l’utilisation d’une nouvelle clé dans la configuration de Babel appelée overrides qui vous permet de spécifier différentes configs par glob.

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

Cela permet à une application qui nécessite des configurations de compilation différentes pour ses tests, son code client et son code serveur de ne pas avoir à créer un nouveau fichier .babelrc par dossier.

Vitesse 🏎

Babel lui-même est plus rapide, il devrait donc prendre moins de temps à construire ! Nous avons fait beaucoup de changements pour optimiser le code ainsi que pour accepter les correctifs de l’équipe v8. Nous sommes heureux de faire partie du Web Tooling Benchmark aux côtés de nombreux autres grands outils JavaScript.

Options de sortie

Babel supporte les options de préréglage et de plugin depuis un certain temps maintenant. Pour récapituler, vous pouvez envelopper le plugin dans un tableau et passer un objet d’options au plugin :

{ "plugins": , ]}

Nous avons apporté quelques modifications à l’option loose de certains plugins et ajouté de nouvelles options pour d’autres ! Notez qu’en utilisant ces options, vous optez pour un comportement non conforme aux spécifications et devez savoir ce que vous faites ; cela peut devenir un problème lorsque vous désactivez la compilation pour utiliser la syntaxe de manière native. Ces types d’options sont mieux utilisés dans une bibliothèque, si c’est le cas.

  • Pour les classes, class A {} n’inclura désormais pas l’aide classCallCheck.
class A {}
var A = function A() {- _classCallCheck(this, A);};
  • Il y a une nouvelle option si chaque utilisation d’une boucle for-of est juste un tableau : 
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);}
  • Nous excluons le plugin transform-typeof-symbol en mode loose pour preset-env #6831

Nous avons trouvé beaucoup de bibliothèques qui le font déjà, donc nous avons décidé de le faire par défaut.

Notez que le comportement par défaut est d’être aussi conforme à la spécification que possible afin que la commutation hors de Babel ou l’utilisation de preset-env soit transparente par rapport à l’autorisation d’une sortie plus petite juste pour économiser des octets (il y a un compromis là que chaque projet peut faire). Nous prévoyons de travailler sur de meilleures docs et outils pour rendre cela plus facile.

Support des annotations « pures »

Après #6209, les classes ES6 transpilées sont annotées avec un commentaire /*#__PURE__*/ qui permet de donner un indice aux minifieurs comme Uglify et babel-minify pour l’élimination du code mort. Ces annotations sont ajoutées à d’autres fonctions d’aide également.

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

Il pourrait y avoir plus d’opportunités pour les indices de minage et les optimisations, faites-nous le savoir !

Syntaxe

Support des propositions du TC39

J’aimerais réitérer que nous avons supprimé les préréglages de l’étape en faveur d’une politique consistant à demander aux utilisateurs d’opter explicitement pour les propositions <de l’étape 4.

La préoccupation est que nous optons automatiquement les gens pour une syntaxe qui n’est pas fixée ou faite avec l’espoir qu’elle ne changera pas. Mais ce n’est pas le cas, surtout pour les propositions qui sont au stade 0 ou 1. Ce post explique un peu le type de réflexion derrière les idées plus récentes.

Voici une petite liste de certaines des nouvelles syntaxes que Babel supporte (gardez à l’esprit que cet ensemble de fonctionnalités est une cible mobile qui pourrait être ajoutée/supprimée/stallée) et lesquelles ont été ajoutées dans la v7:

  • ES2018 : Étalement du repos des objets (var a = { b, ...c })
  • ES2018 (nouveau) : Regex de propriétés Unicode
  • ES2018 (nouveau) : JSON Superset
  • ES2015 (nouveau) : new.target
  • Étape 3 (nouvelle) : Champs d’instance privés de classe (class A { #b = 2 })
  • Etape 3 (WIP) : Champs statiques de classe, méthodes statiques privées (class A { static #a() {} })
  • Étape 3 (nouvelle) : Optional Catch Binding try { throw 0 } catch { do() }
  • Étape 3 (nouvelle) : BigInt (syntaxe uniquement)
  • Étape 3 : Importation dynamique (import("a"))
  • Étape 2 (nouvelle) : import.meta (syntaxe uniquement) (import.meta.url)
  • Etape 2 (nouvelle) : Séparateurs numériques (1_000)
  • Etape 2 (nouvelle) : function.sent
  • Etape 2 : export-namespace-from (export * as ns from 'mod'), séparé de export-extensions
  • Etape 2 : Décorateurs. Regardez ci-dessous pour une mise à jour de nos progrès!
  • Etape 1 : export-default-from (export v from 'mod'), scindé de export-extensions
  • Étape 1 (nouvelle) : Chaînage optionnel (a?.b)
  • Etape 1 (nouvelle) : Opérateurs d’assignation logique (a &&= b; a ||= b)
  • Etape 1 (nouvelle) : Opérateur de coalescence nulle (a ?? b)
  • Étape 1 (nouvelle) : Opérateur de pipelines (a |> b)
  • Etape 1 (nouvelle) : Throw Expressions (() => throw new Error("a"))

Il est difficile pour quiconque de garder une trace de toutes les propositions, donc nous tentons de le faire à babel/proposals.

Support TypeScript (@babel/preset-typescript)

Nous avons travaillé avec l’équipe TypeScript pour que Babel puisse analyser/transformer la syntaxe de type avec @babel/preset-typescript, de manière similaire à la façon dont nous gérons Flow avec @babel/preset-flow.

Pour plus de détails, consultez ce post de l’équipe TypeScript !

Avant (avec types):

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

Après (types supprimés):

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

Flux et Typescript sont tous deux des outils qui permettent aux utilisateurs de JavaScript de profiter du typage progressif, et nous aimerions activer les deux dans Babel. Nous prévoyons de continuer à travailler étroitement avec leurs deux équipes respectives chez FB et Microsoft (en plus de la communauté dans son ensemble) pour maintenir la compatibilité et supporter les nouvelles fonctionnalités.

Cette intégration est assez récente, il est donc possible que certaines syntaxes ne soient pas entièrement supportées. Nous apprécierions votre aide pour signaler les problèmes et peut-être envoyer un PR !

Support des fragments JSX (<>)

Comme mentionné dans le React Blog, le support des fragments JSX est disponible depuis beta.31.

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

Changements dans les aides Babel

Le PR babel-upgrade est en cours

@babel/runtime a été divisé en @babel/runtime et @babel/runtime-corejs2 (PR). Le premier contient uniquement les fonctions d’aide de Babel et le second contient cela ainsi que toutes les fonctions polyfill (par exemple Symbol, Promise).

Babel peut avoir besoin d’injecter certaines fonctions dans le code qui peut être réutilisé. Nous les appelons simplement « fonctions d’aide » tout comme les fonctions qui sont partagées entre les modules.

Un exemple de ceci est avec la compilation d’un class (sans le mode loose activé) :

La spécification dit que vous devez appeler une classe avec new Person() mais si elle est compilée en une fonction, vous pourriez techniquement juste faire Person() donc nous incluons une vérification à l’exécution pour cela.

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);};

Avec @babel/plugin-transform-runtime et @babel/runtime (comme dépendance), Babel peut extraire les fonctions individuelles et juste exiger les fonctions modulaires pour permettre une sortie plus petite comme ceci:

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

La même chose peut être faite avec external-helpers et rollup-plugin-babel. Nous cherchons à voir si nous pouvons le faire automatiquement à l’avenir. Recherchez un post autonome sur les aides de Babel bientôt.

Polyfilling automatique (expérimental)

Les polyfills sont nécessaires pour activer des fonctionnalités comme Promise, Symbol dans des environnements qui n’ont pas de support pour eux. Ceci est important lorsqu’il s’agit de différencier ce que Babel fait en tant que compilateur (transforme la syntaxe) par rapport à un polyfill (implémente des fonctions/objets intégrés).

Il est assez facile de simplement importer quelque chose qui couvre tout comme @babel/polyfill:

import "@babel/polyfill";

Mais cela inclut l’ensemble du polyfill, et vous n’avez peut-être pas besoin de tout importer si les navigateurs le supportent déjà. C’est le même problème que @babel/preset-env essaie de résoudre avec la syntaxe, donc nous l’appliquons ici avec les polyfills. L’option useBuiltins: "entry" fait cela en divisant l’importation originale en seulement les importations qui sont nécessaires.

Mais nous pouvons faire mieux en important seulement les polyfills qui sont utilisés dans la base de code. L’option "useBuiltIns: "usage" est notre première tentative pour activer quelque chose comme ça (docs).

Il va parcourir chaque fichier et injecter un import en haut de chaque fichier si cet intégré est « utilisé » dans le code. Par exemple :

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

L’inférence n’est pas parfaite donc il peut y avoir des faux positifs.

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

Les autres idées dans cet espace sont d’utiliser polyfill.io si vous êtes ok pour vous reposer sur un service (ou lisez comment Kent C. Dodds l’a utilisé pour construire un service hébergé chez PayPal).

Misc

Macros Babel 🎣

L’une des meilleures parties de Babel est la pluggabilité de l’outil. Au fil des années, Babel est passé d’un simple compilateur « 6to5 » à une plateforme de transformation de code, permettant des optimisations fantastiques pour l’expérience des utilisateurs et des développeurs. Des tonnes de plugins Babel ont été développés pour des bibliothèques et des cas d’utilisation spécifiques afin d’améliorer les performances et les capacités des API des bibliothèques, ce qui ne serait pas possible autrement (certaines « bibliothèques » sont complètement transpilées, ce qui entraîne l’absence totale de runtime).

Malheureusement, l’ajout de ces plugins à votre codebase nécessite de modifier la configuration (ce que certaines boîtes à outils comme create-react-app ne permettent pas) et cela ajoute de la complexité à votre code, car les développeurs doivent savoir quels plugins Babel fonctionnent sur un fichier pour savoir ce qui va arriver au code qu’ils écrivent. Ces problèmes ont été résolus par babel-plugin-macros de Kent C. Dodds!

Une fois que babel-plugin-macros a été installé et ajouté à votre configuration (il est inclus dans create-react-app v2), vous n’avez pas besoin de vous embêter avec votre configuration pour utiliser des macros. En outre, il est encore plus facile d’écrire vos propres transformations personnalisées pour des cas d’utilisation spécifiques à votre application ou à une partie de votre code.

En savoir plus sur babel-plugin-macros dans notre post original « Zero-config code transformation with babel-plugin-macros ».

Module Targeting

Babel a toujours tenté d’équilibrer l’impact de taille des transformations et les capacités qu’elles fournissent aux auteurs JavaScript. Dans Babel 7, il est devenu beaucoup plus facile de configurer Babel pour supporter la popularité croissante du pattern module/nomodule.

Notamment, plusieurs outils CLI pour des frameworks web populaires (1, 2) tirent déjà parti du support conduisant à une réduction d’environ 20% du JavaScript expédié aux consommateurs d’applications transposées par Babel.

Métadonnées des appelants et meilleurs défauts

Nous avons ajouté une option caller à @babel/core afin que notre outillage puisse passer des métadonnées aux presets/plugins. Par exemple : babel-loader peut ajouter quelque chose comme ceci afin que preset-env puisse désactiver automatiquement la transformation du module (même chose avec rollup:

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

C’est excitant car cela permet un moyen pour l’outillage de fournir de meilleures valeurs par défaut et moins de configuration ! Pour le cas de webpack/rollup : nous pouvons automatiquement différer l’utilisation de leur transformation de module au lieu de celle de Babel (même chose avec import("a")). Regardez pour plus d’outils pour tirer parti de cela dans le futur!

classe C extends HTMLElement {}

L’un de nos plus anciens problèmes obtient sa propre rubrique (détails)

Babel a toujours eu la mise en garde où il ne pouvait pas supporter l’extension des built-ins natifs (Array, Error, etc) et maintenant il peut ! Nous avons reçu beaucoup de questions à ce sujet ; 🎉 vous devriez célébrer comme Andrea!

Ce changement a été fait au plugin de classe donc il devrait être automatiquement activé si vous utilisez preset-env.

Changements du site Web 🌏

Nous avons déplacé notre site de Jekyll à Docusaurus !

Nous sommes toujours dans le processus de mise en place des traductions avec Crowdin, et avec Babel 7 sorti, nous serons dans une meilleure position pour commencer ce processus.

REPL

Nous avons réécrit le REPL comme un composant React, et avons travaillé avec Ives sur une meilleure intégration avec CodeSandbox. Cela vous permet d’installer n’importe quel plugin ou preset de npm dans le REPL ainsi que d’obtenir toutes les mises à jour que CodeSandbox obtient.

Nous participons à nouveau au Rails Girls Summer of Code ! Cette fois, Gyujin et Sujin ont travaillé dur pour intégrer babel-time-travel de Boopathi dans le REPL, que vous pouvez déjà tester dès maintenant !

Il y a tellement d’opportunités ici pour s’impliquer afin que Babel, les AST et d’autres outils fonctionnent mieux !

Nous avons une chanson 🎶

Hallelujah-In Praise of Babel

Un jour, Angus nous a gracieusement transmis une chanson que je trouvais incroyable, alors pourquoi ne pas en faire notre chanson « officielle » ? Et Shawn a fait une reprise brillante ici.

Vous pouvez la trouver dans notre repo à SONG.md. Nous espérons voir d’autres projets s’en inspirer !

What’s Next?

  • Babel est intrinsèquement lié à ce qu’il compile : JavaScript. Tant qu’il y a de nouveaux ajouts à proposer/travailler, il y a du travail à faire là-dessus. Cela inclut le temps/effort pour implémenter et maintenir la syntaxe même avant qu’elle ne devienne « stable ». Nous nous soucions de l’ensemble du processus : le chemin de mise à niveau, l’éducation des nouvelles fonctionnalités, l’enseignement des normes/la conception du langage, la facilité d’utilisation et l’intégration avec d’autres projets.
    • Relatif : nous avons presque fini de mettre en œuvre la nouvelle proposition de décorateurs dans Babel grâce à Nicolò. Le chemin a été long (cela a pris plus d’un an !) car la nouvelle proposition est complètement différente et beaucoup plus puissante que l’ancienne, mais elle est presque là 🎉. Vous pouvez vous attendre à ce qu’elle soit publiée dans l’une des prochaines versions mineures, accompagnée d’un billet de blog qui expliquera les changements en détail.
  • Boopathi a maintenu avec diligence babel-minify, donc nous ferons une 1.0 pour cela ensuite !
  • Il y a beaucoup de nouvelles fonctionnalités en cours de réalisation : l’ordre des plugins, une meilleure validation/erreurs, la vitesse, repenser les options loose/spec, la mise en cache, l’utilisation de Babel de manière asynchrone, la construction contre elle-même à partir de CI, les tests smoke, l’exécution de test262. Consultez ce doc de feuille de route pour d’autres idées possibles !

Nous n’avons pas de plans secrets : nous essayons du mieux que nous pouvons avec ce que nous avons pour servir cette communauté.

L’Open Source est un miroir

J’adorerais que nous ayons le temps et les ressources pour accomplir toutes ces idées et pour le faire bien. Mais comme nous l’avons montré avec cette version actuelle, les choses prennent beaucoup plus de temps que prévu !

Pourquoi ces versions prennent-elles si longtemps de toute façon ? Est-ce à cause du creep de fonctionnalités, à la fois de nous-mêmes et de nos utilisateurs ? Est-ce parce que nous ne comprenons pas comment établir des priorités parmi toutes les choses possibles à ajouter ou à corriger ? La décision de réparer les fruits les plus faciles à cueillir plutôt que les problèmes fondamentaux jusqu’à la fin ? Ou des « distractions » pour aider les autres sur GitHub, Slack, Twitter ? Sommes-nous simplement mauvais dans l’estimation de notre temps, dans la compréhension de la complexité de ces problèmes, dans notre engagement excessif en tant que bénévoles ?

Ou sommes-nous simplement en train de fixer des attentes trop élevées pour nous-mêmes, ou nous sentons tellement sous la pression des autres pour performer et nous adapter à leurs besoins au détriment de nous-mêmes ? Je peux seulement décrire cela comme de l’effroi quand je vois un message de quelqu’un en ligne qui se demande pourquoi quelque chose n’a pas été publié alors qu’un autre demande pourquoi ce bug n’est pas encore corrigé. J’ai envie de le sortir en toute hâte et d’en finir, mais j’ai aussi le désir de prendre cela au sérieux.

J’ai essayé d’exprimer certaines de ces pensées et de ces luttes dans ma conférence la semaine dernière à React Rally : Through the (Open Source) Looking Glass, que j’espère que vous pourrez saisir l’occasion d’écouter. La question que je me pose : Que puis-je faire à propos du cycle inévitable de l’épuisement du mainteneur, de l’anxiété constante et des attentes irréalistes ?

Comme une grande partie de la vie, les choses que nous faisons reflètent notre caractère et nous montrent comment nous sommes vraiment. Les actions que nous entreprenons peuvent en elles-mêmes nous changer, pour le meilleur ou pour le pire. Si nous voulons prendre notre travail au sérieux, nous devrions nous tenir mutuellement responsables de ces habitudes qui semblent si ancrées dans notre culture : de la gratification instantanée, du succès en termes de métriques, du droit contre la gratitude, et de la fierté dans le surmenage.

Mais malgré tout cela, travailler à cette libération en valait tellement la peine.

Merci

C’est vraiment une version très excitante, non seulement en regardant en arrière ce que nous avons accompli et activé, mais beaucoup plus simplement en sachant combien de temps et de cœur ont été mis dans sa réalisation au cours de la dernière année. Il est difficile de croire les opportunités et les expériences qui se sont produites en cours de route : interagir avec et aider des entreprises du monde entier, trouver des amis dans presque toutes les villes que j’ai visitées, et parler honnêtement de l’incroyable voyage que ce groupe a entrepris ensemble.

Personnellement, je n’ai jamais vraiment mis autant d’énergie mentale dans quelque chose de cette ampleur et je voudrais remercier tant de personnes pour nous avoir soulevés en cours de route. Je remercie en particulier Logan Smyth, qui a passé un temps incalculable à modifier une grande partie du fonctionnement du noyau et qui prend toujours le temps d’être très utile sur notre Slack tout en travaillant en freelance, ainsi que Brian Ng, qui s’est impliqué de manière très importante pour continuer à maintenir Babel et relire tous mes articles de blog et mes conférences. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo, et Justin Ridgewell ont tous simplement contribué à rendre cette version possible et agréable à travailler.

Shoutout à tous les nombreux membres de la communauté sur Slack, Twitter, et à travers tous les projets sur GitHub qui doivent également comprendre ce que nous faisons pour leurs propres utilisateurs. J’aimerais remercier mes amis de Behance/Adobe qui m’ont sponsorisé pendant près d’un an pour travailler sur Babel à mi-temps avant de décider de travailler à plein temps (et qui m’ont aidé à tester Babel 7 en production pendant toute la durée de mon séjour). Un grand merci à tous nos sponsors pour notre Open Collective, en particulier Trivago et Handshake. Et merci à nos amis et à notre famille pour tout leur amour et leur soutien.

Nous sommes tous assez fatigués à ce stade, mais cela a vraiment été un honneur et un privilège de servir de cette façon, alors nous espérons que vous appréciez la sortie !

.