Aller au contenu principal

Babel 7 est disponible

· 27 min de lecture
Henry Zhu
Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

Après près de 2 ans, 4k commits, plus de 50 pré-versions et une aide considérable, nous sommes ravis d'annoncer la sortie de Babel 7. Cela fait presque 3 ans depuis la sortie de Babel 6 ! Il y a beaucoup d'éléments en mouvement, alors merci de faire preuve de patience durant les premières semaines suivant cette sortie. Babel 7 est une version majeure : nous l'avons optimisé en performance, créé un outil de mise à niveau, des configurations JS, des "overrides" de configuration, plus d'options pour la taille/minification, les JSX Fragments, TypeScript, de nouvelles propositions et bien plus encore !

Si vous appréciez notre travail sur Babel, vous pouvez sponsoriser le projet via Open Collective, me soutenir sur Patreon, ou impliquer votre entreprise dans Babel dans le cadre professionnel. Nous apprécions la propriété collective de ce projet vital pour la communauté JavaScript !

C'est officiel ! 🎉​

Un logiciel ne sera jamais parfait, mais nous sommes prêts à publier une version déjà utilisée en production depuis un certain temps ! @babel/core atteint déjà 5,1 millions de téléchargements/mois grâce à 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​

Je souhaite débuter cet article en rappelant le rôle de Babel dans l'écosystème JavaScript ces dernières années.

Le problème initial était que, contrairement aux langages serveur, il n'existait aucun moyen de garantir un support JavaScript identique pour tous les utilisateurs, car ceux-ci pouvaient utiliser différents navigateurs avec des niveaux de support variables (notamment les anciennes versions d'Internet Explorer). Si les développeurs utilisaient une nouvelle syntaxe (ex. class A {}), les utilisateurs sur d'anciens navigateurs obtenaient simplement un écran vide à cause d'une SyntaxError.

Babel a fourni aux développeurs un moyen d'utiliser les dernières syntaxes JavaScript sans se soucier de la rétrocompatibilité pour leurs utilisateurs, en les transpirant (class A {} devient var A = function A() {}).

Grâce à sa capacité à transformer du code JavaScript, il peut également implémenter de nouvelles fonctionnalités : il est ainsi devenu un pont pour aider TC39 (le comité spécifiant le langage JavaScript) à recueillir des retours sur les propositions JavaScript, et pour permettre à la communauté d'influencer l'avenir du langage.

Babel est fondamental pour le développement JavaScript actuel. On compte aujourd'hui plus de 1,3 million de dépôts dépendants sur GitHub, 17 millions de téléchargements mensuels sur npm et des centaines d'utilisateurs incluant des frameworks majeurs (React, Vue, Ember, Polymer) et des entreprises (Facebook, Netflix, Airbnb). Il est devenu une fondation si essentielle du développement JavaScript que beaucoup ignorent son utilisation. Même si vous ne l'utilisez pas directement, il est très probable que vos dépendances l'utilisent.

Les mainteneurs sont des personnes​

Babel exerce une influence considérable non seulement sur l'avenir du langage lui-même, mais aussi sur sa communauté et son écosystème. Mais malgré cette responsabilité, Babel reste un projet communautaire porté par quelques bénévoles.

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

Bien que ce soit un article d'annonce, je profite de l'occasion pour rappeler à tous l'état actuel de ce projet.

J'ai moi-même rejoint l'équipe quelques mois avant la sortie de la version 6.0, qui avait suscité son lot de controverses et de réactions négatives. L'accueil réservé à cette version a largement contribué à l'épuisement des mainteneurs existants (dont Sebastian, le créateur de Babel), et quelques-uns d'entre nous qui restions avons repris les rênes.

Comme de nombreux mainteneurs, nous sommes tombés dans ce rôle par hasard. Beaucoup d'entre nous n'avaient aucune formation formelle sur le fonctionnement des compilateurs ou la maintenance d'un projet open source. Ironiquement, j'avais même évité délibérément de me spécialiser en informatique à l'université car je ne voulais pas suivre de cours sur les compilateurs ou le bas niveau, cela me paraissait inintéressant et difficile. Pourtant, je me suis retrouvé attiré par l'outillage, les linters, Babel et JavaScript en tant que langage.

J'encourage chacun à examiner les projets open source dont vous dépendez et à les soutenir (par du temps et un soutien financier si possible).

Beaucoup de mainteneurs ne sont pas naturellement experts dans leurs domaines de travail ; et on accomplit beaucoup simplement en commençant par se mettre à l'ouvrage. Vous aborderez cela avec curiosité et humilité, deux qualités essentielles pour un mainteneur. Mon souhait porte sur la vision du projet plutôt que sur l'exécution de simples "tâches".

Babel n'est pas une entreprise, ni une équipe open source au sein d'une grande société comme Facebook. Seule une poignée de bénévoles travaillent sur Babel, et cela ne fait que quelques mois que j'ai sauté le pas pour quitter mon emploi et devenir le seul à travailler à plein temps sur l'open source. Mais les gens vont et viennent, ont une vie en dehors de ce "passe-temps", fondent des familles, passent à autre chose, changent d'emploi ou en cherchent, etc. Collectivement, faisons-nous suffisamment pour soutenir ces fondations essentielles à notre travail, ou laisserons-nous lentement s'effriter ces bases ? Comment préserver un open source accueillant et inclusif tout en établissant des limites claires ? Pouvons-nous nous inspirer des expériences d'autres mainteneurs ?

Bien que l'open source ait clairement conquis le logiciel, pouvons-nous vraiment le considérer comme sain sans prendre en compte les personnes qui le font vivre ?

#BabelSponsorsEverything​

La pérennité de l'open source ressemble aujourd'hui à une quête où l'on fait circuler la corbeille. Il est facile d'affirmer la valeur que les projets apportent aux milliers de personnes et entreprises qui les utilisent, mais cette valeur ne se concrétise pas toujours pour ceux qui consentent à fournir le travail. Il existe pourtant de nombreuses façons de soutenir l'open source, même si toutes ne conviennent pas à chaque projet ou personne.

Passons maintenant aux nouveautés !!

Changements majeurs avec rupture de compatibilité​

Nous documentons ces changements dans notre Guide de migration. Beaucoup peuvent être appliqués automatiquement via notre nouvel outil babel-upgrade, ou pourront l'être ultérieurement.

  • Abandon de la prise en charge des versions Node non maintenues : 0.10, 0.12, 4, 5 (détails)

  • Migration vers l'espace de noms @babel via l'utilisation de paquets "scoped" (détails). Cela permet de distinguer les paquets officiels : babel-core devient @babel/core (et empêche le squatting de noms)

  • Suppression (et arrêt de publication) des préréglages annuels (preset-es2015, etc.) (détails). @babel/preset-env remplace ces préréglages car il inclut toutes les fonctionnalités annuelles et permet de cibler des navigateurs spécifiques

  • Abandon des préréglages "Stage" (@babel/preset-stage-0, etc.) au profit de l'activation individuelle des propositions. Suppression également des propositions dans @babel/polyfill par défaut (détails). Lisez l'article complet pour plus d'explications.

  • Renommage de certains paquets : tout plugin de proposition TC39 utilise désormais -proposal au lieu de -transform (détails). Exemple : @babel/plugin-transform-class-properties devient @babel/plugin-proposal-class-properties.

  • Introduction d'une peerDependency sur @babel/core pour les paquets destinés aux utilisateurs (babel-loader, @babel/cli, etc.) (détails)

babel-upgrade​

babel-upgrade est un nouvel outil permettant d'automatiser les modifications de mise à niveau : actuellement pour les dépendances dans package.json et la configuration .babelrc.

Nous recommandons de l'exécuter directement sur un dépôt Git avec npx babel-upgrade, ou de l'installer globalement via npm i babel-upgrade -g.

Pour modifier les fichiers, passez les options --write et --install.

Shell
npx babel-upgrade --write --install

Contribuez en signalant des problèmes ou en proposant des PR pour faciliter la transition vers Babel 7 ! Nous espérons utiliser cet outil pour les futures breaking changes et créer un bot proposant des PR de mise à jour.

Fichiers de configuration JavaScript​

Nous introduisons babel.config.js. Ce n'est pas obligatoire ni un remplacement de .babelrc, mais utile dans certains cas.

Les fichiers de configuration *.js sont courants dans l'écosystème JavaScript (ex: .eslintrc.js pour ESLint, webpack.config.js pour Webpack).

Exemple de compilation conditionnelle en "production" (déjà possible via l'option "env" dans .babelrc) :

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

babel.config.js utilise une résolution de configuration différente de .babelrc : il résout toujours la configuration à partir de ce fichier, contrairement à la recherche ascendante précédente. Cela permet d'utiliser la fonctionnalité overrides ci-dessous.

Configuration sélective avec overrides​

J'ai récemment publié un article sur la publication et l'utilisation de paquets ES2015+.

Une section détaille l'utilisation d'une nouvelle clé dans la configuration de Babel appelée overrides, qui permet de spécifier des configurations différentes par motif glob.

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

Cela permet à une application nécessitant des configurations de compilation distinctes pour ses tests, son code client et son code serveur d'éviter de créer un fichier .babelrc par dossier.

Vitesse 🏎​

Babel lui-même est plus rapide : vos builds devraient prendre moins de temps ! Nous avons optimisé le code et intégré des correctifs de l'équipe v8. Nous sommes fiers de faire partie du Web Tooling Benchmark aux côtés d'autres outils JavaScript majeurs.

Options de sortie​

Babel supporte depuis un moment les options de presets et plugins. Pour rappel, vous pouvez encapsuler le plugin dans un tableau et lui passer un objet d'options :

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

Nous avons modifié l'option loose de certains plugins et ajouté de nouvelles options ! Notez qu'en utilisant ces options, vous adoptez un comportement non conforme aux spécifications : soyez conscients des implications, notamment lors du passage à une syntaxe native sans compilation. Ces options conviennent mieux aux bibliothèques.

  • Pour les classes, class A {} n'inclura plus l'helper classCallCheck.
JavaScript
class A {}
var A = function A() {
-  _classCallCheck(this, A);
};
  • Nouvelle option si chaque boucle for-of utilise uniquement un tableau : ["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);
}
  • Exclusion du plugin transform-typeof-symbol en mode loose pour preset-env #6831

De nombreuses bibliothèques le faisant déjà, nous avons adopté ce comportement par défaut.

Le comportement par défaut reste une conformité maximale aux spécifications pour un passage transparent à preset-env ou une exécution native, contre une réduction de taille (chaque projet arbitre ce compromis). Nous améliorerons la documentation et les outils pour faciliter cela.

Prise en charge des annotations « Pure »​

Après #6209, les classes ES6 transpilées reçoivent un commentaire /*#__PURE__*/ permettant aux minifiers comme Uglify et babel-minify d'éliminer le code mort. Ces annotations sont aussi ajoutées aux fonctions helpers.

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

D'autres opportunités d'optimisation via ces annotations existent peut-être : faites-nous part de vos retours !

Syntaxe​

Prise en charge des propositions TC39​

Nous réitérons avoir supprimé les presets Stage au profit d'une politique d'opt-in explicite pour les propositions < Stage 4.

L'enjeu est d'éviter d'opter automatiquement les utilisateurs pour une syntaxe non figée, notamment pour les propositions Stage 0 ou 1. Ce billet explique la réflexion derrière les nouvelles fonctionnalités.

Voici une liste partielle des nouvelles syntaxes prises en charge par Babel (notez que ces fonctionnalités évoluent constamment et peuvent être ajoutées/supprimées/bloquées) ainsi que celles ajoutées dans la version 7 :

Il est difficile pour quiconque de suivre toutes les propositions, c'est pourquoi nous tentons de le faire sur babel/proposals.

Prise en charge de TypeScript (@babel/preset-typescript)​

Nous avons collaboré avec l'équipe TypeScript pour permettre à Babel de parser/transformer la syntaxe typée via @babel/preset-typescript, similairement à notre traitement de Flow avec @babel/preset-flow.

Pour plus de détails, consultez ce billet de l'équipe TypeScript !

Avant (avec les 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;
}

Flow et TypeScript sont deux outils permettant aux développeurs JavaScript de bénéficier du typage graduel. Notre objectif est de prendre en charge les deux dans Babel. Nous prévoyons de continuer à travailler étroitement avec leurs équipes respectives chez Facebook et Microsoft (ainsi qu'avec la communauté) pour maintenir la compatibilité et supporter les nouvelles fonctionnalités.

Cette intégration étant récente, certaines syntaxes pourraient ne pas être entièrement supportées. Nous apprécierions votre aide pour signaler les problèmes et éventuellement proposer une PR !

Prise en charge des fragments JSX (<>)​

Comme mentionné dans le blog React, la prise en charge des fragments JSX est disponible depuis la version beta.31.

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

// output 👇

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

Modifications des helpers Babel​

La PR babel-upgrade est en cours

@babel/runtime a été scindé en @babel/runtime et @babel/runtime-corejs2 (PR). Le premier contient uniquement les fonctions helpers de Babel, tandis que le second inclut également les fonctions de polyfill (ex: Symbol, Promise).

Babel peut avoir besoin d'injecter certaines fonctions réutilisables dans le code. Nous appelons ces fonctions des "helpers", similaires aux fonctions partagées entre modules.

Voici un exemple avec la compilation d'une class (sans le mode loose) :

La spécification impose d'appeler une classe avec new Person(), mais si elle est compilée en fonction, on pourrait techniquement utiliser Person(). Nous incluons donc une vérification à l'exécution.

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

Avec @babel/plugin-transform-runtime et @babel/runtime (comme dépendance), Babel peut extraire les fonctions individuelles et importer uniquement les fonctions modulaires nécessaires, permettant une sortie plus compacte :

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

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

La même approche est possible avec external-helpers et rollup-plugin-babel. Nous étudions comment automatiser ce processus à l'avenir. Un article dédié aux helpers de Babel sera publié prochainement.

Polyfill automatique (expérimental)​

Les polyfills sont essentiels pour activer des fonctionnalités comme Promise ou Symbol dans des environnements non supportés. Cette distinction est cruciale entre le rôle de Babel comme compilateur (transformant la syntaxe) et celui d'un polyfill (implémentant des fonctions/objets natifs).

Importer une solution globale comme @babel/polyfill est simple :

JavaScript
import "@babel/polyfill";

Mais cela inclut tout le polyfill, alors que certaines fonctionnalités sont déjà supportées par les navigateurs. C'est le même problème que @babel/preset-env résout pour la syntaxe, que nous appliquons ici aux polyfills. L'option useBuiltins: "entry" fractionne l'import initial pour ne conserver que les imports nécessaires.

Nous pouvons optimiser davantage en important uniquement les polyfills utilisés dans le codebase. L'option "useBuiltIns: "usage" est notre première approche pour y parvenir (docs).

Il parcourra chaque fichier et injectera une importation en haut du fichier si cette fonction intégrée est "utilisée" dans le code. Par exemple :

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

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

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

D'autres idées dans ce domaine consistent à utiliser polyfill.io si vous acceptez de dépendre d'un service (ou lisez comment Kent C. Dodds l'a utilisé pour créer un service hébergé chez PayPal).

Divers​

Babel Macros 🎣​

L'un des meilleurs aspects de Babel est la capacité à étendre l'outil via des plugins. Au fil des ans, Babel est passé d'un simple compilateur "6to5" à une plateforme de transformation de code, permettant des optimisations fantastiques pour l'expérience utilisateur et développeur. Des tonnes de plugins Babel ont été développés pour des bibliothèques et cas d'usage spécifiques, améliorant les performances et capacités des APIs d'une manière autrement impossible (certaines "bibliothèques" sont entièrement transpilées, supprimant tout runtime).

Malheureusement, ajouter ces plugins à votre projet nécessite de modifier la configuration (ce que certaines boîtes à outils comme create-react-app n'autorisent pas) et complexifie votre code car les développeurs doivent connaître les plugins Babel appliqués pour anticiper leur impact. Ces problèmes sont résolus par babel-plugin-macros de Kent C. Dodds !

Une fois babel-plugin-macros installé et ajouté à votre configuration (inclus dans create-react-app v2), vous n'aurez plus à modifier votre configuration pour utiliser des macros. De plus, il est plus simple de créer vos propres transformations pour des cas d'usage spécifiques à votre application.

Apprenez-en plus sur babel-plugin-macros dans notre article original "Zero-config code transformation with babel-plugin-macros".

Ciblage des modules​

Babel a toujours cherché à équilibrer l'impact des transformations sur la taille du code et leurs bénéfices pour les développeurs. Dans Babel 7, il est bien plus simple de configurer Babel pour supporter le pattern module/nomodule de plus en plus populaire.

Plusieurs outils CLI pour frameworks web populaires (1, 2) l'utilisent déjà, réduisant d'environ 20% la taille du JavaScript livré aux utilisateurs.

Métadonnées d'appelant et meilleurs paramètres par défaut​

Nous avons ajouté une option caller à @babel/core pour que nos outils puissent transmettre des métadonnées aux presets/plugins. Par exemple : babel-loader peut ajouter quelque chose comme ceci pour que preset-env désactive automatiquement la transformation des modules (idem pour rollup) :

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

Cela permet aux outils d'offrir de meilleurs paramètres par défaut et moins de configuration ! Pour webpack/rollup : nous pouvons automatiquement utiliser leur transformation de modules plutôt que celle de Babel (idem pour import("a")). D'autres outils exploiteront cette fonctionnalité à l'avenir !

class C extends HTMLElement {}​

L'un de nos problèmes les plus anciens obtient sa propre section (détails)

Babel avait toujours eu la limitation de ne pas pouvoir étendre les objets natifs (Array, Error, etc.) et maintenant c'est possible ! Nous avons reçu de nombreux signalements à ce sujet ; 🎉 vous devriez célébrer comme Andrea !

Cette modification a été apportée au plugin de classes, elle devrait donc être activée automatiquement si vous utilisez preset-env.

Changements sur le site 🌏​

Nous avons migré notre site de Jekyll vers Docusaurus !

Nous sommes encore en train de configurer les traductions avec Crowdin, et avec Babel 7 publié, nous serons dans une meilleure position pour démarrer ce processus.

REPL​

Nous avons réécrit le REPL en tant que composant React et avons collaboré avec Ives pour une meilleure intégration avec CodeSandbox. Cela vous permet d'installer n'importe quel plugin ou preset depuis npm dans le REPL ainsi que de bénéficier des mises à jour de CodeSandbox.

Nous participons de 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 !

Il y a tellement d'opportunités ici pour contribuer à améliorer Babel, les AST, et d'autres outils !

Nous avons une chanson 🎶​

Hallelujah—À la gloire de Babel

Un jour, Angus nous a généreusement offert une chanson que j'ai trouvée incroyable, alors pourquoi ne pas en faire notre chanson « officielle » ? Et Shawn en a fait une brillante reprise ici.

Vous pouvez la trouver dans notre dépôt à SONG.md. Nous espérons voir d'autres projets emboîter le pas !

Et ensuite ?​

  • Babel est intrinsèquement lié à ce qu'il compile : JavaScript. Tant qu'il y aura de nouvelles propositions à travailler, notre mission continuera. Cela inclut le temps et l'effort nécessaires pour implémenter et maintenir la syntaxe avant même qu'elle ne devienne "stable". Nous nous soucions de tout le processus : le parcours de mise à niveau, la formation sur les nouvelles fonctionnalités, l'enseignement des standards et de la conception du langage, la simplicité d'utilisation et l'intégration avec d'autres projets.

    • En rapport : nous avons presque terminé l'implémentation de la nouvelle proposition de décorateurs dans Babel grâce à Nicolò. Ce fut un long parcours (cela a pris plus d'un an !) car la nouvelle proposition est complètement différente et bien plus puissante que l'ancienne, mais nous y sommes presque 🎉. Vous pouvez l'attendre dans l'une des prochaines versions mineures, accompagnée d'un article de blog détaillant les changements.

  • Boopathi maintient assidûment babel-minify, nous préparons donc sa version 1.0 !

  • De nombreuses nouvelles fonctionnalités sont en cours : ordonnancement des plugins, meilleure validation/gestion des erreurs, optimisations de vitesse, reconsidération des options loose/spec, mise en cache, utilisation asynchrone de Babel, compilation autonome via CI, tests de non-régression, exécution de test262. Consultez ce plan de route pour plus d'idées !

Nous n'avons aucun plan secret : nous faisons de notre mieux avec les moyens disponibles pour servir cette communauté.

L'Open Source est un miroir​

J'aimerais que nous ayons le temps et les ressources pour réaliser toutes ces idées correctement. Mais comme cette version le démontre, tout prend bien plus de temps que prévu !

Pourquoi ces versions prennent-elles tant de temps ? Est-ce dû à la complexité croissante, venant de nous-mêmes et de nos utilisateurs ? À notre difficulté à prioriser parmi toutes les corrections et améliorations possibles ? Au choix de régler d'abord les problèmes simples plutôt que les fondamentaux ? Ou aux "distractions" causées par l'aide sur GitHub, Slack et Twitter ? Sommes-nous simplement mauvais pour estimer notre temps, comprendre la complexité des problèmes, ou trop nous engager en tant que bénévoles ?

Ou nous mettons-nous trop de pression, ou cédons-nous aux attentes irréalistes des autres au détriment de notre bien-être ? Je ne peux décrire que comme une angoisse la sensation de voir un message demandant pourquoi une fonctionnalité n'est pas publiée ou un bug non corrigé. J'ai envie de tout précipiter pour en finir, mais je veux aussi prendre ce travail au sérieux.

J'ai tenté d'exprimer ces réflexions lors de ma conférence la semaine dernière à React Rally : Through the (Open Source) Looking Glass, que je vous encourage à écouter. La question que je me pose : que puis-je faire contre l'épuisement inévitable des mainteneurs, l'anxiété constante et les attentes irréalistes ?

Comme dans la vie, nos actions reflètent notre caractère et révèlent qui nous sommes. Ces actions peuvent nous transformer, en bien ou en mal. Si nous prenons notre travail au sérieux, nous devons nous responsabiliser mutuellement face à ces habitudes ancrées dans notre culture : gratification instantanée, succès mesuré par des métriques, sentiment de droit plutôt que de gratitude, et fierté du surmenage.

Mais malgré tout, travailler à cette version en valait vraiment la peine.

Remerciements​

Cette version est véritablement passionnante, non seulement par ce qu'elle accomplit et permet, mais surtout par le temps et le cœur investis cette dernière année. C'est incroyable de voir les opportunités et expériences générées : aider des entreprises du monde entier, trouver des amis dans presque chaque ville visitée, et partager honnêtement le parcours extraordinaire de ce groupe.

Personnellement, je n'ai jamais consacré autant d'énergie mentale à un projet d'une telle envergure et je tiens à remercier toutes les personnes qui nous ont soutenus en cours de route. Un hommage spécial à Logan Smyth qui a consacré un temps considérable à transformer profondément le fonctionnement du cœur de Babel, tout en restant toujours disponible pour aider sur notre Slack malgré son activité freelance, et à Brian Ng qui s'est investi massivement pour maintenir Babel tout en relisant mes articles de blog et présentations. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo et Justin Ridgewell ont tous été déterminants pour rendre cette version possible et agréable à développer.

Merci à tous les nombreux membres de la communauté sur Slack, Twitter et à travers tous les projets GitHub qui doivent aussi comprendre nos évolutions pour leurs propres utilisateurs. J'adresse un immense merci à mes collègues de Behance/Adobe qui m'ont sponsorisé pendant près d'un an pour travailler à mi-temps sur Babel avant que je ne passe à plein temps (tout en testant Babel 7 en production durant toute ma période chez eux). Grand merci à tous nos sponsors d'Open Collective, notamment Trivago et Handshake. Et merci à nos proches pour leur amour et soutien inconditionnels.

Nous sommes tous assez fatigués maintenant, mais ce fut un véritable honneur et privilège de servir ainsi la communauté, alors nous espérons que vous apprécierez cette version !