Aller au contenu principal

Version 7.13.0 : Records et Tuples, hypothèses granulaires du compilateur et cibles globales

· 8 min de lecture
Nicolò Ribaudo
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 →

Nous venons de publier Babel 7.13.0, la première version mineure de 2021 !

Cette version inclut des fonctionnalités importantes pour @babel/core : une option targets (similaire à celle de @babel/preset-env) partageable entre différents plugins, une option assumptions pour affiner précisément votre configuration et produire un résultat de compilation plus compact, ainsi que la prise en charge des plugins et presets écrits en modules ECMAScript natifs.

Babel prend désormais en charge la transformation de la proposition ECMAScript Records and Tuples, qui introduit des structures de données immuables et l'égalité structurelle en JavaScript, ainsi que le parsing de la proposition Module Blocks.

Nous avons également ajouté la prise en charge de nouvelles fonctionnalités Flow et TypeScript.

Vous pouvez consulter le journal complet des modifications sur GitHub.

Mise à jour du financement​

Nous avons rejoint le programme "GitHub Sponsors for organizations", vous pouvez désormais nous sponsoriser directement via GitHub 😊.

Ces fonds soutiennent les efforts continus de notre équipe (actuellement un mainteneur à plein temps et trois à temps partiel) pour améliorer la stabilité et développer de nouvelles fonctionnalités.

Nos dons et dépenses sont ouvertement suivis sur notre page Open Collective, où nous tracerons également les dons provenant de GitHub Sponsors.

Nous accueillons les dons de particuliers et d'entreprises. Si votre société souhaite devenir sponsor Gold ($1k/mois) et discuter des modalités, contactez-nous à team@babeljs.io !

Principales fonctionnalités​

Option globale targets (#12189, RFC)​

L'option targets de @babel/preset-env permet de spécifier les environnements cibles, choisissant automatiquement la syntaxe à transformer et les polyfills à injecter. Depuis la sortie de @babel/preset-env, nous avons constaté que les plugins eux-mêmes peuvent aussi bénéficier de connaître vos cibles. Actuellement, cela nécessite de spécifier deux fois vos cibles (par exemple avec nos nouveaux plugins de polyfill). L'introduction de targets comme option globale permet désormais de les spécifier une seule fois :

Old configurationNew configuration
babel.config.json
{
  "presets": [
    ["@babel/preset-env", {
        "targets": ">1%, not ie 11"
    }]
  ],
  "plugins": [
    ["polyfill-es-shims", {
      "targets": ">1%, not ie 11"
    }]
  ]
}
JSON
{
  "targets": ">1%, not ie 11",
  "presets": ["@babel/preset-env"],
  "plugins": ["polyfill-es-shims"]
}

Nous recommandons de migrer votre configuration Babel vers cette nouvelle option targets, qui offre ces avantages supplémentaires :

  1. Meilleure gestion de la cible esmodules: true (elle est combinée avec les autres cibles plutôt que de les remplacer)

  2. Vous bénéficierez automatiquement de sorties plus optimisées au fur et à mesure que nous ajouterons la prise en charge des targets dans nos plugins !

Vous trouverez les détails de cette nouvelle option dans son RFC.

🔮 À l'avenir, nous pourrions intégrer @babel/preset-env dans @babel/core pour éviter d'installer un paquet supplémentaire. Cette nouvelle option constitue une première étape dans cette direction !

Option globale assumptions (#12219, RFC)​

De nombreux plugins Babel proposent une option loose, qui demande au compilateur de générer un code plus compact et plus rapide en faisant certaines hypothèses sur votre code, au détriment du strict respect de certaines spécifications JavaScript.

Cependant, l'option loose présente des inconvénients qui créent de la confusion : le terme lui-même ne décrit pas clairement son impact réel, et pire encore, elle nécessite parfois une configuration sur plusieurs plugins pour garantir une compilation cohérente.

Pour résoudre ces problèmes, nous avons ajouté une nouvelle option globale assumptions permettant de préciser quelles hypothèses Babel peut faire sur votre code ! À l'instar de l'option targets, chaque plugin reçoit désormais la liste des hypothèses activées, éliminant ainsi la nécessité de configurer chaque option individuellement. Ce mécanisme est précieux car une hypothèse peut influencer plusieurs plugins, et un plugin peut être affecté par plusieurs hypothèses.

attention

Il s'agit d'une fonctionnalité avancée. Tout comme l'ancienne option loose, soyez très prudent lors de l'activation des hypothèses : elles ne respectent pas entièrement les spécifications ECMAScript et pourraient provoquer des comportements inattendus dans votre code.

Par exemple, lors de la transformation de classes, Babel génère par défaut ce code :

InputOutput
JavaScript
class Test {
  constructor() {
    this.x = 2;
  }
}

// You can test the thrown error in the console:
// Uncaught TypeError: class constructors must be invoked with 'new'
Test();
JavaScript
function _classCallCheck(instance, Constructor) {
  if (!(instance instanceof Constructor)) {
    throw new TypeError("Cannot call a class as a function");
  }
}

let Test = function Test() {
  _classCallCheck(this, Test);

  this.x = 2;
};

// You can test the thrown error in the console:
// Uncaught TypeError: class constructors must be invoked with 'new'
Test();

Cependant, activer l'hypothèse noClassCalls indique à Babel : « Je n'essaie jamais d'appeler des classes sans new, donc vous pouvez compiler sans vous en soucier » :

JSON
{
  "targets": "firefox 30",
  "assumptions": { "noClassCalls": true },
  "presets": ["@babel/preset-env"]
}
InputOutput
JavaScript
class Test {
  constructor() {
    this.x = 2;
  }
}

// Won't throw since we violated the assumption
Test();
JavaScript
let Test = function Test() {
  this.x = 2;
};

// Won't throw since we violated the assumption
Test();

Consultez la liste complète des hypothèses dans notre documentation, où vous pouvez individuellement les activer ou les désactiver pour voir comment elles affectent le résultat compilé.

Prise en charge de Records et Tuples (#12145)​

Grâce à une collaboration avec Bloomberg, Babel prend désormais en charge la transformation de la proposition "Records and Tuples" (stage 2).

Le plugin Babel transforme la syntaxe des records et tuples en utilisant les fonctions globales Record et Tuple :

InputOutput
JavaScript
let data = #{
  name: "Babel",
  ids: #[1, 2, 3]
};
JavaScript
let data = Record({
  name: "Babel",
  ids: Tuple(1, 2, 3),
});

Cela implique de charger un polyfill pour ces fonctions globales, comme @bloomberg/record-tuple-polyfill, via une importation dans votre code ou une balise <script> :

<script src="https://unpkg.com/@bloomberg/record-tuple-polyfill@0.0.3/lib/index.umd.js" />

NOTE : Aucun moteur JavaScript ne supporte actuellement les records et tuples nativement, le polyfill est donc toujours requis.

Pour activer cette transformation, ajoutez @babel/plugin-proposal-record-and-tuple à votre configuration.

Nouvelles fonctionnalités Flow (#12193, #12234)​

Babel 7.13.0 prend en charge deux nouvelles fonctionnalités Flow :

  • Annotation de type this dans les fonctions, permettant de typer l'objet this comme un paramètre :

    JavaScript
    function getPerson(this: Database, id: string): Person {
      this instanceof Database; // true
    }

  • Déclarations enum avec membres inconnus :

    JavaScript
    enum PetKind {
      Dog,
      Cat,
      Snake,
      ...
    }

Support de TypeScript 4.2 (#12628)​

TypeScript 4.2 introduit de nouvelles fonctionnalités syntaxiques comme les signatures de constructeurs abstraits.

Consultez l'article de release TypeScript pour plus de détails.

Modules ES automatiques dans @babel/runtime (#12632)​

@babel/runtime contient toutes les fonctions d'assistance d'exécution de Babel dans les formats CommonJS et modules ECMAScript.

Jusqu'à présent, vous deviez choisir manuellement celui que vous souhaitiez utiliser, en spécifiant l'option useESModules de @babel/plugin-transform-runtime.

Nous avons réorganisé la structure interne de @babel/runtime en tirant parti du nouveau champ "exports" du fichier package.json, pris en charge par Node.js et les bundlers, afin qu'ils puissent choisir automatiquement entre CJS et ESM.

Pour cette raison, l'option useESModules est désormais dépréciée et sera supprimée dans Babel 8.