Aller au contenu principal

Préparatifs de la version 7.0

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

Si vous ne le saviez pas encore, nous prévoyons de publier bientôt une version 7.0 🙌 ! Le travail a en fait commencé en février, lorsque je voulais simplement publier une version abandonnant la prise en charge de Node 0.10/0.12 et supprimant babel-runtime ainsi que divers autres codes. Depuis, nous avons publié jusqu'à alpha.20.

Nous mettrons à jour cet article tout au long des versions bêta.

Comme nous restons un projet bénévole, il a été difficile pour la plupart de l'équipe de rester concentrée et motivée pour effectuer tous ces changements tout en maintenant un projet dont tant d'entreprises, bootcamps et outils dépendent. Mais nous avons malgré tout réalisé des progrès notables : réunions hebdomadaires/notes, participation en tant qu'invités aux dernières réunions du TC39, facilitation du RGSoC et du GSoC, et création d'un Open Collective.

Mise à niveau​

Pour la plupart des projets, la mise à niveau devrait être aussi simple que de mettre à jour vos dépendances dans package.json vers 7.0.0-beta.0. Tout au long de notre travail sur la 7.0, nous l'avons utilisée dans Babel lui-même (méta !) et sur mon lieu de travail chez Behance.

Nous épinglerons toutes les dépendances à des versions exactes jusqu'à la publication officielle.

{
  "devDependencies": {
    "babel-cli": "7.0.0-beta.0"
  }
}

Paquets spécifiques :

Details

babel packages in the monorepo should all be >= 7.0.0-beta.0
babel-preset-env should be at least 2.0.0-beta.0
babel-eslint can be >= 8.0.0
babel-loader should be >= 7.0.0 (out of beta since it uses babel-core as a peerDependency)
grunt-babel can be >= 7.0.0
gulp-babel can be >= 7.0.0
rollup-plugin-babel can be >= 3.0.2

Consultez notre guide de mise à niveau et l'autre guide destiné aux auteurs d'outils, que nous mettrons à jour si nécessaire.

Je souhaite maintenant passer en revue les principaux changements de notre première version bêta (son périmètre de changements cassants reste bien plus réduit que celui de la précédente version 6.0).

Réaffirmation des objectifs du projet​

Avant cela, permettez-moi de rappeler quel est l'objectif de Babel.

Depuis que Babel a été renommé (auparavant 6to5), les navigateurs implémentent davantage de spécifications et les utilisateurs maîtrisent mieux les dernières syntaxes/outils de build. Il n'est cependant pas surprenant que les objectifs de Babel n'aient guère changé.

Nos deux objectifs sont indissociables :

  1. Aider les développeurs à transformer de nouvelles syntaxes en code rétrocompatible (abstraire la prise en charge des navigateurs)

  2. Servir de pont pour aider le TC39 à recueillir des retours sur les nouvelles propositions ECMAScript et permettre à la communauté d'influencer l'avenir du langage.

Ainsi, dire que Babel est un pilier vital de la communauté JavaScript (presque 10 millions de téléchargements mensuels de babel-core) et qu'il a cruellement besoin de soutien relève de l'euphémisme. (Mes seules présentations traitent de ce sujet : JSConf EU, React Rally, TC39). Récemment, j'ai posé cette question : "Et si Babel disparaissait ?" Que se passe-t-il quand les contributeurs actuels s'ennuient/s'épuisent/partent vers d'autres projets ? (Et si c'était déjà le cas ?). Agirons-nous ? Je ne veux pas simplement vous demander de nous aider : vous êtes déjà nous en tant qu'utilisateurs du projet.

Bien, parlons maintenant des changements !

Abandon de la prise en charge des versions Node non maintenues : 0.10, 0.12, 5 (#4315)​

Les progrès dans les projets open source se font souvent au prix de mises à jour pour leurs utilisateurs. C'est pourquoi nous avons toujours hésité à introduire une version majeure avec des changements cassants. En abandonnant les versions non supportées de Node, nous pouvons non seulement améliorer significativement la base de code, mais aussi mettre à jour les dépendances et outils (ESLint, Yarn, Jest, Lerna, etc.).

👓 Mises à jour des propositions et conformité aux spécifications​

Alias : les seules choses qui intéressent la plupart d'entre vous 😅

Philosophie (Propositions : spec, loose, comportement par défaut)​

Nous avons créé un nouveau dépôt : babel/proposals pour suivre notre avancement sur les différentes propositions TC39 et réunions.

J'ai également ajouté une section expliquant comment nous acceptons les nouvelles propositions. Notre principe fondamental est que nous acceptons désormais les PR pour toute proposition présentée par un champion TC39 (Stage 0). Et nous les mettrons à jour (avec votre aide !) quand les spécifications évolueront.

Naturellement, nous en profiterons pour adopter un comportement par défaut aussi conforme que possible aux spécifications (dans des limites raisonnables de performance). Cela signifie que si vous avez besoin d'une build plus rapide/plus légère, vous devrez utiliser l'option loose qui ignore délibérément certaines exigences des spécifications comme les vérifications à l'exécution ou certains cas limites. Cette option est volontairement explicite car nous estimons que vous devez savoir ce que vous faites, tandis que les autres pourront mettre à jour babel-preset-env pour utiliser la version native de chaque syntaxe ou même abandonner Babel sans rencontrer de problèmes.

Stage 3 : Propriétés de classe (depuis Stage 2)​

babel-plugin-transform-class-properties : le comportement par défaut correspond désormais à l'ancienne option "spec", qui utilise Object.defineProperty au lieu d'une simple assignation.

Cela casse actuellement la compatibilité avec le plugin legacy pour les décorateurs (que nous avons renommé "transform-decorators" dans la 7.0) si vous tentez de décorer une propriété de classe. Vous devrez utiliser l'option loose pour rester compatible avec la version des décorateurs actuellement transformée jusqu'à la sortie du plugin pour les décorateurs Stage 2.

Les champs privés sont en cours de développement : #6120

Entrée

JavaScript
class Bork {
  static a = 'foo';
  x = 'bar';
}

Sortie (par défaut)

JavaScript
class Bork {
  constructor() {
    Object.defineProperty(this, "x", {
      configurable: true,
      enumerable: true,
      writable: true,
      value: 'bar'
    });
  }
};

Object.defineProperty(Bork, "a", {
  configurable: true,
  enumerable: true,
  writable: true,
  value: 'foo'
});

Sortie (mode loose)

JavaScript
class Bork {
  constructor() {
    this.x = 'bar';
  }
};
Bork.a = 'foo';

Stage 3 : Rest/Spread pour les objets (depuis Stage 2)​

babel-plugin-transform-object-rest-spread : le plugin gère désormais les clés non-string (ex : Number/Symbol).

Entrée

JavaScript
// Rest Properties
let { x, y, ...z } = { x: 1, y: 2, a: 3, b: 4 };
console.log(x); // 1
console.log(y); // 2
console.log(z); // { a: 3, b: 4 }

// Spread Properties
let n = { x, y, ...z };
console.log(n); // { x: 1, y: 2, a: 3, b: 4 }

Également interdit

JavaScript
var { ...{ x } } = obj;
var { ...[ y ] } = obj;

Stage 3 : Liaison optionnelle dans les blocs catch (nouveau)​

babel-plugin-transform-optional-catch-binding : permet aux développeurs d'utiliser try/catch sans créer de liaison inutilisée.

Entrée

JavaScript
try {
  throw 0;
} catch {
  doSomethingWhichDoesNotCareAboutTheValueThrown();
}

Sortie

JavaScript
try {
  throw 0;
} catch (_unused) {
  doSomethingWhichDoesNotCareAboutTheValueThrown();
}

Stage 3 : Expressions régulières avec propriétés Unicode (nouveau)​

babel-plugin-transform-unicode-property-regex : compile les échappements de propriétés Unicode (\p{…} et \P{…}) dans les expressions régulières vers de l'ES5 ou ES6 fonctionnel dans les environnements actuels.

Entrée

JavaScript
var regex = /\p{ASCII_Hex_Digit}/u;

Sortie

JavaScript
var regex = /[0-9A-Fa-f]/;

Stage 3 : BigInt (nouveau, non finalisé)​

babel-plugin-transform-bigint: #6015. Ne sera pas inclus dans les presets Stage car cela ralentirait le wrapping de tous les opérateurs.

Entrée

JavaScript
50000n + 60n;

Sortie

JavaScript
import babelCheckBinaryExpressions from "babel-check-binary-expressions";
babelCheckBinaryExpressions(new BigInt("50000"), new BigInt("60"), "+");

Stage 3 : Import dynamique (provenant du Stage 2)​

babel-plugin-syntax-dynamic-import : Seule l'analyse syntaxique est nécessaire, car des outils comme Webpack peuvent gérer la transformation à la place de Babel. Existe aussi un plugin pour Node

Entrée

JavaScript
const testModule = import('test-module');

Stage 2 : import.meta (syntaxe uniquement)​

Propriété meta valide uniquement syntaxiquement dans les modules, destinée aux méta-informations sur le module en cours d'exécution fournies par l'environnement hôte.

Entrée

JavaScript
const size = import.meta.scriptElement.dataset.size || 300;

Stage 2 : Séparateurs numériques (nouveauté)​

babel-plugin-transform-numeric-separator : améliore la lisibilité des littéraux numériques en créant une séparation visuelle (_) entre les groupes de chiffres.

Entrée

JavaScript
1_000_000_000
0b1010_0001_1000_0101
0xA0_B0_C0

Sortie

JavaScript
1000000000
0b1010000110000101
0xA0B0C0

Stage 2 : Décorateurs (provenant du Stage 1), toujours en cours​

babel-plugin-transform-decorators : #6107

Interdit

JavaScript
// no computed decorator keys
@dec[foo]
class A {}

// no parameter decorators (a separate proposal)
class Foo {
  constructor(@foo x) {}
}

// no decorators on object methods
var o = {
  @baz
  foo() {}
}

// decorator cannot be attached to the export
@foo
export default class {}

Valide

JavaScript
// decorators with a call expression
@foo('bar')
class A {
  // decorators on computed methods
  @autobind
  [method](arg) {}
  // decorators on generator functions
  @deco
  *gen() {}
  // decorators with a member expression
  @a.b.c(e, f)
  m() {}
}

// exported decorator classes
export default @foo class {}

Non pris en charge (WIP)

JavaScript
// decorated class properties
class A {
  @dec name = 0
}

Stage 2 : function.sent (nouveauté)​

babel-plugin-transform-function-sent : compile la propriété meta function.sent, utilisée dans les fonctions génératrices

Entrée

JavaScript
function* generator() {
    console.log("Sent", function.sent);
    console.log("Yield", yield);
}

const iterator = generator();
iterator.next(1); // Logs "Sent 1"
iterator.next(2); // Logs "Yield 2"

Sortie

JavaScript
let generator = _skipFirstGeneratorNext(function* () {
    const _functionSent = yield;
    console.log("Sent", _functionSent);
    console.log("Yield", yield);
});

Stage 2 : export-ns-from​

babel-plugin-transform-export-namespace : raccourci pour importer/réexporter un espace de noms. Séparé de l'ancien transform-export-extensions qui combinait cette proposition avec une autre

Entrée

JavaScript
export * as ns from "mod";

Sortie

JavaScript
import * as ns from "mod";
export {ns};

Stage 1 : export-default-from​

babel-plugin-transform-export-default : raccourci pour importer/réexporter un élément. Séparé de l'ancien transform-export-extensions qui combinait cette proposition avec une autre

Entrée

JavaScript
export v from "mod";

Sortie

JavaScript
import _v from "module";
export { _v as v };

Stage 1 : Chaînage optionnel (nouveauté)​

babel-plugin-transform-optional-chaining : l'opérateur (?.) permet de gérer les propriétés d'objets profondément imbriqués sans craindre les objets intermédiaires non définis.

Entrée

JavaScript
a?.b = 42;

Sortie

JavaScript
var _a;
(_a = a) == null ? void 0 : _a.b = 42;

ES2015 : new.target​

babel-plugin-transform-new-target : nous n'avions pas encore implémenté la prise en charge de new.target, désormais un plugin dédié sera inclus dans les presets ES2015/env.

Exemple

JavaScript
// with a function
function Foo() {
  console.log(new.target);
}

Foo(); // => undefined
new Foo(); // => Foo

// with classes
class Foo {
  constructor() {
    console.log(new.target);
  }
}

class Bar extends Foo {
}

new Foo(); // => Foo
new Bar(); // => Bar

Entrée

JavaScript
class Foo {
  constructor() {
    new.target;
  }

  test() {
    new.target;
  }
}

Sortie

JavaScript
class Foo {
  constructor() {
    this.constructor;
  }

  test() {
    void 0;
  }
}

🚀 Nouvelle fonctionnalité​

.babelrc.js​

babel/babel#4630

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

L'écriture de configurations en JavaScript permet des configurations dynamiques, facilitant l'adaptation programmatique à différents environnements via un seul fichier.

JavaScript
var env = process.env.BABEL_ENV || process.env.NODE_ENV;
var plugins = [];
if (env === 'production') {
  plugins.push.apply(plugins, ["a-super-cool-babel-plugin"]);
}
module.exports = { plugins };
JavaScript
var env = process.env.BABEL_ENV || process.env.NODE_ENV;
module.exports = {
  plugins: [
    env === 'production' && "another-super-cool-babel-plugin"
  ].filter(Boolean)
};

Cette approche remplace l'option env désormais dépréciée. Voir ci-dessous pour plus de détails.

TypeScript​

Vous pouvez désormais utiliser babel-preset-typescript pour permettre à Babel de supprimer les types, de la même manière que babel-preset-flow fonctionne !

babel.config.json
{
  "presets": ["typescript"]
}

Nous travaillons sur un guide pour configurer TypeScript et Babel avec l'équipe TypeScript, qui devrait être terminé avant la sortie officielle de la version 7.0. TL;DR : vous configurez TS avec --noEmit ou l'utilisez en mode éditeur/watch afin de pouvoir utiliser preset-env et d'autres plugins Babel.

Annotation « Pure » dans des transformations spécifiques pour les minificateurs​

Après #6209, les classes ES6 transpilées auront un commentaire /*#__PURE__*/ que les minificateurs comme Uglify et babel-minify peuvent utiliser pour l'élimination de code mort. Ces annotations pourront également s'étendre à nos fonctions d'aide.

Entrée

JavaScript
class C {
  m(x) {
    return 'a';
  }
}

Sortie

JavaScript
var C = /*#__PURE__*/ function () {
  function C() {
    _classCallCheck(this, C)
  }
  C.prototype.m = function m(x) {
    return 'a';
  };
  return C;
}();

😎 Autres changements cassants​

Suppression de babel-preset-flow de babel-preset-react​

C'était important car nous avons reçu de nombreuses plaintes d'utilisateurs qui n'utilisaient aucun type/flow et qui se sont retrouvés à écrire du JS invalide sans erreur de syntaxe parce qu'ils utilisaient le preset React.

De plus, nous avons maintenant le preset TypeScript, il n'était donc plus logique d'inclure flow dans le preset React lui-même.

Intégrations​

Des packages comme grunt-babel, gulp-babel, rollup-plugin-babel, etc. avaient tous babel-core comme dépendance.

Après la v7, nous prévoyons de faire de babel-core une peerDependency, comme babel-loader l'a déjà. Cela permet à tous ces packages de ne pas avoir à augmenter leur version majeure lorsque l'API de babel-core n'a pas changé. Ainsi, ils sont déjà publiés en 7.0.0 puisque nous n'attendons plus de modifications pour ces packages.

Meta​

Suppression de babel-runtime de nos propres dépendances Babel (#5218)​

Babel lui-même n'a pas tant de dépendances externes, mais en 6.x chaque package avait une dépendance sur babel-runtime afin que les built-ins comme Symbol, Map, Set et d'autres soient disponibles sans avoir besoin d'un polyfill. En changeant la version minimale de Node supportée à v4 (où ces built-ins sont supportés nativement), nous pouvons supprimer complètement cette dépendance.

C'était un problème avec npm 2 (nous ne recommandions pas son utilisation avec Babel 6) et les anciennes versions de yarn, mais pas avec npm 3 grâce à son comportement de déduplication.

Avec Create React App, la taille du dossier node_modules changeait radicalement lorsque babel-runtime était hoisté.

  • node_modules avec npm 3 : ~120 Mo

  • node_modules avec Yarn (≤0.21.0) : ~518 Mo

  • node_modules avec Yarn (≤0.21.0) et babel-runtime hoisté : ~157 Mo

  • node_modules avec Yarn + PR #2676 : ~149 Mo (tweet)

Donc, bien que ce problème ait été corrigé « en amont » en utilisant npm >= 3 ou des versions ultérieures de Yarn, nous pouvons faire notre part en supprimant simplement notre propre dépendance à babel-runtime.

Publication indépendante des packages expérimentaux (#5224)​

J'évoquais cela dans The State of Babel dans la section Versioning. Issue Github

Vous vous souvenez peut-être qu'après Babel 6, Babel est devenu un ensemble de paquets npm avec son propre écosystème de presets et plugins personnalisés.

Cependant depuis, nous avons toujours utilisé un système de versionnage "fixe/synchronisé" (ainsi aucun package n'atteint la v7.0 ou plus). Lors d'une nouvelle version comme v6.23.0, seuls les packages avec du code modifié sont publiés avec la nouvelle version, les autres restent inchangés. Cela fonctionne généralement car nous utilisons ^ dans nos packages.

Malheureusement, ce système impose qu'une version majeure soit publiée pour tous les packages dès qu'un seul en a besoin. Cela conduit soit à de nombreuses ruptures mineures (inutiles), soit à regrouper de nombreuses ruptures dans une seule version. Nous préférons différencier les packages expérimentaux (Stage 0, etc.) du reste (es2015).

Ainsi, nous comptons effectuer des mises à jour majeures pour les plugins de propositions expérimentales lorsque la spec évolue, plutôt que d'attendre de mettre à jour tout Babel. Tout ce qui est < Stage 4 pourra subir des ruptures via des mises à jour majeures, idem pour les presets Stage s'ils ne sont pas abandonnés.

Par exemple :

Supposons que vous utilisiez preset-env (qui inclut es2015, es2016, es2017) + un plugin expérimental. Vous adoptez aussi object-rest-spread car c'est pratique.

babel.config.json
{
  "presets": ["env"],
  "plugins": ["transform-object-rest-spread"]
}

Si la spec d'une proposition expérimentale change, nous devrions pouvoir introduire une rupture avec une mise à jour majeure limitée à ce plugin. Cela n'affecte rien d'autre, permettant aux utilisateurs de mettre à jour à leur rythme. Nous voulons faciliter la mise à jour des propositions expérimentales via des outils automatisés quand c'est pertinent.

💀 Dépréciations envisagées​

Déprécier l'option "env" dans .babelrc​

babel/babel#5276 MAJ : Nous avons rendu son comportement plus intuitif sans la supprimer.

L'option "env" (à ne pas confondre avec babel-preset-env) a causé de la confusion, comme le montrent les nombreuses issues remontées.

Le comportement actuel fusionne les configurations, ce qui n'est pas toujours intuitif : les développeurs finissent par dupliquer tous les presets/plugins dans chaque environnement.

Pour clarifier (et aider les utilisateurs avancés), nous envisageons de supprimer l'option "env" et recommandons le format de configuration JS proposé (ci-dessous).

Déprécier les presets ES20xx (fait)​

Nous avons déjà déprécié preset-latest il y a quelque temps, et ES2016/ES2017 plus tôt Créer un préréglage annuel est fastidieux (paquet/dépendance supplémentaire, problèmes de squattage de paquets npm sauf si nous utilisons des paquets scopés)

Les développeurs ne devraient pas choisir un preset annuel. En dépréciant ces presets, tout le monde peut utiliser babel-preset-env qui évolue avec la spec.

🤔 Questions en suspens​

Déprécier/Renommer/Supprimer les presets Stage X (fait)​

MAJ : Nous l'avons fait et expliqué dans un billet dédié.

De nombreux membres de la communauté (et du TC39) ont exprimé des préoccupations concernant les presets Stage X. Je pense les avoir ajoutés principalement pour faciliter la migration de Babel 5 vers Babel 6 (l'option "stage" existait auparavant).

Bien que nous souhaitions un outil facile d'utilisation, force est de constater que de nombreuses entreprises/développeurs utilisent ces presets "pas encore JavaScript" constamment, y compris en production. "Stage 0" ne transmet pas le même message qu'un babel-preset-dont-use-this-stage-0.

Ariya a récemment créé un sondage éclairant illustrant parfaitement ce problème

Les développeurs ne savent généralement pas quelles fonctionnalités appartiennent à quelle version de JavaScript (et ils ne devraient pas avoir à le savoir). Cependant, cela devient problématique lorsque nous considérons comme acquises des "fonctionnalités" qui ne sont encore que des propositions.

De nombreux projets open source (y compris Babel lui-même 😝), tutoriels, conférences, etc. utilisent stage-0. React promeut JSX, les propriétés de classe (désormais Stage 3), la syntaxe rest/spread (Stage 3), et nous finissons par croire que ce sont des fonctionnalités JavaScript standard grâce à la compilation de Babel. Supprimer cette abstraction pourrait aider à mieux comprendre les implications et compromis liés à l'utilisation des plugins Stage X.

Maintenir son propre preset semble également plus simple que de devoir mettre à jour constamment le preset Stage.

On entend souvent : "Je veux utiliser la syntaxe rest, c'est stage 2, donc j'active stage 2". Résultat : d'autres fonctionnalités expérimentales sont activées à leur insu. De plus, l'évolution des stages peut introduire de nouvelles fonctionnalités sans avertissement (pour ceux n'utilisant pas shrinkwrap ou yarn), voire en faire disparaître. @glenjamin

Utilisation des packages scopés npm (implémenté, @babel/x)​

La majorité des personnes comprenant les packages scopés semblaient favorables ?

Avantages

  • Plus besoin de se battre pour obtenir un nom de package spécifique (raison initiale de cette proposition).

De nombreux noms étaient déjà pris (preset-es2016, preset-es2017, 2020, 2040, etc.). Transférer un nom est complexe et peut induire en erreur sur le caractère officiel d'un package.

Inconvénients

  • Migration nécessaire vers la nouvelle syntaxe

  • Support limité sur certains outils non-npm (effet lock-in)

  • Statistiques de téléchargement perdues sans alias vers les anciens noms

Il semble préférable de reporter ce changement, qui ne constitue de toute façon pas une rupture majeure puisqu'il s'agit uniquement d'un renommage.

external-helpers, transform-runtime, babel-polyfill​

MISE À JOUR : nous avons séparé l'utilisation de @babel/runtime et core-js dans transform-runtime

"regeneratorRuntime is not defined" - erreur fréquemment rapportée

Nous devons fondamentalement améliorer notre approche des built-ins/polyfills.

  • Les développeurs ignorent ce qu'est regenerator-runtime, ils veulent simplement utiliser des générateurs/fonctions async.

  • Beaucoup ne comprennent pas pourquoi un runtime est nécessaire, ou pourquoi Babel ne compile pas Promise, Object.assign ou d'autres built-ins.

  • Confusion récurrente entre le plugin Babel transform-runtime et le runtime babel-runtime lui-même.

  • Plaintes sur la taille du code généré : babel-polyfill inclut tous les polyfills (malgré useBuiltIns) et external-helpers reste méconnu.

Peut-on combiner/remplacer ces paquets pour offrir une expérience par défaut plus simple ?

Et ensuite ?​

Nous souhaitons que la communauté effectue la mise à niveau et fournisse ses retours/rapports. Il y aura probablement beaucoup d'activité initiale qui pourrait être écrasante, alors merci de faire preuve de patience. Nous apprécierions votre aide pour trier les problèmes, rédiger de la documentation/des guides de mise à niveau/des conseils, et créer des codemods pour faciliter la transition. Comme Babel impacte une grande partie de l'écosystème JavaScript, la mise à jour ne se résume pas simplement à modifier un paquet, car cela peut dépendre d'autres plugins Babel communautaires sur npm. Nous ne comptons pas attendre passivement un mois en espérant que les gens mettent à jour - un travail conséquent est nécessaire pour éviter que la moitié de la communauté reste sur la 6.x l'an prochain. Je ne souhaite pas abandonner des projets (et des personnes). Faites-nous savoir comment nous pouvons vous aider, et j'aimerais que vous fassiez de même pour nous et le reste de la communauté.

Durabilité du projet​

Un grand merci à mon équipe chez Behance qui me permet de travailler sur Babel à temps partiel pendant mes heures de travail ; nous restons pratiquement la seule entreprise soutenant activement Babel pendant le temps de travail. Je suis reconnaissant de pouvoir soutenir le projet professionnellement plutôt qu'en dehors des heures, et j'espère que davantage de mainteneurs pourront en bénéficier à l'avenir. (J'espère que nous montrons comment les entreprises peuvent soutenir les projets open source qu'elles utilisent sans nécessairement les "posséder").

Notre Open Collective ne dispose pas encore de fonds suffisants pour rémunérer quelqu'un à plein temps : le don le plus important reçu est de 750$ de Webflow, et la contribution mensuelle maximale est de 100$ de diverses entreprises/particuliers. Nous devons donc soit améliorer cela, soit impliquer plus d'entreprises comme l'ont fait AMP/Google (@jridgewell, récemment intégré à notre équipe, peut désormais y consacrer du temps professionnel, ce qui change beaucoup).

Demandez à votre entreprise de sponsoriser via notre Open Collective, signalez-nous les manques, proposez votre aide. Aucune raison spécifique n'est nécessaire pour contribuer. Si vous souhaitez simplement assurer la pérennité du projet, impliquez votre équipe et rejoignez-nous.

Futur​

Après la 7.0 : plusieurs pistes s'offrent à nous (évoquées depuis des années) : séparation du parcours et des plugins (visiteurs asynchrones ?), AST immuable, extensions syntaxiques ? Côté infrastructure : intégration avec test262 et tests smoke, meilleur workflow GitHub pour passer des propositions aux transformations, système de codemods pour les mises à jour automatiques, etc.

Suivez nos notes de réunion/discussions sur babel/notes et impliquez-vous !

Remerciements !​

J'espère que nous pourrons publier la version officielle rapidement, mais rappelons que l'open source repose sur un maintien quotidien constant, pas juste sur des cycles de release médiatisés où on abandonnerait les autres. Cela pourrait prendre un peu plus de temps le temps de corriger les bugs et de mettre à niveau l'écosystème.