Vai al contenuto principale

Pianificazione per la 7.0

· Lettura di 20 min
Henry Zhu
Traduzione Beta Non Ufficiale

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

Se non lo sapete già, stiamo pianificando di rilasciare presto una versione 7.0 🙌! Il lavoro è effettivamente iniziato a febbraio, quando volevo semplicemente fare un rilascio per abbandonare il supporto a Node 0.10/0.12 e rimuovere babel-runtime insieme ad altro codice vario. Da allora, abbiamo effettuato rilasci fino alla alpha.20.

Aggiorneremo questo post durante i rilasci beta

Essendo ancora un progetto gestito da volontari, è stato difficile per la maggior parte del team rimanere concentrati e motivati per apportare tutti questi cambiamenti e continuare a mantenere un progetto su cui così tante aziende, bootcamp e strumenti fanno fortemente affidamento. Nel frattempo abbiamo fatto molti progressi: riunioni/appunti settimanali, partecipazione come ospiti invitati agli ultimi incontri TC39, facilitazione sia per RGSoC che per GSoC, e creazione di un Open Collective.

Aggiornamento​

Per la maggior parte dei progetti, l'aggiornamento dovrebbe essere semplice come modificare le dipendenze nel tuo package.json con 7.0.0-beta.0. Per tutto il tempo in cui abbiamo lavorato alla 7.0, l'abbiamo utilizzata in Babel stesso (molto meta) e nel mio posto di lavoro a Behance.

Fisseremo tutte le dipendenze a versioni esatte fino al rilascio ufficiale.

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

Pacchetti specifici:

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

Consultate la nostra guida all'aggiornamento e l'altra guida specifica per autori di strumenti, che aggiorneremo secondo necessità.

Vorrei esaminare alcuni cambiamenti degni di nota per il nostro primo rilascio beta (ha comunque un ambito molto più ristretto in termini di breaking changes rispetto al precedente rilascio 6.0).

Riaffermazione degli obiettivi del progetto​

Prima di approfondire, voglio solo ripetere nuovamente lo scopo di Babel.

Da quando Babel è stato rinominato da 6to5, i browser hanno implementato più specifiche e gli utenti si sono abituati a utilizzare le ultime sintassi/strumenti di build. Tuttavia, non dovrebbe sorprendere che gli obiettivi di Babel non siano cambiati molto.

I nostri due obiettivi vanno di pari passo:

  1. Aiutare gli sviluppatori a trasformare la nuova sintassi in codice retrocompatibile (astrarre il supporto del browser)

  2. Essere un ponte per aiutare TC39 a ricevere feedback sulle nuove proposte ECMAScript e permettere alla community di dire la sua sul futuro del linguaggio.

Pertanto, penso sia riduttivo dire che Babel è una parte vitale della community JavaScript (quasi 10 milioni di download al mese di babel-core) e che ha disperatamente bisogno del suo supporto. (Gli unici talk che ho cercato di tenere riguardano questo punto: JSConf EU, React Rally, TC39). Recentemente ho detto: "Cosa succede se Babel muore"? Cosa succede quando l'attuale gruppo di persone interessate a questo progetto si annoia/si esaurisce/passa ad altro? (E se fosse già successo?). Faremo qualcosa al riguardo? Non voglio solo chiedervi di aiutarci, voi siete già noi in quanto utenti del progetto.

Bene, parliamo allora di alcuni cambiamenti!

Abbandono del supporto per le versioni di Node non più mantenute: 0.10, 0.12, 5 (#4315)​

Il progresso nei progetti open source spesso avviene a costo di aggiornamenti per gli utenti. Per questo motivo, siamo sempre stati esitanti nell'introdurre un aggiornamento di versione maggiore con cambiamenti non retrocompatibili. Abbandonando le versioni di Node non più supportate, possiamo non solo apportare numerosi miglioramenti al codice, ma anche aggiornare dipendenze e strumenti (ESLint, Yarn, Jest, Lerna, ecc.).

👓 Aggiornamenti alle Proposte/Conformità alle Specifiche​

Ovvero le uniche cose di cui a molti di voi importa 😅

Filosofia (Proposte: spec, loose, comportamento predefinito)​

Abbiamo creato un nuovo repository: babel/proposals per monitorare i progressi sulle varie Proposte TC39 e gli incontri.

Ho anche aggiunto una sezione su come accettiamo nuove proposte. La nostra logica di base è che inizieremo ad accettare PR per qualsiasi proposta presentata da un champion TC39 (Stage 0). E le aggiorneremo (con il vostro aiuto!) quando le specifiche cambieranno.

Naturalmente, approfitteremo dell'occasione per essere il più conformi possibile alle specifiche (entro limiti ragionevoli di velocità) come comportamento predefinito. Ciò significa che se avete bisogno di build più veloci/leggere, dovrete usare l'opzione loose che ignorerà deliberatamente alcuni requisiti delle specifiche come controlli runtime e altri edge case. La ragione per cui è un'opzione opzionale è perché ci aspettiamo che sappiate cosa state facendo, mentre altri dovrebbero poter aggiornare babel-preset-env per usare la versione nativa di ogni sintassi o abbandonare completamente Babel senza problemi.

Stage 3: Class Properties (da Stage 2)​

babel-plugin-transform-class-properties: il comportamento predefinito ora è quello che precedentemente era l'opzione "spec", che utilizza Object.defineProperty invece della semplice assegnazione.

Attualmente questo comporta l'interruzione del plugin decoratori legacy (che abbiamo chiamato "transform-decorators" in 7.0) se provate a decorare una proprietà di classe. Dovrete usare l'opzione loose per essere compatibili con la versione dei decoratori nella trasformazione finché non rilasceremo il plugin decoratori Stage 2.

I campi privati sono in lavorazione: #6120

Input

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

Output (predefinito)

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'
});

Output (modalità loose)

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

Stage 3: Object Rest Spread (da Stage 2)​

babel-plugin-transform-object-rest-spread: ora il plugin gestisce chiavi non stringa (es: Number/Symbol)

Input

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 }

Anche non consentito

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

Stage 3: Optional Catch Binding (nuovo)​

babel-plugin-transform-optional-catch-binding: consente agli sviluppatori di usare try/catch senza creare un binding inutilizzato.

Input

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

Output

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

Stage 3: Unicode Property Regex (nuovo)​

babel-plugin-transform-unicode-property-regex: compila le escape di proprietà Unicode (\p{…} e \P{…}) nelle regex Unicode in codice ES5 o ES6 funzionante negli ambienti attuali.

Input

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

Output

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

Stage 3: BigInt (nuovo, non completato)​

babel-plugin-transform-bigint: #6015. Non sarà incluso nei preset Stage perché rallenterebbe il wrapping di tutti gli operatori.

Input

JavaScript
50000n + 60n;

Output

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

Stage 3: Import Dinamici (da Stage 2)​

babel-plugin-syntax-dynamic-import: È sufficiente analizzare la sintassi poiché strumenti come Webpack possono gestire la trasformazione al posto di Babel. Esiste anche un plugin per Node

Input

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

Stage 2: import.meta (solo sintassi)​

Una meta proprietà sintatticamente valida solo nei moduli, pensata per informazioni meta sul modulo attualmente in esecuzione fornite dall'ambiente host.

Input

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

Stage 2: Separatori Numerici (nuovo)​

babel-plugin-transform-numeric-separator: rende i valori numerici più leggibili creando una separazione visiva (_) tra gruppi di cifre.

Input

JavaScript
1_000_000_000
0b1010_0001_1000_0101
0xA0_B0_C0

Output

JavaScript
1000000000
0b1010000110000101
0xA0B0C0

Stage 2: Decoratori (da Stage 1), ancora WIP​

babel-plugin-transform-decorators: #6107

Non consentito

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

Valido

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 supportato (WIP)

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

Stage 2: function.sent (nuovo)​

babel-plugin-transform-function-sent: compila la meta proprietà function.sent, utilizzata all'interno delle funzioni generatrici

Input

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"

Output

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: una scorciatoia per importare/riesportare un namespace. Separato dal vecchio transform-export-extensions che combinava questa proposta con un'altra

Input

JavaScript
export * as ns from "mod";

Output

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

Stage 1: export-default-from​

babel-plugin-transform-export-default: una scorciatoia per importare/riesportare elementi. Separato dal vecchio transform-export-extensions che combinava questa proposta con un'altra

Input

JavaScript
export v from "mod";

Output

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

Stage 1: Optional Chaining (nuovo)​

babel-plugin-transform-optional-chaining: l'operatore (?.) consente di gestire proprietà di oggetti annidati senza preoccuparsi di oggetti intermedi indefiniti.

Input

JavaScript
a?.b = 42;

Output

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

ES2015: new.target​

babel-plugin-transform-new-target: non avevamo mai implementato il supporto per new.target in precedenza, quindi ora esiste un plugin che sarà incluso nei preset ES2015/env.

Esempio

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

Input

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

  test() {
    new.target;
  }
}

Output

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

  test() {
    void 0;
  }
}

🚀 Nuova Funzionalità​

.babelrc.js​

babel/babel#4630

I file di configurazione *.js sono comuni nell'ecosistema JavaScript. ESLint e Webpack utilizzano rispettivamente .eslintrc.js e webpack.config.js.

Scrivere file di configurazione in JavaScript consente configurazioni dinamiche, permettendo di creare un singolo file adattabile a diversi ambienti in modo programmatico.

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

Precedentemente ciò avveniva tramite l'opzione di configurazione env, ora deprecata. Vedi sotto per maggiori dettagli.

TypeScript​

Adesso puoi usare babel-preset-typescript per consentire a Babel di rimuovere i tipi, in modo simile al funzionamento di babel-preset-flow!

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

Stiamo lavorando a una guida su come configurare TypeScript e Babel insieme al team di TypeScript, che dovrebbe essere completata prima del rilascio ufficiale di 7.0. In breve: configuri TypeScript con --noEmit o lo usi in modalità editor/watch in modo da poter utilizzare preset-env e altri plugin di Babel.

Annotazione "Pure" in trasformazioni specifiche per i minificatori​

Dopo la #6209, le classi ES6 transpilate avranno un commento /*#__PURE__*/ che minificatori come Uglify e babel-minify possono utilizzare per l'eliminazione del codice morto. Queste annotazioni potrebbero estendersi anche alle nostre funzioni helper.

Input

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

Output

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

😎 Altre Modifiche di Rottura​

Rimosso babel-preset-flow da babel-preset-react​

Questo cambiamento era necessario perché abbiamo ricevuto molte lamentele da utenti che non utilizzavano tipi/flow: scrivevano JS non valido senza ricevere errori sintattici poiché usavano il preset react.

Inoltre ora abbiamo il preset TypeScript, quindi non aveva più senso includere flow nel preset react stesso.

Integrazioni​

Pacchetti come grunt-babel, gulp-babel, rollup-plugin-babel, ecc. avevano babel-core come dipendenza.

Dopo la v7, pianifichiamo di rendere babel-core una peerDependency come già fa babel-loader. Ciò consente a questi pacchetti di non dover aggiornare la versione major quando l'API di babel-core non cambia. Pertanto sono già pubblicati come 7.0.0 poiché non ci aspettiamo ulteriori modifiche.

Aspetti Organizzativi​

Rimozione di babel-runtime dalle dipendenze di Babel (#5218)​

Babel stesso ha poche dipendenze esterne, ma in 6.x ogni pacchetto dipendeva da babel-runtime per garantire il supporto a built-in come Symbol, Map e Set senza polyfill. Supportando solo Node v4+ (dove questi built-in sono nativi), possiamo eliminare completamente la dipendenza.

Questo era un problema con npm 2 (non raccomandato per Babel 6) e vecchie versioni di yarn, ma non con npm 3 grazie al suo comportamento di deduplicazione.

Con Create React App la dimensione di node_modules cambiava drasticamente quando babel-runtime veniva sollevato.

  • node_modules con npm 3: ~120MB

  • node_modules con Yarn (≤0.21.0): ~518MB

  • node_modules con Yarn (≤0.21.0) e babel-runtime sollevato: ~157MB

  • node_modules con Yarn + PR #2676: ~149MB (tweet)

Sebbene il problema sia stato risolto "a monte" con npm ≥3/yarn aggiornato, possiamo contribuire eliminando la nostra dipendenza da babel-runtime.

Pubblicazione Indipendente dei Pacchetti Sperimentali (#5224)​

Ne parlo in The State of Babel nella sezione Versioning. Github Issue

Ricorderete che dopo Babel 6, Babel è diventato un insieme di pacchetti npm con un proprio ecosistema di preset e plugin personalizzati.

Tuttavia da allora abbiamo sempre utilizzato un sistema di versioning "fisso/sincronizzato" (in modo che nessun pacchetto raggiunga la versione 7.0 o superiore). Quando rilasciamo una nuova versione come v6.23.0, solo i pacchetti con codice aggiornato vengono pubblicati con la nuova versione, mentre gli altri rimangono invariati. Questo funziona nella maggior parte dei casi grazie all'uso di ^ nelle nostre dipendenze.

Sfortunatamente questo sistema richiede che una major version venga rilasciata per tutti i pacchetti quando anche solo uno di essi necessita di un aggiornamento sostanziale. Ciò ci costringe a fare tante piccole modifiche breaking change (non necessarie) oppure a raggruppare numerosi cambiamenti in un unico rilascio. Vorremmo invece differenziare tra pacchetti sperimentali (Stage 0, ecc.) e il resto (es2015).

Ciò significa che intendiamo rilasciare major version per i singoli plugin delle proposte sperimentali quando cambiano le specifiche, senza dover aggiornare tutto Babel. Quindi qualsiasi plugin con stage < 4 sarà soggetto a breaking change tramite incrementi di major version, stesso discorso per gli stage preset stessi se non li rimuoviamo del tutto.

Ad esempio:

Immaginate di usare preset-env (che rimane aggiornato e include attualmente tutto in es2015, es2016, es2017) più un plugin sperimentale. Decidete anche di usare object-rest-spread perché è interessante.

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

Se le specifiche di una proposta sperimentale cambiano, dovremmo poter apportare breaking change e rilasciare una major version solo per quel plugin. Poiché ciò influisce solo su quel plugin, non impatta il resto e gli utenti possono aggiornare quando possibile. Vogliamo solo assicurarci che gli utenti aggiornino all'ultima versione delle proposte sperimentali quando possibile, fornendo anche strumenti per farlo automaticamente ove ragionevole.

💀 Possibili Deprecazioni​

Deprecare l'opzione "env" in .babelrc​

babel/babel#5276 MODIFICA: Abbiamo modificato il comportamento per renderlo più intuitivo e non l'abbiamo rimossa.

L'opzione di configurazione "env" (da non confondere con babel-preset-env) è stata fonte di confusione per gli utenti, come dimostrano i numerosi issue segnalati.

Il comportamento attuale unisce i valori di configurazione con quelli di livello superiore, risultando poco intuitivo: gli sviluppatori finiscono per non inserire nulla al livello principale e duplicare tutti i preset/plugin sotto env separati.

Per eliminare la confusione (e aiutare gli utenti avanzati), stiamo valutando di rimuovere completamente l'opzione env e raccomandare invece il formato di configurazione JS proposto (vedi sotto).

Deprecare i preset ES20xx (fatto)​

Abbiamo già deprecato preset-latest tempo fa, e ES2016/ES2017 in precedenza Creare preset annuali è problematico (pacchetto/dipendenza aggiuntiva, problemi di squatting su npm a meno di usare scoped packages)

Gli sviluppatori non dovrebbero nemmeno dover scegliere quale preset annuale usare. Se deprechiamo questi preset, tutti potranno usare babel-preset-env che si aggiorna automaticamente al progredire delle specifiche.

🤔 Domande​

Deprecare/Rinominare/Rimuovere i preset Stage X (fatto)​

MODIFICA: Lo abbiamo fatto e abbiamo scritto un intero post per spiegarlo.

Molti nella community (e nel TC39) hanno espresso preoccupazioni riguardo ai preset Stage X. Credo di averli aggiunti principalmente per offrire un percorso di migrazione semplice da Babel 5 a Babel 6 (in origine c'era un'opzione "stage").

Sebbene vogliamo uno strumento facile da usare, molti sviluppatori/aziende utilizzano costantemente questi preset "non ancora JavaScript" in produzione. "Stage 0" non trasmette lo stesso messaggio di babel-preset-dont-use-this-stage-0.

Ariya ha recentemente creato un sondaggio illuminante che spiega esattamente di cosa sto parlando

Gli sviluppatori spesso non sanno quali funzionalità appartengano a quale versione di JavaScript (e non dovrebbero saperlo). Tuttavia è problematico quando iniziamo a pensare che proposte sperimentali siano già parte dello standard.

Molti progetti open source (Babel incluso 😝), tutorial e talk conferenze usano stage-0. React promuove JSX, proprietà delle classi (ora Stage 3) e rest/spread (ora Stage 3), facendoci credere siano JavaScript nativo grazie a Babel. Rimuovere questa astrazione aiuterebbe a comprendere meglio i compromessi nell'usare plugin Stage X.

È anche più semplice mantenere un preset personalizzato che aggiornare costantemente i preset Stage.

Spesso vedo persone dire "Voglio object rest, quindi abilito stage 2". Così abilitano inconsapevolmente altre funzionalità sperimentali non necessarie. Inoltre, con l'evoluzione degli stage, chi non usa shrinkwrap o yarn vedrà apparire nuove funzionalità senza preavviso. Se una proposta viene abbandonata, potrebbe sparire dal codice. @glenjamin

Utilizzo di pacchetti npm con scope (completato, @babel/x)​

Sembra che la maggior parte di chi comprende i pacchetti con scope sia favorevole?

Vantaggi

  • Nessun problema di naming (motivo originale della proposta)

Molti nomi sono già occupati (preset-es2016, preset-es2017, ecc.). Il trasferimento è complesso e naming ambigui potrebbero far credere che pacchetti siano ufficiali.

Svantaggi

  • Necessità di migrare alla nuova sintassi

  • Supporto limitato su strumenti non-npm (lock-in)

  • Statistiche download assenti senza alias ai vecchi nomi

Probabilmente rimanderemo: comunque non è una breaking change essendo solo un cambio di nome.

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

MODIFICA: abbiamo separato l'uso di @babel/runtime e core-js in transform-runtime

"regeneratorRuntime is not defined" - errore segnalato costantemente

Serve una soluzione migliore per gestire built-in/polyfill.

  • Gli sviluppatori vogliono usare generatori/async senza sapere cosa sia regenerator-runtime

  • Confusione sul perché serva un runtime e perché Babel non compili Promise o Object.assign

  • Difficoltà nel distinguere il plugin transform-runtime dal runtime babel-runtime

  • Lamentele sulla dimensione del codice: babel-polyfill include tutti i polyfill (nonostante useBuiltIns) e pochi conoscono external-helpers

Possiamo combinare/sostituire questi pacchetti per ottenere un'esperienza predefinita più semplice?

Prossimi passi​

Vogliamo che la comunità esegua l'aggiornamento e fornisca feedback/segnalazioni. Probabilmente ci sarà un'intensa attività iniziale che potrebbe essere travolgente, quindi chiediamo pazienza. Apprezziamo l'aiuto nel triage dei problemi, nella stesura di documentazione/guide di aggiornamento/suggerimenti e nello sviluppo di codemod per facilitare transizioni più fluide. Essendo Babel così pervasivo nell'ecosistema JavaScript, aggiornare un singolo pacchetto potrebbe non bastare a causa delle dipendenze da altri plugin Babel della comunità. Non aspetteremo passivamente che gli utenti migrino: serve un lavoro attivo per evitare che metà della comunità resti bloccata sulla versione 6.x il prossimo anno. Non vogliamo lasciare indietro progetti (e persone). Comunicateci come possiamo aiutare, e vi chiediamo di fare lo stesso per noi e per il resto della comunità.

Sostenibilità del progetto​

Un ringraziamento al mio team di Behance per permettermi di dedicare tempo lavorativo a Babel; siamo ancora sostanzialmente l'unica azienda che supporta attivamente il progetto durante l'orario d'ufficio. Sono grato di poter contribuire durante l'orario lavorativo invece che solo dopo lavoro/weekend, e spero che più maintainer possano avere questa opportunità in futuro. (Speriamo di essere un buon esempio di come le aziende possano sostenere progetti open source che usano senza necessariamente "possedere").

Le risorse dell'Open Collective non sono ancora sufficienti per retribuire qualcuno a tempo pieno: la donazione più consistente è stata di $750 da Webflow, mentre le ricorrenti mensili arrivano a $100 da singoli/aziende. Dobbiamo lavorare per coinvolgere più realtà, come hanno fatto AMP/Google (@jridgewell, recentemente entrato nel team, può dedicare tempo lavorativo con ottimi risultati).

Chiedete alla vostra azienda di sponsorizzarci tramite l'Open Collective, segnalateci cosa manca, come potete contribuire. Non serve una ragione specifica per partecipare. Se vi sta a cuore la sostenibilità del progetto a lungo termine, coinvolgete il vostro team e partecipate attivamente.

Futuro​

Post 7.0: ci sono molte strade da esplorare (già discusse anni fa): separare la traversata dai plugin (visitor asincroni?), AST immutabili, estensioni sintattiche? Sul fronte infrastrutturale: integrazione con test262 e smoke test, workflow GitHub migliorato per trasformare proposte in funzionalità, codemod per aggiornamenti automatici.

Seguite discussioni e verbali riunioni su babel/notes e partecipate!

Ringraziamenti​

Spero di rilasciare presto la versione ufficiale, ma ricordo che l'open source vive di manutenzione quotidiana costante, non solo di cicli di rilascio eclatanti che abbandonano gli utenti. Potremmo impiegare più tempo per sistemare bug e aggiornare l'ecosistema.