Babel 7 Rilasciato

BY admin
|

Dopo quasi 2 anni, 4k commits, oltre 50 pre-releases, e un sacco di aiuto siamo felici di annunciare il rilascio di Babel 7. Sono passati quasi 3 anni dal rilascio di Babel 6! Ci sono molte parti in movimento, quindi per favore abbiate pazienza con noi nelle prime settimane di rilascio. Babel 7 è una release enorme: l’abbiamo resa più veloce, abbiamo creato uno strumento di aggiornamento, configs JS, “overrides” di configurazione, più opzioni per la size/minification, JSX Fragments, TypeScript, nuove proposte, e altro ancora!

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. Apprezzeremmo la proprietà collettiva di questo progetto vitale nella comunità JavaScript!

Sta accadendo! 🎉

Il software non sarà mai perfetto, ma siamo pronti a spedire qualcosa che è già stato usato in produzione da tempo! @babel/core è già a 5,1 milioni di download/mese a causa del suo utilizzo in strumenti come Next.js 6, vue-cli 3.0, React Native 0.56, e anche il frontend di WordPress.com 🙂!

Il ruolo di Babel

Vorrei iniziare questo post introducendo nuovamente il ruolo di Babel nell’ecosistema JavaScript negli ultimi anni.

Il problema iniziale era che, a differenza dei linguaggi server, non c’era modo di garantire che ogni utente avesse lo stesso supporto per JavaScript perché gli utenti potevano usare diversi browser con diversi livelli di supporto (specialmente le vecchie versioni di Internet Explorer). Se gli sviluppatori volevano usare una nuova sintassi (ad esempio class A {}), gli utenti sui vecchi browser avrebbero semplicemente ottenuto una schermata vuota a causa del SyntaxError.

Babel ha fornito un modo per gli sviluppatori di usare l’ultima sintassi JavaScript permettendo loro di non preoccuparsi di come renderla compatibile all’indietro per i loro utenti traducendola (class A {} in var A = function A() {}).

A causa della sua capacità di trasformare il codice JavaScript, può anche essere usato per implementare nuove funzionalità: così è diventato un ponte per aiutare il TC39 (il comitato che specifica il linguaggio JavaScript) a ottenere feedback sulle idee proposte per JavaScript e per la comunità di avere voce in capitolo nel futuro del linguaggio.

Babel è fondamentale per lo sviluppo di JavaScript oggi. Ci sono attualmente oltre 1,3 milioni di repo dipendenti su GitHub, 17 milioni di download su npm al mese, e centinaia di utenti tra cui molti framework importanti (React, Vue, Ember, Polymer), e aziende (Facebook, Netflix, Airbnb). È diventato un tale fondamento per lo sviluppo JavaScript che molte persone non sanno nemmeno che viene usato. Anche se non lo stai usando tu stesso, è molto probabile che le tue dipendenze stiano usando 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 anche con tutta questa responsabilità, Babel è solo un progetto guidato dalla comunità di un paio di volontari.

Solo l’anno scorso alcuni membri del team hanno potuto incontrarsi per la prima volta di persona:

Il team originale @babeljs, finalmente insieme. Da sinistra a destra: @left_pad, @jamiebuilds, @sebmck, il sottoscritto e @loganfsmyth pic.twitter.com/XfPj6OhZfA

– Amjad Masad (@amasad) May 3, 2018

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

Io stesso mi sono iscritto qualche mese prima del rilascio della 6.0, che ha avuto la sua quantità di polemiche e contraccolpi. Gran parte dell’accoglienza ha portato all’esaurimento dei manutentori esistenti (incluso Sebastian, il creatore di Babel) e alcuni di noi che erano rimasti hanno preso le redini. Molti di noi non avevano alcuna formazione formale sul funzionamento dei compilatori o su come mantenere un progetto open source. Ironicamente, ho persino evitato di proposito di specializzarmi in Informatica all’università perché non volevo prendere lezioni sui compilatori o qualsiasi cosa di basso livello perché mi sembrava poco interessante e difficile. Eppure mi sono trovato attratto dagli strumenti, dai linters, da Babel e da JavaScript come linguaggio.

Vorrei incoraggiare tutti a guardare nei progetti open source da cui dipendete e a supportarli (sia con tempo che con supporto monetario, se possibile).

Molti manutentori non sono intrinsecamente esperti nelle cose su cui lavorano; e c’è molto da realizzare iniziando semplicemente il lavoro. Arriverai con curiosità e umiltà, entrambi grandi attributi da avere come manutentore. Il mio desiderio è una speranza per la visione del progetto rispetto a tutti noi che facciamo solo “compiti”.

Babel non è una società, o un team open source di una grande azienda come Facebook. C’è solo una manciata di volontari che lavorano su Babel, e sono passati solo pochi mesi da quando ho fatto il salto per lasciare il mio lavoro ed essere l’unico finora a lavorare sull’open source a tempo pieno. Ma le persone possono andare e venire, avere vite al di fuori di questo “hobby”, crescere famiglie, passare a cose diverse, cambiare lavoro o cercare lavoro, ecc. Stiamo facendo collettivamente quello che possiamo per sostenere le cose che sono così fondamentali per il nostro modo di lavorare, o permetteremo alle fondamenta di sgretolarsi lentamente? Come possiamo mantenere l’open source accogliente e inclusivo ma con confini chiari? Possiamo imparare dalle esperienze di altri manutentori?

Anche se l’Open Source ha chiaramente preso il sopravvento sul software, possiamo davvero considerarlo in uno stato sano senza tener conto delle persone che ci sono dietro?

#BabelSponsorsEverything

Tips 4 @babeljs al @ReactRally #BabelSponsorsEverything pic.twitter.com/WCxefMOC8V

– Harry Wolff (@hswolff) August 17, 2018

La sostenibilità dell’Open Source sembra come distribuire un cesto delle offerte al momento. Non è difficile affermare il valore che i progetti forniscono alle migliaia di persone e aziende che utilizzano l’open source, ma tuttavia non vediamo che quel valore viene mostrato ai pochi che sono disposti a metterci il lavoro. Ci possono essere così tanti modi per sostenere l’open source e tuttavia non tutti gli approcci funzionano per ogni progetto o persone.

Ora passiamo ai cambiamenti!!!

Major Breaking Changes

Siamo documentando questi nella nostra Guida alla migrazione. Molti di questi cambiamenti possono essere fatti automaticamente con il nostro nuovo babel-upgrade strumento, o possono essere aggiunti in futuro.

  • Rimuovere il supporto per le versioni di Node non mantenute: 0.10, 0.12, 4, 5 (dettagli)
  • Spostare noi nello spazio dei nomi @babel passando ad usare pacchetti “scoped” (dettagli). Questo aiuta a differenziare i pacchetti ufficiali, quindi babel-core diventa @babel/core (e niente squat)
  • Rimuovi (e smetti di pubblicare) qualsiasi preset annuale (preset-es2015, ecc.) (dettagli). @babel/preset-env sostituisce la necessità di questi, poiché include tutte le aggiunte annuali e la possibilità di mirare a un insieme specifico di browser
  • Anche i preset “Stage” (@babel/preset-stage-0, ecc.) vanno eliminati in favore dell’opting in proposte individuali. Allo stesso modo rimuovere le proposte da @babel/polyfill di default (dettagli). Si prega di considerare di leggere l’intero post su questo per maggiori spiegazioni.
  • Alcuni pacchetti hanno rinominato: qualsiasi plugin di proposta TC39 sarà ora -proposal invece di -transform (dettagli). Quindi @babel/plugin-transform-class-properties diventa @babel/plugin-proposal-class-properties.
  • Introdurre un peerDependency su @babel/core per certi pacchetti rivolti all’utente (ad esempio babel-loader, @babel/cli, ecc.) (dettagli)

babel-upgrade

babel-upgrade è un nuovo strumento che abbiamo avviato che cerca di fare automaticamente i cambiamenti di aggiornamento: attualmente con dipendenze in package.json e .babelrc config.

Si consiglia di eseguirlo direttamente su un repo git con npx babel-upgrade, oppure è possibile installarlo globalmente con npm i babel-upgrade -g.

Se si desidera modificare i file, è possibile passare --write così come --install.

npx babel-upgrade --write --install

Si prega di considerare di contribuire segnalando problemi o PR per aiutare tutti a passare a Babel 7! Una speranza per il futuro è che usiamo questo stesso strumento per tutte le future modifiche e creiamo un bot per i progetti PR da aggiornare.

File di configurazione JavaScript

Introduciamo babel.config.js. Non è un requisito e nemmeno una sostituzione per .babelrc, ma avere questo può essere utile in certi casi.

*.js I file di configurazione sono abbastanza comuni nell’ecosistema JavaScript. ESLint e Webpack permettono entrambi i file di configurazione .eslintrc.js e webpack.config.js, rispettivamente.

Di seguito c’è il caso di compilare solo con un plugin in “produzione” (è possibile farlo già con l’opzione "env" in un file .babelrc):

var env = process.env.NODE_ENV;module.exports = { plugins: .filter(Boolean)};

babel.config.js ha una risoluzione di configurazione diversa da una .babelrc. Risolverà sempre la configurazione da quel file rispetto a quando Babel faceva una ricerca da ogni file verso l’alto finché non trovava una configurazione. Questo rende possibile approfittare della prossima caratteristica postata sotto, overrides.

Configurazione selettiva con override

Di recente, ho pubblicato un post con riflessioni sia sulla pubblicazione dei pacchetti ES2015+ che sul loro consumo/compilazione.

C’è una sezione che tratta dell’uso di una nuova chiave nella configurazione di Babel chiamata overrides che permette di specificare diverse config per glob.

module.exports = { presets: , overrides: , presets: , }, { test: , presets: , }]};

Questo permette ad un’applicazione che richiede diverse configurazioni di compilazione per i suoi test, il codice client e il codice server di saltare la necessità di creare un nuovo file .babelrc per ogni cartella.

Velocità 🏎

Babel stesso è più veloce quindi dovrebbe richiedere meno tempo per costruire! Abbiamo fatto molte modifiche per ottimizzare il codice e per accettare le patch del team v8. Siamo felici di far parte del Web Tooling Benchmark insieme a molti altri grandi strumenti JavaScript.

Opzioni di output

Babel supporta da tempo le opzioni di preset e plugin. Per ricapitolare puoi avvolgere il plugin in un array e passare un oggetto opzioni al plugin:

{ "plugins": , ]}

Abbiamo fatto alcune modifiche all’opzione loose di alcuni plugin e aggiunto alcune nuove opzioni per altri! Notate che usando queste opzioni state optando per un comportamento non conforme alle specifiche e dovreste sapere cosa state facendo; questo può diventare un problema quando non compilate per usare la sintassi in modo nativo. Questo tipo di opzioni sono meglio usate in una libreria, se mai.

  • Per le classi, class A {} ora non includerà l’helper classCallCheck.
class A {}
var A = function A() {- _classCallCheck(this, A);};
  • C’è una nuova opzione se ogni uso di un ciclo for-of è solo un array: 
let elm;for (elm of array) { console.log(elm);}
let elm;for (let _i = 0, _array = array; _i < _array.length; _i++) { elm = _array; console.log(elm);}
  • Escludiamo il plugin transform-typeof-symbol in modalità loose per preset-env #6831

Abbiamo trovato molte librerie che lo fanno già, quindi abbiamo deciso di farlo di default.

Nota che il comportamento predefinito è quello di essere il più possibile conforme alle specifiche in modo che lo spegnimento di Babel o l’uso di preset-env sia senza soluzione di continuità rispetto al permettere un output più piccolo solo per risparmiare byte (c’è un compromesso che ogni progetto può fare). Abbiamo in programma di lavorare su documenti e strumenti migliori per rendere tutto ciò più facile.

Supporto alle annotazioni “pure”

Dopo il #6209, le classi ES6 trapiantate sono annotate con un commento /*#__PURE__*/ che permette di dare un suggerimento ai minificatori come Uglify e babel-minify per l’eliminazione del codice morto. Queste annotazioni sono aggiunte anche ad altre funzioni helper.

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

Ci potrebbero essere altre opportunità per i suggerimenti e le ottimizzazioni dei minificatori, fatecelo sapere!

Sintassi

Supporto proposte TC39

Vorrei ribadire che abbiamo rimosso le preimpostazioni Stage in favore di una politica di chiedere agli utenti di optare esplicitamente per le proposte < Stage 4.

La preoccupazione è che stiamo automaticamente optando le persone in una sintassi che non è fissa o fatta con l’aspettativa che non cambierà. Ma questo non è il caso, specialmente per le proposte che sono Stage 0 o 1. Questo post spiega un po’ il tipo di pensiero che sta dietro alle idee più recenti.

Ecco un piccolo elenco di alcune delle nuove sintassi supportate da Babel (tenete a mente che questa serie di caratteristiche è un obiettivo in movimento che potrebbe essere aggiunto/rimosso/stop) e quali sono state aggiunte nella v7:

  • ES2018: Object Rest Spread (var a = { b, ...c })
  • ES2018 (nuovo): Regex proprietà Unicode
  • ES2018 (nuovo): Superset JSON
  • ES2015 (nuovo): new.target
  • Fase 3 (nuova): Campi istanza privati di classe (class A { #b = 2 })
  • Fase 3 (WIP): Campi statici di classe, metodi statici privati (class A { static #a() {} })
  • Fase 3 (nuova): Catch Binding opzionale try { throw 0 } catch { do() }
  • Fase 3 (nuova): BigInt (solo sintassi)
  • Fase 3: Importazione dinamica (import("a"))
  • Fase 2 (nuova): import.meta (solo sintassi) (import.meta.url)
  • Fase 2 (nuova): Separatori numerici (1_000)
  • Fase 2 (nuova): function.sent
  • Stadio 2: export-namespace-from (export * as ns from 'mod'), diviso da export-extensions
  • Stadio 2: Decoratori. Controlla qui sotto per un aggiornamento sui nostri progressi!
  • Fase 1: export-default-from (export v from 'mod'), diviso da export-extensions
  • Stadio 1 (nuovo): Incatenamento opzionale (a?.b)
  • Stadio 1 (nuovo): Operatori di assegnazione logica (a &&= b; a ||= b)
  • Fase 1 (nuova): Operatore di coalescenza nullo (a ?? b)
  • Fase 1 (nuova): Pipeline Operator (a |> b)
  • Fase 1 (nuova): Throw Expressions (() => throw new Error("a"))

È difficile per chiunque tenere traccia di tutte le proposte, così cerchiamo di farlo in babel/proposals.

Supporto TypeScript (@babel/preset-typescript)

Abbiamo lavorato con il team TypeScript per far sì che Babel analizzi/trasformi la sintassi dei tipi con @babel/preset-typescript, in modo simile a come gestiamo Flow con @babel/preset-flow.

Per maggiori dettagli guardate questo post 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 utenti JavaScript di trarre vantaggio dalla tipizzazione graduale, e ci piacerebbe abilitarli entrambi in Babel. Abbiamo intenzione di continuare a lavorare a stretto contatto con entrambi i rispettivi team di FB e Microsoft (oltre che con la comunità in generale) per mantenere la compatibilità e supportare nuove funzionalità.

Questa integrazione è abbastanza nuova, quindi è possibile che alcune sintassi non siano pienamente supportate. Apprezzeremmo il vostro aiuto nel segnalare i problemi e magari nell’inviare un PR!

Supporto JSX Fragment (<>)

Come menzionato nel React Blog, il supporto JSX Fragment è disponibile da beta.31.

render() { return ( <> <ChildA /> <ChildB /> </> );}// output 👇render() { return React.createElement( React.Fragment, null, React.createElement(ChildA, null), React.createElement(ChildB, null) );}

Modifiche agli helper Babel

La PR di babel-upgrade è in corso

@babel/runtime è stata divisa in @babel/runtime e @babel/runtime-corejs2 (PR). La prima contiene solo le funzioni helper di Babel e la seconda contiene questo e tutte le funzioni polyfill (ad esempio Symbol, Promise).

Babel potrebbe aver bisogno di iniettare alcune funzioni nel codice che possono essere riutilizzate. Chiamiamo queste “funzioni di aiuto” proprio come le funzioni condivise tra i moduli.

Un esempio di questo è la compilazione di un class (senza la modalità loose attiva):

La specifica dice che è necessario chiamare una classe con new Person() ma se è compilata in una funzione si potrebbe tecnicamente fare solo Person() quindi includiamo un controllo runtime per questo.

class Person {}
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 le funzioni modulari per consentire un output più piccolo, così:

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 cercando di vedere se possiamo farlo automaticamente in futuro. Presto ci sarà un post autonomo sugli helper di Babel.

Polyfilling automatico (sperimentale)

I polyfill sono necessari per abilitare funzionalità come Promise, Symbol in ambienti che non le supportano. Questo è importante quando si differenzia tra ciò che Babel fa come compilatore (trasforma la sintassi) rispetto a un polyfill (implementa funzioni/oggetti incorporati).

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

import "@babel/polyfill";

Ma include l’intero polyfill, e potrebbe non essere necessario importare tutto se i browser lo supportano già. Questo è lo stesso problema che @babel/preset-env cerca di risolvere con la sintassi, quindi lo applichiamo qui con i polyfill. L’opzione useBuiltins: "entry" lo fa dividendo l’importazione originale in solo le importazioni che sono necessarie.

Ma possiamo fare meglio importando solo i polyfill che sono usati nel codebase. L’opzione "useBuiltIns: "usage" è il nostro primo tentativo di abilitare qualcosa del genere (docs).

Eseguirà ogni file e inietterà un’importazione all’inizio di ogni file se quel built-in è “usato” nel codice. Per esempio:

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

L’inferenza non è perfetta quindi ci possono essere falsi positivi.

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

Altre idee in questo spazio sono di usare polyfill.io se ti va bene affidarti a un servizio (o leggi come Kent C. Dodds lo ha usato per costruire un servizio ospitato da PayPal).

Misc

Babel Macros 🎣

Una delle parti migliori di Babel è la pluggabilità dello strumento. Nel corso degli anni, Babel è passato dall’essere solo un compilatore “6to5” ad una piattaforma di trasformazione del codice, permettendo alcune fantastiche ottimizzazioni sia per l’utente che per lo sviluppatore. Tonnellate di plugin Babel sono state sviluppate per librerie e casi d’uso specifici per migliorare le prestazioni e le capacità delle API delle librerie che non sarebbero possibili altrimenti (alcune “librerie” sono completamente transpilate e non hanno quindi alcun runtime).

Purtroppo, l’aggiunta di questi plugin al codice richiede la modifica della configurazione (che alcuni toolkit come create-react-app non permettono) e aggiunge complessità al codice perché gli sviluppatori devono sapere quali plugin Babel stanno operando su un file per sapere cosa succederà al codice che stanno scrivendo. Questi problemi sono stati risolti da babel-plugin-macros di Kent C. Dodds!

Una volta che babel-plugin-macros è stato installato e aggiunto alla tua configurazione (è incluso in create-react-app v2), non hai bisogno di preoccuparti della tua configurazione per usare qualsiasi macro. Inoltre, è ancora più facile scrivere le tue trasformazioni personalizzate per casi d’uso specifici della tua applicazione o di una parte del tuo codice.

Scopri di più su babel-plugin-macros nel nostro post originale “Zero-config code transformation with babel-plugin-macros”.

Module Targeting

Babel ha sempre cercato di bilanciare l’impatto delle dimensioni delle trasformazioni e le capacità che forniscono agli autori JavaScript. In Babel 7, è diventato molto più facile configurare Babel per supportare la crescente popolarità del pattern modulo/nomodulo.

In particolare, diversi strumenti CLI per framework web popolari (1, 2) stanno già sfruttando il supporto che porta ad una riduzione di circa il 20% del JavaScript spedito ai consumatori di applicazioni trapiantate da Babel.

Metadati del chiamante e migliori default

Abbiamo aggiunto un’opzione caller a @babel/core in modo che i nostri strumenti possano passare metadati a preset/plugin. Per esempio: babel-loader può aggiungere qualcosa del genere in modo che preset-env possa disabilitare automaticamente la trasformazione del modulo (lo stesso con rollup:

babel.transform("code;", { filename, presets: , caller: { name: "babel-loader", supportsStaticESM: true, },});

Questo è eccitante poiché permette al tooling di fornire migliori default e meno configurazione! Per il caso di webpack/rollup: possiamo automaticamente rinviare l’uso della loro trasformazione di modulo invece di quella di Babel (lo stesso con import("a")). In futuro, si dovranno usare più strumenti per trarre vantaggio da questo!

classe C estende HTMLElement {}

Uno dei nostri problemi più vecchi ha un titolo tutto suo (dettagli)

Babel ha sempre avuto l’avvertenza di non poter supportare l’estensione dei built-in nativi (Array, Error, ecc.) e ora può! Abbiamo ricevuto molti problemi su questo; 🎉 dovreste festeggiare come Andrea!

Questa modifica è stata fatta al plugin di classe quindi dovrebbe essere automaticamente abilitato se state usando preset-env.

Modifiche al sito 🌏

Abbiamo spostato il nostro sito da Jekyll a Docusaurus!

Siamo ancora nel processo di impostazione delle traduzioni con Crowdin, e con Babel 7 fuori, saremo in un posto migliore per iniziare quel processo.

REPL

Abbiamo riscritto il REPL come un componente React, e abbiamo lavorato con Ives per integrarlo meglio con CodeSandbox. Questo vi permette di installare qualsiasi plugin o preset da npm nel REPL e di ottenere qualsiasi aggiornamento di CodeSandbox.

Partecipiamo nuovamente al Rails Girls Summer of Code! Questa volta, Gyujin e Sujin hanno lavorato duramente per integrare babel-time-travel di Boopathi nel REPL, che potete già testare ora!

Ci sono così tante opportunità di essere coinvolti per far funzionare meglio Babel, gli AST e altri strumenti!

Abbiamo una canzone 🎶

Hallelujah-In Praise of Babel

Un giorno, Angus ci ha gentilmente impartito una canzone che ho trovato fantastica, quindi perché non renderla la nostra canzone “ufficiale”? E Shawn ha fatto una brillante cover qui.

Puoi trovarla nel nostro repo a SONG.md. Speriamo di vedere altri progetti seguire questo!

Cosa c’è dopo?

  • Babel è intrinsecamente legato a ciò che compila: JavaScript. Finché ci sono nuove aggiunte da proporre/lavorare c’è del lavoro da fare. Questo include il tempo e lo sforzo per implementare e mantenere la sintassi anche prima che diventi “stabile”. Ci preoccupiamo dell’intero processo: il percorso di aggiornamento, l’educazione alle nuove funzionalità, l’insegnamento degli standard/del design del linguaggio, la facilità d’uso e l’integrazione con altri progetti.
    • Relativamente: abbiamo quasi finito di implementare la nuova proposta dei decoratori in Babel grazie a Nicolò. È stato un lungo viaggio (c’è voluto più di un anno!) perché la nuova proposta è completamente diversa e molto più potente di quella vecchia, ma ci siamo quasi 🎉. Potete aspettarvi che venga rilasciata in una delle prossime versioni minori, insieme a un post sul blog che spiegherà i cambiamenti in dettaglio.
  • Boopathi ha mantenuto diligentemente babel-minify, quindi faremo una 1.0 per quello dopo!
  • Ci sono un sacco di nuove caratteristiche in lavorazione: ordinamento dei plugin, migliore convalida/errori, velocità, ripensamento delle opzioni loose/spec, caching, utilizzo di Babel in modo asincrono, costruzione contro se stessa da CI, smoke test, esecuzione di test262. Date un’occhiata a questo documento sulla roadmap per altre possibili idee!

Non abbiamo piani segreti: stiamo cercando di fare del nostro meglio con quello che abbiamo per servire questa comunità.

Open Source è uno specchio

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

Perché queste release richiedono così tanto tempo comunque? È a causa del feature creep, sia da parte nostra che dei nostri utenti? È perché non capiamo come dare la priorità tra tutte le possibili cose da aggiungere o sistemare? Decidere di sistemare i frutti a portata di mano contro i problemi fondamentali fino alla fine? O “distrazioni” dall’aiutare gli altri su GitHub, Slack, Twitter? Siamo solo pessimi nel valutare il nostro tempo, nel capire la complessità di questi problemi, nell’impegnarci troppo come volontari?

O forse stiamo solo ponendo aspettative troppo alte su noi stessi, o ci sentiamo così pressati dagli altri per eseguire e adattarci alle loro esigenze a scapito di noi stessi? Posso solo descrivere il terrore quando vedo un messaggio di qualcuno online che si chiede perché qualcosa non è stato rilasciato, mentre un altro chiede perché questo bug non è ancora stato risolto. Voglio solo fare in fretta e farla finita, ma ho anche il desiderio di prendere la cosa sul serio.

Ho cercato di esprimere alcuni di questi pensieri e lotte nel mio discorso della scorsa settimana al React Rally: Through the (Open Source) Looking Glass, che spero possiate cogliere l’occasione di ascoltare. La domanda che mi pongo è: Cosa posso fare per l’inevitabile ciclo di burnout dei manutentori, ansia costante e aspettative irrealistiche?

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

Ma nonostante tutto questo, lavorare per questo rilascio ne è valsa la pena.

Grazie

Questa è davvero una release molto eccitante, non solo guardando indietro a ciò che abbiamo realizzato e abilitato, ma molto di più sapendo quanto tempo e cuore è stato messo nel realizzarla nell’ultimo anno. È difficile credere alle opportunità e alle esperienze che sono accadute lungo la strada: interagire con e aiutare aziende da tutto il mondo, trovare amici in quasi tutte le città che ho visitato, e parlare onestamente dell’incredibile viaggio che questo gruppo ha intrapreso insieme.

Personalmente, non ho mai messo così tanta energia mentale in qualcosa di questa portata e vorrei ringraziare così tante persone per averci sollevato lungo la strada. Un ringraziamento particolare a Logan Smyth che ha speso un tempo incalcolabile per cambiare gran parte del funzionamento del nucleo e che trova sempre il tempo per essere così utile nel nostro Slack mentre lavora anche come freelance e Brian Ng che si è fatto avanti in modo così grande per continuare a mantenere Babel così come per rivedere tutti i miei post e discorsi. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo e Justin Ridgewell sono stati tutti determinanti nel rendere questo rilascio possibile e piacevole da lavorare.

Shoutout a tutti i molti membri della comunità su Slack, Twitter e in tutti i progetti su GitHub che devono anche capire cosa stiamo facendo per i loro utenti. Vorrei ringraziare enormemente i miei amici di Behance/Adobe per avermi sponsorizzato per quasi un anno per lavorare su Babel a metà tempo prima di decidere di andare a tempo pieno (oltre ad avermi aiutato a testare Babel 7 in produzione per tutto il tempo in cui ero lì). Un grande ringraziamento a tutti i nostri sponsor per il nostro Open Collective, specialmente Trivago e Handshake. E grazie ai nostri amici e alla famiglia per tutto il loro amore e sostegno.

Siamo tutti piuttosto stanchi a questo punto, ma è stato davvero un onore e un privilegio servire in questo modo, quindi speriamo che apprezziate il rilascio!