7.14.0 : Nouveautés des classes activées par défaut, TypeScript 4.3 et meilleure interopérabilité CommonJS

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 →

Babel 7.14.0 est disponible !

Cette version active par défaut les champs de classe et méthodes privées (promues au Stage 4 lors de la récente réunion TC39 d'avril !) et ajoute les vérifications de marque pour les champs privés et les blocs statiques à l'option shippedProposals de @babel/preset-env.

Nous avons ajouté le support des expressions async do au Stage 1 (via @babel/plugin-proposal-async-do-expressions), qui étend la proposition do expression au même stade.

Grâce à Sosuke Suzuki et Pig Fang, Babel gère désormais les fonctionnalités de TypeScript 4.3. @babel/parser propose aussi une nouvelle option pour analyser correctement les fichiers de déclaration TypeScript.

Enfin, nous avons introduit une nouvelle option importInterop: node pour faciliter la production de modules doubles en compilant les imports ECMAScript vers du CommonJS conforme à la sémantique Node.js.

Consultez le journal complet des modifications sur GitHub.

Si vous ou votre entreprise souhaitez soutenir Babel et l'évolution de JavaScript sans savoir comment procéder, vous pouvez nous faire un don via notre Open Collective ou mieux encore, collaborer directement avec nous à l'implémentation de nouvelles propositions ECMAScript ! Projet reposant sur le bénévolat, nous comptons sur le soutien communautaire pour financer nos efforts au service de la diversité des utilisateurs JavaScript. Contactez-nous à team@babeljs.io pour en discuter !

Principales fonctionnalités

Nouveautés des classes activées par défaut

Les propositions de champs de classe et méthodes privées viennent d'atteindre le Stage 4 et seront officiellement incluses dans ECMAScript 2022 ! C'était surtout une formalité puisque leur sémantique était déjà finalisée et implémentée dans tous les principaux navigateurs.

Retrouvez plus de détails sur cette nouvelle syntaxe dans la documentation MDN (champs publics, champs et méthodes privés).

JavaScript

class Check {
  static className = "Check"; // static public class field

  #value = 3; // # means private!

  get #double() { // private getter
    return this.#value * 2; // using a private field
  }
}

Vous pouvez donc supprimer @babel/plugin-proposal-class-properties et @babel/plugin-proposal-private-methods, car ils sont désormais activés par défaut dans @babel/preset-env.

attention

Webpack supporte nativement cette syntaxe depuis la v5.36.0. Pour les versions antérieures, une solution fonctionnelle avec des configurations Webpack simples consiste à activer manuellement le plugin acorn-stage3 en installant acorn-stage3 et en ajoutant ces lignes au début de votre fichier webpack.config.js :

JavaScript

// Require webpack's acorn dependency
const acorn = require(require.resolve("acorn", {
  paths: [require.resolve("webpack")]
}));

// Enable the Stage 3 plugin
acorn.Parser = acorn.Parser.extend(require("acorn-stage3"));

Si cette solution ne fonctionne pas, ou si vous utilisez un autre outil ne supportant pas les champs de classe, vous devez toujours utiliser les plugins Babel pour les transformer.

Si vous utilisez l'option shippedProposals de @babel/preset-env, celle-ci inclut désormais les plugins @babel/plugin-proposal-private-property-in-object (introduit dans la version 7.10) et @babel/plugin-proposal-class-static-block (introduit dans la version 7.12) : vous pouvez les retirer en toute sécurité de votre configuration.

JavaScript

class Foo {
  #bar = "bar";

  test(obj) {
    return #bar in obj; // private-property-in-object
  }

  static #x = 42;
  static y;
  static { // static block
    try {
      this.y = doSomethingWith(this.#x);
    } catch {
      this.y = "unknown";
    }
  }
}

Meilleure interopérabilité ESM-CJS

Lors de l'importation d'un fichier CommonJS depuis un module ECMAScript, Node.js présente une sémantique différente de la plupart des outils de l'écosystème JavaScript.

Supposons que vous dépendiez de la bibliothèque suivante :

JavaScript

export default function two() {
  return 2;
}

Et que son auteur ne la publie pas en l'état, mais la compile en CommonJS :

JavaScript

"use strict";

Object.defineProperty(exports, "__esModule", { value: true });
exports.default = two;

function two() {
  return 2;
}

Lors de l'importation de cette bibliothèque avec Babel (ou TypeScript, Rollup ou des outils similaires) et la compilation de votre code en CommonJS, cela ressemblera à :

JavaScript

import two from "two";
console.log(two());

Un jour, vous décidez de fournir deux versions de votre code : une version compilée en CommonJS et une autre utilisant les modules ECMAScript natifs.

Bien que la version compilée fonctionne, la version ESM générera TypeError: two is not a function. En effet, dans Node.js, l'import par défaut n'est pas exports.default de la dépendance, mais l'objet module.exports entier.

Vous pourriez modifier votre code ainsi :

JavaScript

import two from "two";
console.log(two.default());

Cependant, ce nouveau code pose un problème : il ne fonctionne plus une fois compilé, car two.default n'est pas une fonction.

Babel v7.14.0 ajoute une nouvelle option importInterop: "node" dans le plugin @babel/plugin-transform-modules-commonjs qui permet aux déclarations import de correspondre au comportement natif de Node.js. Vous pouvez en savoir plus sur cette option dans la documentation.

Nicolò de notre équipe a également contribué à une option similaire pour @rollup/plugin-commonjs, qui sera disponible dans la prochaine version. Notre objectif est d'aider l'écosystème à migrer vers les modules ECMAScript natifs en fournissant un chemin de migration plus simple.

TypeScript 4.3

La nouvelle version de TypeScript, qui sera publiée en version stable en mai, prend en charge plusieurs nouvelles fonctionnalités :

• Les modificateurs override dans les éléments de classe

• Les signatures d'index statiques ([key: KeyType]: ValueType) dans les classes

• Les déclarations get/set dans les types

Vous pouvez en savoir plus dans l'article de publication de TypeScript 4.3. Cette prise en charge est assurée via @babel/preset-typescript.

Les expressions async do

Les expressions async do sont une proposition de Stage 1 construite sur la proposition des expressions do.

Elles permettent d'utiliser des blocs asynchrones dans du code synchrone, et ces blocs sont évalués comme une promesse :

JavaScript

function sync() {
  let x = async do {
    let res = await Promise.resolve("Third!");
    console.log("Second!");
    res;
  };
  console.log("First!");
  x.then(console.log);
}

console.log(sync());
// Logs:
// - "First!"
// - "Second!"
// - "Third!"

Vous pouvez tester cette proposition (et nous faire part de vos retours !) en ajoutant les plugins @babel/plugin-proposal-do-expressions et @babel/plugin-proposal-async-do-expressions à votre configuration Babel.

attention

Ces propositions sont hautement expérimentales. Elles peuvent et vont probablement continuer à évoluer. Cela pourrait prendre des années avant qu'elles soient standardisées, et elles pourraient même être rejetées complètement. Vous êtes invités à les tester, mais nous ne recommandons pas de les utiliser en production.

---

Vous avez des commentaires ou des questions ? Venez en discuter sur GitHub !