Vai al contenuto principale

Babel 7 rilasciato

· Lettura di 27 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 →

Dopo quasi 2 anni, 4000 commit, oltre 50 pre-release e tanto aiuto, siamo entusiasti di annunciare il rilascio di Babel 7. Sono passati quasi 3 anni dal rilascio di Babel 6! Ci sono molti componenti in movimento, quindi abbiate pazienza con noi nelle prime settimane dopo il rilascio. Babel 7 è una versione enorme: l'abbiamo reso più veloce, abbiamo creato uno strumento di aggiornamento, configurazioni JS, "override" di configurazione, più opzioni per dimensioni/minificazione, JSX Fragments, TypeScript, nuove proposte e molto altro!

Se apprezzi il lavoro che stiamo facendo su Babel, puoi sponsorizzare Babel su Open Collective, supportarmi su Patreon o coinvolgere te o la tua azienda con Babel come parte del lavoro. Apprezziamo la proprietà collettiva di questo progetto vitale nella comunità JavaScript!

Ci siamo! 🎉​

Il software non sarà mai perfetto, ma siamo pronti a rilasciare qualcosa che è già stato utilizzato in produzione da tempo! @babel/core ha già raggiunto 5,1 milioni di download/mese grazie al suo utilizzo in strumenti come Next.js 6, vue-cli 3.0, React Native 0.56 e persino nel frontend di WordPress.com 🙂!

Il ruolo di Babel​

Vorrei iniziare questo post riproponendo il ruolo di Babel nell'ecosistema JavaScript negli ultimi anni.

Il problema iniziale era che, a differenza dei linguaggi lato server, non c'era modo di garantire che ogni utente avesse lo stesso supporto per JavaScript perché gli utenti potrebbero utilizzare browser diversi con livelli di supporto variabili (soprattutto versioni più vecchie di Internet Explorer). Se gli sviluppatori volevano usare nuova sintassi (ad es. class A {}), gli utenti su browser obsoleti avrebbero semplicemente ottenuto uno schermo vuoto a causa del SyntaxError.

Babel ha fornito agli sviluppatori un modo per utilizzare le ultime sintassi JavaScript consentendo loro di non preoccuparsi di come renderle retrocompatibili per i propri utenti, traducendole (class A {} in var A = function A() {}).

Grazie alla sua capacità di trasformare il codice JavaScript, può anche essere utilizzato per implementare nuove funzionalità: è così diventato un ponte per aiutare TC39 (il comitato che specifica il linguaggio JavaScript) a ricevere feedback su proposte di idee JavaScript e per consentire alla comunità di dire la sua sul futuro del linguaggio.

Babel è fondamentale per lo sviluppo JavaScript oggi. Attualmente ci sono oltre 1,3 milioni di repository dipendenti su GitHub, 17 milioni di download su npm al mese e centinaia di utenti inclusi molti framework principali (React, Vue, Ember, Polymer) e aziende (Facebook, Netflix, Airbnb). È diventato una tale base per lo sviluppo JavaScript che molte persone non sanno nemmeno che viene utilizzato. Anche se non lo usi personalmente, è altamente probabile che le tue dipendenze utilizzino Babel.

I manutentori sono persone​

Babel ha un'enorme influenza non solo sul futuro del linguaggio stesso ma anche sulla sua comunità e sul suo ecosistema. Ma nonostante tutta questa responsabilità, Babel è solo un progetto guidato dalla comunità gestito da un paio di volontari.

È stato solo l'anno scorso che alcuni membri del team hanno potuto incontrarsi di persona per la prima volta:

Per quanto questo sia un annuncio, vorrei cogliere l'occasione per ricordare a tutti lo stato attuale di questo progetto.

Mi sono unito personalmente pochi mesi prima del rilascio della versione 6.0, che ha generato non poche controversie e reazioni negative. Gran parte dell'accoglienza ha portato all'esaurimento dei maintainer esistenti (incluso Sebastian, creatore di Babel) e alcuni di noi rimasti abbiamo preso le redini.

Come molti maintainer, siamo incappati nel ruolo per caso. Molti di noi non avevano alcuna formazione formale sul funzionamento dei compilatori o sulla gestione di progetti open source. Ironia della sorte, io stesso ho evitato appositamente di specializzarmi in Informatica all'università per non seguire corsi su compilatori o argomenti di basso livello, che mi sembravano poco interessanti e difficili. Eppure mi sono ritrovato attratto da strumenti, linter, Babel e JavaScript come linguaggio.

Vorrei incoraggiare tutti a esaminare i progetti open source da cui dipendete e a sostenerli (sia con tempo che con supporto economico, ove possibile).

Molti maintainer non sono esperti per natura nelle loro aree di lavoro; c'è molto da realizzare semplicemente iniziando a lavorare. Affrontate il ruolo con curiosità e umiltà, qualità essenziali per un maintainer. Il mio desiderio è una visione del progetto che vada oltre il semplice svolgimento di "compiti".

Babel non è un'azienda né un team open source interno a grandi compagnie come Facebook. Ci sono solo pochi volontari che lavorano al progetto, ed è passato appena qualche mese da quando ho fatto il passo di lasciare il mio lavoro per diventare l'unico a tempo pieno. Ma le persone vanno e vengono, hanno vite oltre questo "hobby", crescono famiglie, cambiano interessi o lavoro. Stiamo facendo abbastanza per sostenere questi pilastri fondamentali del nostro lavoro? Come mantenere l'open source accogliente e inclusivo ma con confini chiari? Possiamo imparare dalle esperienze di altri maintainer?

Nonostante l'open source abbia conquistato il mondo del software, possiamo davvero considerarlo sano senza guardare alle persone che lo rendono possibile?

#BabelSponsorsEverything​

La sostenibilità dell'open source oggi sembra un cesto per le offerte. È facile riconoscere il valore che i progetti portano a migliaia di aziende e sviluppatori, ma raramente questo valore si traduce in sostegno concreto per chi ci lavora. Esistono molti modi per supportare l'open source, ma non tutti funzionano per ogni progetto o persona.

Ora passiamo alle novità!!

Modifiche Incompatibili Principali​

Stiamo documentando tutto nella nostra Guida alla Migrazione. Molte di queste modifiche possono essere applicate automaticamente con il nuovo strumento babel-upgrade, o implementate successivamente.

  • Rimozione supporto per versioni Node non mantenute: 0.10, 0.12, 4, 5 (dettagli)

  • Migrazione allo spazio dei nomi @babel utilizzando pacchetti "scoped" (dettagli). Questo aiuta a differenziare i pacchetti ufficiali: babel-core diventa @babel/core (ed evita il namespace squatting)

  • Rimozione (e cessazione della pubblicazione) dei preset annuali (preset-es2015, ecc.) (dettagli). @babel/preset-env sostituisce queste funzionalità includendo tutte le aggiunte annuali e la possibilità di specificare browser target

  • Abbandono anche dei preset "Stage" (@babel/preset-stage-0, ecc.) a favore dell'adozione individuale delle proposte. Rimozione parallela delle proposte da @babel/polyfill per impostazione predefinita (dettagli). Si consiglia di leggere l'intero post per maggiori spiegazioni.

  • Ridenominazione di alcuni pacchetti: qualsiasi plugin per proposte TC39 avrà ora -proposal invece di -transform (dettagli). Ad esempio @babel/plugin-transform-class-properties diventa @babel/plugin-proposal-class-properties.

  • Introduzione di una peerDependency su @babel/core per pacchetti user-facing specifici (es. babel-loader, @babel/cli, ecc.) (dettagli)

babel-upgrade​

babel-upgrade è un nuovo strumento che automatizza le modifiche per l'aggiornamento: attualmente gestisce dipendenze in package.json e configurazioni .babelrc.

Consigliamo di eseguirlo direttamente su un repository git con npx babel-upgrade, oppure installarlo globalmente via npm i babel-upgrade -g.

Per modificare i file, è possibile aggiungere i flag --write e --install.

Shell
npx babel-upgrade --write --install

Vi invitiamo a contribuire segnalando issue o inviando PR per facilitare la transizione a Babel 7! L'obiettivo futuro è utilizzare questo strumento per tutti i breaking change e creare un bot che proponga PR di aggiornamento ai progetti.

File di Configurazione JavaScript​

Introduciamo babel.config.js. Non sostituisce .babelrc né è obbligatorio, ma risulta utile in casi specifici.

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

Ecco un esempio di compilazione condizionata all'ambiente "production" (già realizzabile con l'opzione "env" in .babelrc):

JavaScript
var env = process.env.NODE_ENV;
module.exports = {
  plugins: [
    env === "production" && "babel-plugin-that-is-cool"
  ].filter(Boolean)
};

babel.config.js adotta una risoluzione configurazione diversa da .babelrc. Risolve sempre la configurazione dal file stesso, a differenza del precedente comportamento di ricerca ricorsiva verso l'alto. Ciò abilita la funzionalità overrides descritta di seguito.

Configurazione Selettiva con overrides​

Recentemente ho pubblicato un post con riflessioni sulla pubblicazione e utilizzo/compilazione di pacchetti ES2015+.

Esiste una sezione che approfondisce l'utilizzo di una nuova chiave nella configurazione di Babel chiamata overrides, che consente di specificare configurazioni diverse per ogni glob.

JavaScript
module.exports = {
  presets: [
    // default config...
  ],
  overrides: [{
    test: ["./node_modules"],
    presets: [
      // config for node_modules
    ],
  }, {
    test: ["./tests"],
    presets: [
      // config for tests
    ],
  }]
};

Questo permette a un'applicazione che richiede configurazioni di compilazione differenti per test, codice client e codice server di evitare di creare un nuovo file .babelrc per ogni cartella.

Velocità 🏎​

Babel stesso è più veloce, quindi dovrebbe richiedere meno tempo per la build! Abbiamo apportato molte modifiche per ottimizzare il codice e abbiamo accettato patch dal team di v8. Siamo lieti di far parte del Web Tooling Benchmark insieme a molti altri ottimi strumenti JavaScript.

Opzioni di Output​

Babel supporta da tempo opzioni per preset e plugin. Per ricapitolare, è possibile racchiudere il plugin in un array e passargli un oggetto di opzioni:

{
  "plugins": [
-   "pluginA",
+   ["pluginA", {
+     // options here
+   }],
  ]
}

Abbiamo apportato modifiche all'opzione loose di alcuni plugin e aggiunto nuove opzioni per altri! Nota: utilizzando queste opzioni stai optando per comportamenti non conformi alle specifiche e dovresti sapere cosa stai facendo; ciò potrebbe creare problemi quando disattivi la compilazione per usare la sintassi nativamente. Queste opzioni sono più adatte a librerie, se proprio necessarie.

  • Per le classi, class A {} non includerà più l'helper classCallCheck.
JavaScript
class A {}
var A = function A() {
-  _classCallCheck(this, A);
};
  • È presente una nuova opzione per casi in cui ogni ciclo for-of riguarda solo array: ["transform-for-of", { "assumeArray": true }]
JavaScript
let elm;
for (elm of array) {
  console.log(elm);
}
JavaScript
let elm;

for (let _i = 0, _array = array; _i < _array.length; _i++) {
  elm = _array[_i];
  console.log(elm);
}
  • Escludiamo il plugin transform-typeof-symbol in modalità loose per preset-env #6831

Abbiamo osservato che molte librerie lo fanno già, quindi abbiamo deciso di renderlo il comportamento predefinito.

Nota che il comportamento predefinito è di rispettare il più possibile le specifiche, così che disattivare Babel o usare preset-env sia seamless, rispetto a privilegiare un output più piccolo per risparmiare byte (ogni progetto può valutare questo compromesso). Pianifichiamo di migliorare documentazione e strumenti per semplificare questa scelta.

Supporto alle Annotazioni "Pure"​

Dopo #6209, le classi ES6 transpilate sono annotate con un commento /*#__PURE__*/ che fornisce un hint a minifier come Uglify e babel-minify per l'eliminazione del codice morto. Queste annotazioni sono aggiunte anche ad altre funzioni helper.

JavaScript
class C {
  m() {}
}
JavaScript
var C =
/*#__PURE__*/
function () {
  // ...
}();

Potrebbero esserci ulteriori opportunità per hint di ottimizzazione nei minifier, fateci sapere!

Sintassi​

Supporto alle Proposte TC39​

Vorrei ribadire che abbiamo rimosso i preset Stage a favore di una politica che richiede agli utenti di aderire esplicitamente a proposte < Stage 4.

La preoccupazione è che stiamo abilitando automaticamente sintassi non definitive o che potrebbero cambiare, senza che gli utenti ne siano consapevoli. Questo non è accettabile, specialmente per proposte allo Stage 0 o 1. Questo post spiega il ragionamento dietro le nuove idee.

Ecco un breve elenco di alcune nuove sintassi supportate da Babel (ricordate che questo set di funzionalità è in evoluzione e potrebbe essere aggiunto/rimosso/bloccato) e quelle introdotte nella versione 7:

È difficile per chiunque tenere traccia di tutte le proposte, quindi tentiamo di farlo su babel/proposals.

Supporto TypeScript (@babel/preset-typescript)​

Abbiamo collaborato con il team di TypeScript per implementare in Babel l'analisi e la trasformazione della sintassi dei tipi tramite @babel/preset-typescript, analogamente a come gestiamo Flow con @babel/preset-flow.

Per maggiori dettagli, consulta questo articolo del team TypeScript!

Prima (con i tipi):

interface Person {
  firstName: string;
  lastName: string;
}

function greeter(person : Person) {
  return "Hello, " + person.firstName + " " + person.lastName;
}

Dopo (tipi rimossi):

function greeter(person) {
  return "Hello, " + person.firstName + " " + person.lastName;
}

Sia Flow che TypeScript sono strumenti che permettono agli sviluppatori JavaScript di sfruttare la tipizzazione graduale, e vorremmo supportarli entrambi in Babel. Intendiamo continuare a collaborare strettamente con i rispettivi team di Facebook e Microsoft (oltre che con la comunità generale) per mantenere la compatibilità e supportare nuove funzionalità.

Questa integrazione è piuttosto recente, quindi è possibile che alcune sintassi non siano pienamente supportate. Apprezziamo il tuo aiuto nel segnalare problemi e magari inviare una PR!

Supporto ai frammenti JSX (<>)​

Come menzionato nel blog di React, il supporto per i frammenti JSX è disponibile a partire dalla versione beta.31.

JSX
render() {
  return (
    <>
      <ChildA />
      <ChildB />
    </>
  );
}

// output 👇

render() {
  return React.createElement(
    React.Fragment,
    null,
    React.createElement(ChildA, null),
    React.createElement(ChildB, null)
  );
}

Modifiche agli helper di Babel​

La PR per babel-upgrade è in lavorazione

@babel/runtime è stato suddiviso in @babel/runtime e @babel/runtime-corejs2 (PR). Il primo contiene solo le funzioni helper di Babel, mentre il secondo include anche le funzioni di polyfill (es. Symbol, Promise).

Babel potrebbe dover inserire nel codice alcune funzioni riutilizzabili. Chiamiamo queste "funzioni helper" proprio come le funzioni condivise tra moduli.

Un esempio è la compilazione di una class (senza la modalità loose attivata):

Le specifiche richiedono che una classe venga chiamata con new Person(), ma se viene compilata in una funzione, tecnicamente si potrebbe fare Person(), quindi includiamo un controllo runtime per questo.

JavaScript
class Person {}
JavaScript
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }

var Person = function Person() {
  _classCallCheck(this, Person);
};

Con @babel/plugin-transform-runtime e @babel/runtime (come dipendenza), Babel può estrarre le singole funzioni e richiedere solo quelle modulari per ottenere un output più compatto:

JavaScript
var _classCallCheck = require("@babel/runtime/helpers/classCallCheck");

var Person = function Person() {
  _classCallCheck(this, Person);
};

Lo stesso può essere fatto con external-helpers e rollup-plugin-babel. Stiamo valutando la possibilità di automatizzare questo processo in futuro. Presto pubblicheremo un articolo dedicato sugli helper di Babel.

Polyfill automatici (sperimentale)​

I polyfill sono necessari per abilitare funzionalità come Promise e Symbol in ambienti che non le supportano. È importante distinguere tra ciò che fa Babel come compilatore (trasforma la sintassi) e un polyfill (implementa funzioni/oggetti integrati).

È semplice importare qualcosa che copre tutto come @babel/polyfill:

JavaScript
import "@babel/polyfill";

Ma include l'intero polyfill, e potresti non dover importare tutto se i browser lo supportano già. È lo stesso problema che @babel/preset-env risolve per la sintassi, quindi applichiamo lo stesso approccio ai polyfill. L'opzione useBuiltins: "entry" fa questo suddividendo l'import originale solo negli import necessari.

Possiamo fare meglio importando solo i polyfill effettivamente utilizzati nel codicebase. L'opzione "useBuiltIns: "usage" è il nostro primo tentativo per abilitare questa funzionalità (documentazione).

Analizzerà ogni file e inietterà un'importazione all'inizio di ciascun file se quel built-in viene "utilizzato" nel codice. Ad esempio:

JavaScript
import "core-js/modules/es6.promise";
var a = new Promise();

L'inferenza non è perfetta, quindi potrebbero verificarsi falsi positivi.

JavaScript
import "core-js/modules/es7.array.includes";
a.includes // assume a is an []

Altre idee in questo ambito includono l'uso di polyfill.io se si è disposti a fare affidamento su un servizio esterno (o leggere come Kent C. Dodds lo ha utilizzato per creare un servizio ospitato in PayPal).

Varie​

Babel Macros 🎣​

Uno dei punti di forza di Babel è la sua estensibilità tramite plugin. Nel corso degli anni, Babel è evoluto da semplice compilatore "6to5" a una piattaforma di trasformazione del codice, abilitando ottimizzazioni fantastiche sia per l'esperienza utente che per quella degli sviluppatori. Sono stati sviluppati innumerevoli plugin per Babel per librerie specifiche e casi d'uso, migliorando prestazioni e capacità di API che altrimenti non sarebbero possibili (alcune "librerie" vengono completamente transpilate, eliminando del tutto il runtime).

Purtroppo, aggiungere questi plugin al proprio codice richiede modifiche alla configurazione (operazione non consentita da toolkit come create-react-app) e aumenta la complessità perché gli sviluppatori devono conoscere quali plugin operano su un file per prevedere gli effetti sul codice. Questi problemi sono stati risolti da babel-plugin-macros di Kent C. Dodds!

Una volta installato babel-plugin-macros e aggiunto alla configurazione (è incluso in create-react-app v2), non sarà più necessario modificare la configurazione per utilizzare le macro. Inoltre, è più semplice creare trasformazioni personalizzate per casi d'uso specifici della tua applicazione.

Scopri di più su babel-plugin-macros nel nostro post originale "Trasformazione del codice senza configurazione con babel-plugin-macros".

Targeting dei Moduli​

Babel ha sempre bilanciato l'impatto dimensionale delle trasformazioni con le funzionalità offerte agli sviluppatori. In Babel 7, è diventato più semplice configurare il supporto per il crescente pattern module/nomodule.

Diversi strumenti CLI per framework web popolari (1, 2) sfruttano già questo supporto, riducendo di circa il 20% il JavaScript inviato agli utenti nelle applicazioni transpilate con Babel.

Metadati del Chiamante e Default Migliorati​

Abbiamo aggiunto un'opzione caller in @babel/core per permettere agli strumenti di passare metadati a preset e plugin. Ad esempio: babel-loader può aggiungere elementi come questo affinché preset-env disabiliti automaticamente la trasformazione dei moduli (analogamente per rollup):

JavaScript
babel.transform("code;", {
  filename,
  presets: ["@babel/preset-env"],
  caller: {
    name: "babel-loader",
    supportsStaticESM: true,
  },
});

Questa novità è entusiasmante perché consente agli strumenti di fornire impostazioni predefinite più intelligenti con meno configurazione! Per webpack/rollup possiamo delegare automaticamente la trasformazione dei moduli ai loro sistemi invece che a Babel (stesso principio per import("a")). In futuro altri strumenti sfrutteranno questa funzionalità!

class C extends HTMLElement {}​

Uno dei nostri problemi più vecchi ottiene un titolo dedicato (dettagli)

Babel ha sempre avuto la limitazione di non poter estendere gli oggetti built-in nativi (Array, Error, ecc.) ma ora ci riesce! Abbiamo ricevuto numerose segnalazioni su questo; 🎉 festeggiate come Andrea!

Questa modifica è stata implementata nel plugin per le classi, quindi sarà abilitata automaticamente se usate preset-env.

Modifiche al Sito Web 🌏​

Abbiamo migrato il nostro sito da Jekyll a Docusaurus!

Stiamo ancora configurando le traduzioni con Crowdin, e con il rilascio di Babel 7, saremo pronti per avviare questo processo.

REPL​

Abbiamo riscritto la REPL come Componente React e abbiamo collaborato con Ives per una migliore integrazione con CodeSandbox. Ciò permette di installare qualsiasi plugin o preset da npm nella REPL e di ricevere tutti gli aggiornamenti di CodeSandbox.

Partecipiamo nuovamente a Rails Girls Summer of Code! Questa volta Gyujin e Sujin hanno lavorato all'integrazione di babel-time-travel di Boopathi nella REPL, che potete già testare!

Ci sono tantissime opportunità per contribuire a migliorare Babel, gli AST e altri strumenti!

Abbiamo una Canzone 🎶​

Hallelujah—In Lode di Babel

Un giorno Angus ci ha generosamente donato una canzone che ho trovato magnifica, quindi perché non renderla il nostro "inno ufficiale"? E Shawn ne ha realizzato un'ottima cover qui.

La trovate nel nostro repository in SONG.md. Speriamo che altri progetti seguano questo esempio!

Prossimi Passi​

  • Babel è intrinsecamente legato a ciò che compila: JavaScript. Finché ci saranno nuove aggiunte da proporre/lavorare, ci sarà lavoro da fare. Ciò include il tempo/l'impegno per implementare e mantenere la sintassi ancora prima che diventi "stabile". Ci preoccupiamo dell'intero processo: il percorso di aggiornamento, l'educazione sulle nuove funzionalità, l'insegnamento degli standard/progettazione del linguaggio, la facilità d'uso e l'integrazione con altri progetti.

    • In relazione: abbiamo quasi completato l'implementazione della nuova proposta dei decoratori in Babel grazie a Nicolò. È stato un lungo viaggio (ci è voluto più di un anno!) perché la nuova proposta è completamente diversa e molto più potente della precedente, ma ci siamo quasi 🎉. Puoi aspettarti che venga rilasciata in una delle prossime versioni minori, insieme a un articolo del blog che spiegherà i cambiamenti in dettaglio.

  • Boopathi ha diligentemente mantenuto babel-minify, quindi procederemo con una versione 1.0 per questo!

  • Ci sono molte nuove funzionalità in lavorazione: ordinamento dei plugin, migliore validazione/gestione degli errori, velocità, ripensamento delle opzioni loose/spec, caching, utilizzo asincrono di Babel, compilazione contro se stesso da CI, smoke test, esecuzione di test262. Dai un'occhiata a questo documento roadmap per altre possibili idee!

Non abbiamo piani segreti: stiamo facendo del nostro meglio con ciò che abbiamo per servire questa comunità.

L'Open Source è uno Specchio​

Mi piacerebbe se avessimo il tempo e le risorse per realizzare tutte queste idee e farlo bene. Ma come abbiamo dimostrato con questa versione, le cose richiedono molto più tempo del previsto!

Perché queste versioni richiedono così tanto tempo? È a causa della crescita incontrollata delle funzionalità, sia da parte nostra che dei nostri utenti? È perché non sappiamo come dare priorità tra tutte le possibili cose da aggiustare o aggiungere? Decidere di correggere i problemi più semplici rispetto a quelli fondamentali fino alla fine? O le "distrazioni" derivanti dall'aiutare gli altri su GitHub, Slack, Twitter? Siamo semplicemente pessimi a stimare il nostro tempo, a comprendere la complessità di questi problemi, a sovraimpegnarci come volontari?

O stiamo semplicemente ponendo aspettative troppo alte su noi stessi, o ci sentiamo così sotto pressione dagli altri per performare e soddisfare le loro esigenze a discapito di noi stessi? Posso solo descriverlo come un senso di terrore quando vedo un messaggio di qualcuno online che si chiede perché qualcosa non sia stato ancora rilasciato mentre un altro chiede perché questo bug non sia stato ancora risolto. Vorrei solo sbrigarmi e finirla, ma ho anche il desiderio di prendere la cosa sul serio.

Ho cercato di esprimere alcuni di questi pensieri e difficoltà nel mio discorso la scorsa settimana a React Rally: Through the (Open Source) Looking Glass, che spero abbiate l'opportunità di ascoltare. La domanda che mi pongo: cosa posso fare riguardo al ciclo inevitabile di burnout dei maintainer, ansia costante e aspettative irrealistiche?

Come in gran parte della vita, le cose che facciamo riflettono il nostro carattere e ci mostrano come siamo veramente. Le azioni che intraprendiamo possono di per sé cambiarci, in meglio o in peggio. Se vogliamo prendere sul serio il nostro lavoro, dovremmo ritenerci reciprocamente responsabili per queste abitudini così radicate nella nostra cultura: la gratificazione istantanea, il successo in termini di metriche, il senso di diritto contro la gratitudine, e l'orgoglio nel lavorare troppo.

Ma nonostante tutto, lavorare a questa versione ne è valso così tanto la pena.

Ringraziamenti​

Questa è davvero una versione entusiasmante, non solo per aver guardato indietro a ciò che abbiamo realizzato e abilitato, ma molto di più per sapere quanto tempo e cuore sono stati messi nel realizzarla nell'ultimo anno. È difficile credere alle opportunità e alle esperienze accadute lungo il percorso: interagire e aiutare aziende da tutto il mondo, trovare amici in quasi ogni città che ho visitato, e parlare onestamente dell'incredibile viaggio che questo gruppo ha intrapreso insieme.

Personalmente, non ho mai investito così tante energie mentali in un progetto di questa portata e vorrei ringraziare le numerose persone che ci hanno sostenuto lungo il percorso. Un ringraziamento speciale in particolare a Logan Smyth che ha dedicato innumerevoli ore a rivoluzionare il funzionamento del core, trovando sempre il tempo per supportarci su Slack nonostante i suoi impegni freelance, e a Brian Ng che si è assunto responsabilità fondamentali nel mantenere Babel oltre a revisionare tutti i miei post e talk. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo e Justin Ridgewell sono stati tutti determinanti nel rendere possibile questa release e piacevole il lavoro svolto.

Un ringraziamento a tutti i membri della community su Slack, Twitter e nei vari progetti GitHub che devono comprendere il nostro lavoro per i loro utenti. Desidero esprimere enorme gratitudine ai miei amici di Behance/Adobe che mi hanno sponsorizzato per quasi un anno consentendomi di lavorare a Babel part-time prima della decisione di dedicarmi full-time (oltre ad aver testato Babel 7 in produzione durante tutto il mio periodo con loro). Grazie infinite a tutti i nostri sponsor di Open Collective, in particolare Trivago e Handshake. E grazie ad amici e familiari per il loro amore e sostegno.

Siamo tutti piuttosto stanchi a questo punto, ma è stato davvero un onore e un privilegio contribuire in questo modo, speriamo apprezziate la release!