7.14.0 rilasciata: Nuove funzionalità per le classi abilitate di default, TypeScript 4.3 e migliore interoperabilità CommonJS

Traduzione Beta Non Ufficiale

Questa pagina è stata tradotta da PageTurner AI (beta). Non ufficialmente approvata dal progetto. Hai trovato un errore? Segnala problema →

Babel 7.14.0 è disponibile!

Questa versione abilita di default i class fields e i private methods (promossi a Stage 4 durante la recente riunione di TC39 di aprile!) e aggiunge i brand checks per i private fields e gli static class blocks all'opzione shippedProposals di @babel/preset-env.

Abbiamo aggiunto il supporto per le async do expressions di Stage 1 (tramite @babel/plugin-proposal-async-do-expressions), che estendono la proposta Stage 1 delle do expression.

Grazie a Sosuke Suzuki e Pig Fang, Babel supporta ora le funzionalità di TypeScript 4.3. @babel/parser include anche una nuova opzione per interpretare correttamente i file di dichiarazione TypeScript.

Infine, abbiamo introdotto una nuova opzione importInterop: node per semplificare la creazione di moduli duali compilando gli import ECMAScript in CommonJS seguendo la semantica di Node.js.

Potete consultare l'intero changelog su GitHub.

Se tu o la tua azienda volete supportare Babel e l'evoluzione di JavaScript, potete donare sul nostro Open Collective o, meglio ancora, collaborare direttamente all'implementazione di nuove proposte ECMAScript! Come progetto guidato da volontari, dipendiamo dal supporto della comunità per finanziare il nostro lavoro a beneficio degli utenti JavaScript. Contattateci a team@babeljs.io per discutere!

Novità principali

Nuove funzionalità per le classi abilitate di default

Le proposte per i class fields e i private methods hanno appena raggiunto lo Stage 4 e saranno ufficialmente incluse in ECMAScript 2022! Si tratta più di una formalità poiché la semantica era già definitiva e sono già implementati in tutti i principali browser.

Potete trovare maggiori dettagli su questa nuova sintassi su MDN (campi pubblici, campi e metodi privati).

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

Pertanto, potete rimuovere @babel/plugin-proposal-class-properties e @babel/plugin-proposal-private-methods, poiché sono ora abilitati di default in @babel/preset-env.

attenzione

Webpack supporta nativamente questa sintassi a partire dalla v5.36.0. Per versioni precedenti, una soluzione alternativa funzionante con configurazioni Webpack semplici consiste nell'abilitare manualmente il plugin acorn-stage3, installando acorn-stage3 e aggiungendo queste righe all'inizio del file 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"));

Se questo non funziona per voi, o se utilizzate un altro strumento che non supporta i class fields, dovrete comunque utilizzare i plugin Babel per trasformarli.

Se stai usando l'opzione shippedProposals di @babel/preset-env, ora include anche i plugin @babel/plugin-proposal-private-property-in-object (introdotto nella 7.10) e @babel/plugin-proposal-class-static-block (introdotto nella 7.12): puoi rimuoverli tranquillamente dalla tua configurazione.

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

Migliore interoperabilità ESM-CJS

Quando si importa un file CommonJS da un modulo ECMAScript, Node.js ha una semantica diversa rispetto alla maggior parte degli strumenti nell'ecosistema JavaScript.

Supponi di dipendere dalla seguente libreria:

JavaScript

export default function two() {
  return 2;
}

E che l'autore di questa libreria non la pubblichi così com'è, ma la compili in CommonJS:

JavaScript

"use strict";

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

function two() {
  return 2;
}

Quando importi questa libreria con Babel (o TypeScript, Rollup o strumenti simili) e compili il tuo codice in CommonJS, apparirà così:

JavaScript

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

Un giorno decidi di fornire due versioni del tuo codice: una compilata in CommonJS e una che utilizza moduli ECMAScript nativi.

Mentre la versione compilata funziona, quella ESM genererà TypeError: two is not a function. Questo perché in Node.js, l'import di default non corrisponde a exports.default della dipendenza, ma all'intero oggetto module.exports.

Potresti modificare il tuo codice in:

JavaScript

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

Tuttavia, questo nuovo codice ha un problema: ora non funziona quando compilato, perché two.default non è una funzione.

Babel v7.14.0 aggiunge una nuova opzione importInterop: "node" nel plugin @babel/plugin-transform-modules-commonjs che permette alle istruzioni import di corrispondere al comportamento nativo di Node.js. Puoi leggere maggiori dettagli su questa opzione nella documentazione.

Nicolò del nostro team ha anche contribuito un'opzione simile per @rollup/plugin-commonjs, che sarà disponibile nella prossima release. Il nostro obiettivo è aiutare l'ecosistema nella migrazione verso i moduli ECMAScript nativi fornendo un percorso di transizione più semplice.

TypeScript 4.3

La nuova versione di TypeScript, che sarà rilasciata come stabile a maggio, introduce diverse nuove funzionalità:

• Modificatori override negli elementi delle classi

• Firme di indice statiche ([key: KeyType]: ValueType) nelle classi

• get/set nelle dichiarazioni di tipo

Puoi leggere maggiori dettagli nel post di rilascio di TypeScript 4.3. Questo supporto è disponibile tramite @babel/preset-typescript.

Espressioni async do

Le espressioni async do sono una proposta di Stage 1 basata sulla proposta delle espressioni do.

Permettono di utilizzare blocchi asincroni all'interno di codice sincrono, valutando tali blocchi come promise:

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!"

Puoi testare questa proposta (e inviare feedback!) aggiungendo i plugin @babel/plugin-proposal-do-expressions e @babel/plugin-proposal-async-do-expressions alla tua configurazione Babel.

attenzione

Queste proposte sono altamente sperimentali. Possono e probabilmente continueranno a evolversi. Potrebbero volerci anni prima che vengano standardizzate, e potrebbero persino essere rifiutate definitivamente. Puoi testarle, ma non le raccomandiamo per ambienti di produzione.

---

Commenti o domande? Partecipa alla discussione su GitHub!