Version 7.8.0 : Support ECMAScript 2020, fichiers de configuration .mjs et améliorations de @babel/cli
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 →
Voici la première version de l'année ! 🎉
Babel 7.8.0 prend désormais en charge nativement les nouvelles fonctionnalités ECMAScript 2020 : vous n'avez plus besoin d'activer manuellement les plugins pour le coalescement nul (??), le chaînage optionnel (?.) et l'import() dynamique avec preset-env.
Nous avons également finalisé l'alignement de nos différents formats de fichiers de configuration avec ceux supportés nativement par Node.js, un processus initié dans la version 7.7.0.
Enfin, l'interface en ligne de commande de Babel propose désormais deux nouvelles options : --out-file-extension et --copy-ignored.
Vous pouvez consulter le journal complet des modifications sur GitHub.
Un grand merci à Abdul Ali, Jack Isherwood, Jayen Ashar, James Beavers, Klaus Meinhardt, Oleksandr Fediashov, Siddhant N Trivedi, Tsubasa Nakayama, Yordis Prieto et ZYSzys pour leurs premières contributions !
Nous remercions également Thomas Smith qui s'est porté volontaire pour maintenir le plugin essentiel babel-sublime de coloration syntaxique, et souhaitons la bienvenue à Raja Sekar, notre nouveau membre de l'organisation Babel !
Si vous ou votre entreprise souhaitez soutenir Babel et l'évolution de JavaScript mais ne savez pas comment, vous pouvez faire un don via notre Open Collective ou mieux encore, collaborer directement à l'implémentation des nouvelles propositions ECMAScript ! En tant que projet bénévole, nous dépendons du soutien communautaire pour financer nos efforts au service de la vaste communauté JavaScript. Contactez-nous à team@babeljs.io pour en discuter !
Nous avons récemment publié un billet sur le financement détaillant nos plans et objectifs. Découvrez-le !
Support natif d'ECMAScript 2020 (#10811, #10817, #10819, #10843)
Lors de la dernière réunion, le TC39 a fait passer les propositions de coalescement nul et de chaînage optionnel au stade 4 !
L'opérateur de coalescence nulle permet de fournir une valeur de repli lorsqu'une expression vaut null ou undefined :
const name = person.fullName ?? "Anonymous";
console.log(`Hello, ${name}!`);
Cela est similaire au fonctionnement de l'opérateur OU logique (||). La différence réside dans le fait que || vérifie les valeurs "falsy" (c'est-à-dire undefined, null, false, 0, 0n et ""), tandis que ?? ne vérifie que les valeurs "nullish". Cela correspond mieux au modèle mental de "valeur non fournie" et fonctionne mieux avec des valeurs potentiellement falsy mais valides :
const element = { index: 0, value: "foo" };
const index = element.index ?? -1; // 0 :D
const index = element.index || -1; // -1 :(
La proposition de chaînage optionnel utilise le même concept de "valeurs nullish", permettant des accès propriétés optionnels sur des valeurs qui pourraient être nullish. Elle prend également en charge les appels de fonction optionnels et les propriétés calculées.
const city = person.address?.city; // person.address could be not defined
const isNeighbor = person.address?.isCloseTo(me);
person.sayHayUsing?.("Twitter"); // The person.sayHayUsing method could be not defined
Vous pouvez désormais utiliser ces nouvelles fonctionnalités en toute sécurité dans votre code ! Si vous utilisez déjà @babel/preset-env, vous pouvez employer ces deux opérateurs et ils seront compilés en fonction de vos cibles, comme toute autre fonctionnalité ECMAScript. Si vous utilisiez directement @babel/plugin-proposal-nullish-coalescing-operator ou @babel/plugin-proposal-optional-chaining, vous pouvez les supprimer de votre configuration :
{
"presets": [
["@babel/env", { "targets": ["last 2 versions"] }]
],
"plugins": [
- "@babel/proposal-optional-chaining",
- "@babel/proposal-nullish-coalescing-operator"
]
}
Ces fonctionnalités sont désormais activées par défaut dans @babel/parser : si vous l'utilisiez directement, vous pouvez supprimer les plugins de parseur nullishCoalescingOperator et optionalChaining. Nous avons également activé l'analyse syntaxique pour import() dynamique (inclus dans @babel/preset-env depuis v7.5.0), vous pouvez donc supprimer en toute sécurité le plugin dynamicImport.
Prise en charge de toutes les extensions de fichiers de configuration (#10783 et #10903)
Babel 6 prenait en charge un seul fichier de configuration basé sur JSON : .babelrc.
Dans Babel 7.0.0, nous avons introduit babel.config.js (qui a une logique de résolution différente) et .babelrc.js. Les fichiers de configuration JavaScript sont utiles pour les scénarios nécessitant une flexibilité accrue. Voici la situation qui prévalait :
| Node.js file type | babel.config.__ | .babelrc.__ |
|---|---|---|
.js | ✔️ Supported | ✔️ Supported |
.json | ❌ Not supported | ❔ Supported, with implicit extension |
Nous vous recommandons vivement de lire les différences entre babel.config.js et .babelrc.js !
Plus récemment, Node.js 13.2.0 a été publié avec le support natif des modules ECMAScript et des extensions .cjs/.mjs. Dans Babel 7.7.0, nous avons ajouté le support des fichiers de configuration .cjs pour permettre l'activation de "type": "module" dans package.json sans compromettre Babel, ainsi que le support de babel.config.json pour une configuration statique à l'échelle du projet.
| Node.js file type | babel.config.__ | .babelrc.__ |
|---|---|---|
.js | ✔️ Supported when "type": "module" is not enabled | ✔️ Supported when "type": "module" is not enabled |
.json | ✔️ Supported | ❔ Supported, with implicit extension |
.cjs | ✔️ Supported | ✔️ Supported |
.mjs | ❌ Not supported | ❌ Not supported |
Cette version aligne Babel sur les formats natifs de Node.js en autorisant .babelrc.json, babel.config.mjs et .babelrc.mjs.
| Node.js file type | babel.config.__ | .babelrc.__ |
|---|---|---|
.js | ✔️ Supported | ✔️ Supported |
.json | ✔️ Supported | ✔️ Supported |
.cjs | ✔️ Supported | ✔️ Supported |
.mjs | ✔️ Supported | ✔️ Supported |
Notez que les modules ECMAScript sont asynchrones : c'est pourquoi vous ne pouvez pas les require() et devez utiliser import() qui renvoie une promesse.
Pour ces raisons, ils ne sont utilisables qu'avec les points d'entrée basés sur des promesses ou callbacks. Ils fonctionnent déjà avec @babel/cli, babel-loader et gulp-babel, et seront compatibles avec la prochaine version de rollup-plugin-babel. Notez qu'ils ne sont pas encore supportés par babel-eslint.
Nouvelles options CLI (#9144 et #10887)
Nous avons ajouté deux nouveaux flags à @babel/cli : --copy-ignored et --out-file-extension.
--copy-ignored permet de copier les fichiers non transpilés par Babel, qu'ils soient ignorés via l'option --ignore ou via la configuration "ignore".
Pour maintenir la rétrocompatibilité, dans Babel 7.8.4 la valeur par défaut de l'option --copy-ignored a été changée à true. Pour la désactiver, utilisez --no-copy-ignored.
Ce fonctionnement est similaire à l'option --copy-files, mais --copy-files copie tout fichier non-transpilé car non-JavaScript (par exemple .css ou .json), plutôt que les fichiers explicitement ignorés.
--out-file-extension permet de configurer l'extension des fichiers générés par Babel. Par exemple, si vous transpilez des fichiers .js contenant des modules ECMAScript natifs dans Node.js pour générer du CommonJS, vous devrez peut-être utiliser l'extension .cjs :
$ babel src --out-dir lib-cjs --out-file-extension cjs
Préparation pour Babel 8
Nous commençons les travaux sur Babel 8.0.0 via notre ticket récapitulatif : #10746.
Babel 8 contiendra uniquement des changements cassants : nous publierons simultanément une version mineure incluant tous les correctifs et nouvelles fonctionnalités qui auraient dû figurer dans la 8.0.0.
Bien que nous n'anticipions pas une migration complexe, deux points méritent votre attention :
Extraction de l'analyseur de cibles et des données de compatibilité de preset-env (#10899)
Divers presets tiers utilisent actuellement la logique interne de @babel/preset-env pour analyser les cibles de compilation ou récupérer des informations sur les plugins et polyfills nécessaires.
Nous officialisons ces deux cas d'usage via deux nouveaux paquets publics :
-
@babel/helper-compilation-targets, exportant une fonction pour normaliser les cibles spécifiées et d'autres utilitaires associés :JavaScriptimport getTargets from "@babel/helper-compilation-targets";
getTargets({
browsers: ["last 2 chrome versions"],
node: 10,
}) ==
{
chrome: "77.0.0",
node: "10.0.0",
}; -
@babel/compat-data, contenant des fichiers JSON listant les versions de navigateurs nécessitant chaque plugin ou polyfillcore-js@2. Généré principalement depuiscompat-table, d'autres sources pourront s'ajouter ultérieurement. Pour les données de polyfillscore-js@3, utilisezcore-js-compat.
Nous interdirons l'usage des fichiers internes à partir de Babel 8. Si vous utilisez d'autres API internes, signalez-le nous !
Introduction d'une validation AST plus stricte sur option (#10917)
@babel/types effectue déjà des vérifications pour garantir la validité de l'AST construit. Par exemple, ce code lèvera une erreur car une instruction ne peut remplacer une expression :
// foo = if (true) {}
t.assignmentExpression(
"=",
t.identifier("foo"),
t.ifStatement(t.booleanLiteral(true), t.blockStatement([]))
);
Nous renforçons la validation pour prévenir davantage d'AST invalides : non seulement sur la structure d'arbre, mais aussi sur la validité sémantique. Par exemple, t.identifier("123") sera interdit dans Babel 8 car 123 n'est pas un identifiant valide.
Ces vérifications ne seront pas activées par défaut dans Babel 7.8.0 (risque de rupture trop élevé), mais nous vous encourageons à les tester via la variable d'environnement BABEL_TYPES_8_BREAKING=true. Signalez (ou corrigez !) les plugins incompatibles avec Babel 8.