Babel 7 Vrijgegeven

BY admin
|

Na bijna 2 jaar, 4k commits, meer dan 50 pre-releases, en heel veel hulp zijn we verheugd om de release van Babel 7 aan te kondigen. Het is bijna 3 jaar geleden sinds de release van Babel 6! Er zijn een heleboel bewegende delen, dus heb geduld met ons in de eerste weken van de release. Babel 7 is een grote release: we hebben het sneller gemaakt, een upgrade tool gemaakt, JS configs, config “overrides”, meer opties voor size/minification, JSX Fragments, TypeScript, nieuwe voorstellen, en meer!

Als u het werk dat we aan Babel doen waardeert, kunt u Babel sponsoren op Open Collective, mij steunen op Patreon, of u of uw bedrijf betrekken bij Babel als onderdeel van het werk. We zouden het op prijs stellen als de JavaScript-gemeenschap zich collectief verantwoordelijk voelt voor dit belangrijke project!

Het gaat gebeuren! 🎉

Software zal nooit perfect zijn, maar we zijn klaar om iets te verschepen dat nu al een tijdje in productie wordt gebruikt! @babel/core zit al op 5,1 miljoen downloads/maand vanwege het gebruik in tools als Next.js 6, vue-cli 3.0, React Native 0.56, en zelfs de frontend van WordPress.com 🙂!

De rol van Babel

Ik wil deze post beginnen met het herintroduceren van de rol van Babel in het JavaScript ecosysteem van de afgelopen jaren.

Het oorspronkelijke probleem was dat in tegenstelling tot servertalen, er geen manier was om te garanderen dat elke gebruiker dezelfde ondersteuning heeft voor JavaScript, omdat gebruikers verschillende browsers kunnen gebruiken met verschillende niveaus van ondersteuning (vooral oudere versies van Internet Explorer). Als ontwikkelaars een nieuwe syntaxis wilden gebruiken (bijv. class A {}), zouden gebruikers op oude browsers gewoon een leeg scherm krijgen vanwege de SyntaxError.

Babel bood een manier voor ontwikkelaars om de nieuwste JavaScript syntaxis te gebruiken, terwijl ze zich geen zorgen hoefden te maken over hoe ze het achterwaarts compatibel konden maken voor hun gebruikers door het te vertalen (class A {} naar var A = function A() {}).

Door zijn vermogen om JavaScript-code te transformeren, kan het ook worden gebruikt om nieuwe functies te implementeren: zo is het een brug geworden om TC39 (de commissie die de JavaScript-taal specificeert) te helpen feedback te krijgen op voorgestelde JavaScript-ideeën en voor de gemeenschap om inspraak te hebben in de toekomst van de taal.

Babel is vandaag de dag van fundamenteel belang voor de ontwikkeling van JavaScript. Er zijn momenteel meer dan 1,3 miljoen afhankelijke repo’s op GitHub, 17 miljoen downloads op npm per maand, en honderden gebruikers, waaronder veel grote frameworks (React, Vue, Ember, Polymer), en bedrijven (Facebook, Netflix, Airbnb). Het is zo’n fundament geworden voor JavaScript ontwikkeling dat veel mensen niet eens weten dat het gebruikt wordt. Zelfs als je het zelf niet gebruikt, is het zeer waarschijnlijk dat je afhankelijkheden Babel gebruiken.

Onderhouders zijn mensen

Babel heeft een enorme invloed op niet alleen de toekomst van de taal zelf, maar ook op de gemeenschap en het ecosysteem ervan. Maar zelfs met al deze verantwoordelijkheid, is Babel slechts een gemeenschap gedreven project door een paar vrijwilligers.

Het was pas dit afgelopen jaar dat een aantal van het team elkaar voor het eerst persoonlijk konden ontmoeten:

Het originele @babeljs team, eindelijk samen. Van links naar rechts: @left_pad, @jamiebuilds, @sebmck, ondergetekende, en @loganfsmyth pic.twitter.com/XfPj6OhZfA

– Amjad Masad (@amasad) May 3, 2018

Zoveel als dit een aankondigingspost is, wil ik van de gelegenheid gebruikmaken om iedereen te herinneren aan de staat van dit project.

Ikzelf ben een paar maanden voor de 6.0-release toegetreden, die zijn eigen hoeveelheid controverse en backlash had. Veel van de ontvangst daar leidde tot een burn-out bij de bestaande maintainers (inclusief Sebastian, de maker van Babel) en een paar van ons die overbleven namen de teugels in handen.

Zoals veel maintainers, zijn we per ongeluk in de rol gestruikeld. Velen van ons hadden geen formele opleiding gehad over hoe compilers werkten of hoe je een open source project moest onderhouden. Ironisch genoeg vermeed ik zelfs opzettelijk om een hoofdvak te kiezen in Computerwetenschappen op de universiteit omdat ik geen lessen wilde volgen over compilers of iets van laag niveau omdat het me oninteressant en moeilijk leek. Toch voelde ik me aangetrokken tot tooling, linters, Babel, en JavaScript als taal.

Ik wil iedereen aanmoedigen om te kijken naar de open source projecten waar je van afhankelijk bent en om ze te ondersteunen (zowel met tijd als geld indien mogelijk).

Veel beheerders zijn niet per definitie experts in de dingen waar ze aan werken; en er is veel te bereiken door gewoon eerst te beginnen met het werk. Je komt binnen met zowel nieuwsgierigheid als nederigheid, wat beide geweldige eigenschappen zijn om te hebben als onderhouder. Mijn wens is hoop voor de visie van het project in plaats van dat we allemaal “taken” doen.

Babel is geen bedrijf, of een open source team bij een groot bedrijf als Facebook. Er werken slechts een handvol vrijwilligers aan Babel, en het is nog maar een paar maanden geleden dat ik de sprong waagde om mijn baan op te zeggen en tot nu toe de enige was die fulltime aan open source werkte. Maar mensen kunnen komen en gaan, hebben levens buiten deze “hobby”, voeden gezinnen op, gaan verder met andere dingen, veranderen van baan of zijn op zoek naar een baan, enz. Doen we collectief wat we kunnen om de dingen die zo fundamenteel zijn voor onze manier van werken in stand te houden, of laten we de fundamenten langzaam afbrokkelen? Hoe houden we open source gastvrij en inclusief, maar met duidelijke grenzen? Kunnen we leren van de ervaringen van andere beheerders?

Hoewel Open Source software duidelijk heeft overgenomen, kunnen we het echt als gezond beschouwen zonder rekening te houden met de mensen erachter?

#BabelSponsorsEverything

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

– Harry Wolff (@hswolff) August 17, 2018

Open Source duurzaamheid voelt op dit moment aan als het uitdelen van een offermandje. Het is niet moeilijk om de waarde te benoemen die projecten bieden aan de duizenden mensen en bedrijven die open source gebruiken, maar toch zien we niet dat die waarde wordt getoond aan de weinigen die bereid zijn om het werk erin te steken. Er kunnen zoveel manieren zijn om open source te ondersteunen en toch werken niet alle benaderingen voor elk project of elke persoon.

Nu over naar de veranderingen!!

Grote Brekende Veranderingen

We zijn deze aan het documenteren in onze Migratiegids. Veel van deze wijzigingen kunnen automatisch worden uitgevoerd met onze nieuwe babel-upgrade tool, of kunnen in de toekomst worden toegevoegd.

  • Ondersteuning voor niet-onderhouden Node-versies laten vallen: 0.10, 0.12, 4, 5 (details)
  • Verplaats ons naar de @babel-namespace door over te stappen op het gebruik van “scoped” packages (details). Dit helpt officiële pakketten te onderscheiden, dus babel-core wordt @babel/core (en geen kraken)
  • Verwijder (en stop met publiceren) alle jaarlijkse presets (preset-es2015, etc) (details). @babel/preset-env vervangt de noodzaak voor deze, omdat het alle jaarlijkse toevoegingen bevat, evenals de mogelijkheid om zich te richten op een specifieke set browsers
  • Laat ook de “Stage” presets (@babel/preset-stage-0, etc) vallen ten gunste van het kiezen voor individuele voorstellen. Verwijder ook standaard voorstellen uit @babel/polyfill (details). Lees de hele post hierover voor meer uitleg.
  • Enkele pakketten hebben een nieuwe naam gekregen: elke TC39 voorstel plugin zal nu -proposal zijn in plaats van -transform (details). Dus @babel/plugin-transform-class-properties wordt @babel/plugin-proposal-class-properties.
  • Invoeren van een peerDependency op @babel/core voor bepaalde user-facing packages (b.v. babel-loader, @babel/cli, etc) (details)

babel-upgrade

babel-upgrade is een nieuwe tool die we zijn begonnen die probeert automatisch upgrade veranderingen te maken: momenteel met afhankelijkheden in package.json en .babelrc config.

We raden aan om het direct op een git repo te draaien met npx babel-upgrade, of je kunt het globaal installeren met npm i babel-upgrade -g.

Als je de bestanden wilt wijzigen, kun je --write en --install doorgeven.

npx babel-upgrade --write --install

Overweeg alsjeblieft om bij te dragen door issues of PR’s te melden om iedereen te helpen bij de overgang naar Babel 7! Een hoop voor de toekomst is dat we deze zelfde tool gebruiken voor alle toekomstige breaking changes en een bot creëren om PR projecten te updaten.

JavaScript Config Files

We introduceren babel.config.js. Het is geen vereiste of zelfs een vervanging voor .babelrc, maar het hebben van dit kan nuttig zijn in bepaalde gevallen.

*.js configuratiebestanden zijn vrij gebruikelijk in het JavaScript-ecosysteem. ESLint en Webpack staan beide respectievelijk .eslintrc.js en webpack.config.js configuratiebestanden toe.

Hieronder is het geval van alleen compileren met een plugin in “productie” (je kunt dit al doen met de "env" optie in een .babelrc bestand):

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

babel.config.js heeft een andere config resolutie dan een .babelrc. Het zal altijd de config van dat bestand oplossen, in tegenstelling tot de oorspronkelijke situatie waarbij Babel een opzoeking zou doen van elk bestand naar boven tot het een config vond. Dit maakt het mogelijk om voordeel te halen uit de volgende functie die hieronder wordt gepost, overrides.

Selectieve configuratie met overrides

Recentelijk publiceerde ik een post met gedachten over zowel het publiceren van ES2015+ packages als het consumeren/compileren ervan.

Er is een sectie die ingaat op het gebruik van een nieuwe sleutel in Babel’s config genaamd overrides die je toelaat om verschillende configs per glob te specificeren.

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

Dit maakt het mogelijk voor een applicatie die verschillende compilatie configs nodig heeft voor zijn tests, client code, en server code om het maken van een nieuw .babelrc bestand per map over te slaan.

Snelheid 🏎

Babel zelf is sneller dus het zou minder tijd moeten kosten om te bouwen! We hebben veel veranderingen aangebracht om de code te optimaliseren en patches van het v8 team te accepteren. We zijn blij om deel uit te maken van de Web Tooling Benchmark naast vele andere geweldige JavaScript tools.

Output Options

Babel ondersteunt al enige tijd preset en plugin opties. Je kunt de plugin in een array wikkelen en een object met opties aan de plugin doorgeven:

{ "plugins": , ]}

We hebben enkele wijzigingen aangebracht in de loose optie van sommige plugins en enkele nieuwe opties voor anderen toegevoegd! Merk op dat door het gebruik van deze opties je kiest voor niet-spec-compliant gedrag en dat je moet weten wat je doet; dit kan een probleem worden wanneer je het compileren uitschakelt om de syntax van nature te gebruiken. Dit soort opties kunnen het beste in een bibliotheek worden gebruikt, als ze al worden gebruikt.

  • Voor klassen zal class A {} nu niet de classCallCheck helper bevatten.
class A {}
var A = function A() {- _classCallCheck(this, A);};
  • Er is een nieuwe optie als elk gebruik van een for-of lus gewoon een array is: 
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);}
  • We sluiten de transform-typeof-symbol plugin uit in loose modus voor preset-env #6831

We hebben veel bibliotheken gevonden die dit al doen, dus we hebben besloten om dit standaard te doen.

Merk op dat het standaardgedrag is om zo spec-compliant mogelijk te zijn, zodat het uitschakelen van Babel of het gebruik van preset-env naadloos verloopt, in tegenstelling tot het toestaan van kleinere uitvoer alleen om bytes te besparen (er is een afweging die elk project kan maken). We zijn van plan om te werken aan betere docs en tooling om dat gemakkelijker te maken.

“Pure” Annotation Support

Na #6209 worden getranspileerde ES6 klassen geannoteerd met een /*#__PURE__*/ commentaar dat een hint geeft aan minifiers zoals Uglify en babel-minify voor het elimineren van dode code. Deze annotaties worden ook aan andere helper-functies toegevoegd.

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

Er zijn misschien meer mogelijkheden voor minifier hints en optimalisaties, laat het ons weten!

Syntax

TC39 Proposals Support

Ik wil graag herhalen dat we de Stage presets hebben verwijderd ten gunste van een beleid om gebruikers te vragen expliciet te kiezen voor voorstellen < Stage 4.

De zorg is dat we mensen automatisch kiezen voor een syntax die niet vastligt of gedaan wordt met de verwachting dat het niet zal veranderen. Maar dat is niet het geval, vooral niet voor voorstellen die in fase 0 of 1 verkeren. Deze post legt een beetje uit over het soort denken achter nieuwere ideeën.

Hier is een kleine opsomming van enkele van de nieuwe syntaxis die Babel ondersteunt (houd in gedachten dat deze functieset een bewegend doel is dat kan worden toegevoegd/verwijderd/geïnstalleerd) en welke zijn toegevoegd in v7:

  • ES2018: Object Rest Spread (var a = { b, ...c })
  • ES2018 (nieuw): Unicode Property Regex
  • ES2018 (nieuw): JSON Superset
  • ES2015 (nieuw): new.target
  • Stage 3 (nieuw): Class Private Instance Fields (class A { #b = 2 })
  • Stage 3 (WIP): Static Class Fields, Private Static Methods (class A { static #a() {} })
  • Stage 3 (nieuw): Optionele Catch Binding try { throw 0 } catch { do() }
  • Stage 3 (nieuw): BigInt (alleen syntaxis)
  • Stap 3: Dynamisch importeren (import("a"))
  • Stap 2 (nieuw): import.meta (alleen syntaxis) (import.meta.url)
  • Stap 2 (nieuw): Numerieke scheidingstekens (1_000)
  • Stap 2 (nieuw): function.sent
  • Stap 2: export-namespace-from (export * as ns from 'mod'), afgesplitst van export-extensions
  • Stap 2: Versierders. Kijk hieronder voor een update van onze vorderingen!
  • Stadium 1: export-default-from (export v from 'mod'), afgesplitst van export-extensions
  • Stadium 1 (nieuw): Optionele Chaining (a?.b)
  • Stap 1 (nieuw): Logische Toewijzingsoperatoren (a &&= b; a ||= b)
  • Fase 1 (nieuw): Nullish Coalescing Operator (a ?? b)
  • Stage 1 (nieuw): Pijplijn Operator (a |> b)
  • Stage 1 (nieuw): Throw Expressions (() => throw new Error("a"))

Het is voor iedereen moeilijk om alle voorstellen bij te houden, dus proberen we dat te doen bij babel/voorstellen.

TypeScript Support (@babel/preset-typescript)

We hebben met het TypeScript-team samengewerkt om Babel de typesyntax te laten parsen/transformeren met @babel/preset-typescript, vergelijkbaar met de manier waarop we Flow afhandelen met @babel/preset-flow.

Voor meer details, zie dit bericht van het TypeScript-team!

Voor (met types):

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

Na (types verwijderd):

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

Zowel Flow als Typescript zijn hulpprogramma’s waarmee JavaScript-gebruikers kunnen profiteren van stapsgewijze typering, en we willen beide graag mogelijk maken in Babel. We zijn van plan nauw samen te blijven werken met de teams van FB en Microsoft (en met de gemeenschap als geheel) om de compatibiliteit te behouden en nieuwe functies te ondersteunen.

Deze integratie is vrij nieuw, dus het is mogelijk dat bepaalde syntaxis niet volledig wordt ondersteund. We stellen uw hulp op prijs bij het melden van problemen en het eventueel sturen van een PR!

JSX Fragment Support (<>)

Zoals vermeld in het React Blog, is JSX Fragment support beschikbaar sinds beta.31.

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

Babel Helpers Changes

De babel-upgrade PR is in uitvoering

@babel/runtime is opgesplitst in @babel/runtime en @babel/runtime-corejs2 (PR). De eerste bevat alleen de helperfuncties van Babel en de tweede bevat die, evenals eventuele polyfill-functies (bijv. Symbol, Promise).

Babel moet mogelijk bepaalde functies in de code injecteren die kunnen worden hergebruikt. We noemen deze gewoon “helper functies”, net als functies die worden gedeeld tussen modules.

Een voorbeeld hiervan is met het compileren van een class (zonder loose modus aan):

De specificatie zegt dat je een class moet aanroepen met new Person(), maar als het is gecompileerd naar een functie, zou je technisch gezien gewoon Person() kunnen doen, dus we voegen een runtime-controle voor dit toe.

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

Met @babel/plugin-transform-runtime en @babel/runtime (als een afhankelijkheid), kan Babel de individuele functies extraheren en alleen de modulaire functies vereisen om kleinere uitvoer mogelijk te maken, als volgt:

var _classCallCheck = require("@babel/runtime/helpers/classCallCheck");var Person = function Person() { _classCallCheck(this, Person);};

Hetzelfde kan worden gedaan met external-helpers en rollup-plugin-babel. We zijn aan het kijken of we dit in de toekomst automatisch kunnen doen. Kijk uit naar een standalone post over Babel’s helpers binnenkort.

Automatische Polyfilling (experimenteel)

Polyfills zijn nodig om functies als Promise, Symbol mogelijk te maken in omgevingen die er geen ondersteuning voor hebben. Dit is belangrijk wanneer onderscheid wordt gemaakt tussen wat Babel doet als een compiler (transformeert syntaxis) versus een polyfill (implementeert ingebouwde functies/objecten).

Het is gemakkelijk genoeg om gewoon iets te importeren dat alles dekt zoals @babel/polyfill:

import "@babel/polyfill";

Maar het omvat de hele polyfill, en je hoeft misschien niet alles te importeren als browsers het al ondersteunen. Dit is hetzelfde probleem dat @babel/preset-env probeert op te lossen met syntax, dus passen we het hier toe met polyfills. De optie useBuiltins: "entry" doet dit door de originele import op te splitsen in alleen de importen die nodig zijn.

Maar we kunnen het beter doen door alleen de polyfills te importeren die in de codebase worden gebruikt. De optie "useBuiltIns: "usage" is onze eerste poging om zoiets mogelijk te maken (docs).

Het zal door elk bestand lopen en een import injecteren bovenaan elk bestand als die ingebouwde “gebruikt” wordt in de code. Bijvoorbeeld:

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

De inferentie is niet perfect, dus er kunnen valse positieven zijn.

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

Andere ideeën in deze ruimte zijn om polyfill.io te gebruiken als je het goed vindt om op een service te vertrouwen (of lees hoe Kent C. Dodds gebruikte om een gehoste service bij PayPal te bouwen).

Misc

Babel Macros 🎣

Een van de beste onderdelen van Babel is de pluggbaarheid van de tool. In de loop der jaren is Babel veranderd van een “6to5” compiler in een code transform platform, wat fantastische optimalisaties mogelijk maakt voor zowel de gebruiker als de ontwikkelaar. Tonnen Babel plugins zijn ontwikkeld voor specifieke bibliotheken en gebruikssituaties om de prestaties en mogelijkheden van bibliotheek-API’s te verbeteren die anders niet mogelijk zouden zijn (sommige “bibliotheken” worden volledig getranspiled waardoor er helemaal geen runtime is).

Helaas vereist het toevoegen van deze plugins aan je codebase het wijzigen van de configuratie (wat sommige toolkits zoals create-react-app niet toestaan) en het voegt complexiteit toe aan je code omdat ontwikkelaars moeten weten welke Babel plugins actief zijn op een bestand om te weten wat er zal gebeuren met de code die ze aan het schrijven zijn. Deze problemen zijn opgelost door babel-plugin-macro’s van Kent C. Dodds!

Als babel-plugin-macros eenmaal is geïnstalleerd en toegevoegd aan uw configuratie (het is opgenomen in create-react-app v2), hoeft u zich niet te storen aan uw configuratie om macro’s te gebruiken. Bovendien is het nog eenvoudiger om uw eigen aangepaste transformaties te schrijven voor gebruik gevallen die specifiek zijn voor uw app of een deel van uw code.

Lees meer over babel-plugin-macros in onze oorspronkelijke post “Zero-config code transformatie met babel-plugin-macro’s”.

Module Targeting

Babel heeft altijd geprobeerd om de grootte impact van transformaties en mogelijkheden die zij bieden aan JavaScript-auteurs in evenwicht te brengen. In Babel 7, is het veel gemakkelijker geworden om Babel te configureren om de groeiende populariteit van het module/nomodule patroon te ondersteunen.

Notably, verschillende CLI tools voor populaire web frameworks (1, 2) maken al gebruik van de ondersteuning die leidt tot een ruw geschat 20% reductie in verzonden JavaScript naar consumenten van toepassingen getransporteerd door Babel.

Caller Metadata en Betere Defaults

We hebben een caller optie toegevoegd aan @babel/core zodat onze tooling metadata kan doorgeven aan presets/plugins. Bijvoorbeeld: babel-loader kan zoiets toevoegen zodat preset-env automatisch de moduletransformatie kan uitschakelen (hetzelfde met rollup:

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

Dit is opwindend omdat het een manier voor tooling mogelijk maakt om betere standaards en minder configuratie te bieden! Voor het geval van webpack/rollup: we kunnen automatisch overgaan op het gebruik van hun module transformatie in plaats van die van Babel (zelfde met import("a")). Kijk uit naar meer tooling om hier voordeel uit te halen in de toekomst!

klasse C breidt HTMLElement uit {}

Een van onze oudste problemen krijgt een eigen rubriek (details)

Babel heeft altijd het voorbehoud gehad dat het geen ondersteuning kon bieden voor het uitbreiden van native build-ins (Array, Error, enz.) en nu kan het dat wel! We hebben hier veel problemen over gekregen; 🎉 je zou het moeten vieren zoals Andrea!

Deze verandering is doorgevoerd in de class plugin, dus het zou automatisch ingeschakeld moeten zijn als je preset-env gebruikt.

Website veranderingen 🌏

We hebben onze site verplaatst van Jekyll naar Docusaurus!

We zijn nog steeds bezig met het opzetten van vertalingen met Crowdin, en met Babel 7 uit, zullen we in een betere positie zijn om dat proces te starten.

REPL

We hebben de REPL herschreven als een React Component, en hebben samen met Ives gewerkt aan een betere integratie met CodeSandbox. Hierdoor kun je elke plugin of preset van npm in de REPL installeren en ook alle updates krijgen die CodeSandbox krijgt.

We doen weer mee aan Rails Girls Summer of Code! Deze keer hebben Gyujin en Sujin hard gewerkt om Boopathi’s babel-time-travel te integreren in de REPL, die je nu al kunt testen!

Er zijn hier zoveel mogelijkheden om betrokken te raken om Babel, ASTs, en andere tools beter te laten werken!

We hebben een liedje 🎶

Hallelujah-In Praise of Babel

Op een dag gaf Angus ons een liedje dat ik geweldig vond, dus waarom zouden we het niet ons “officiële” liedje maken? En Shawn heeft hier een briljante cover van gemaakt.

Je kunt het vinden in onze repo op SONG.md. We hopen dat andere projecten hier gehoor aan geven!

What’s Next?

  • Babel is inherent verbonden aan wat het compileert: JavaScript. Zolang er nieuwe toevoegingen zijn om voor te stellen/aan te werken, is er werk aan de winkel. Dat omvat ook de tijd/inspanningen om de syntaxis te implementeren en te onderhouden, zelfs voordat deze “stabiel” wordt. We geven om het hele proces: het upgradepad, het onderwijzen van nieuwe functies, het onderwijzen van standaarden/taalontwerp, gebruiksgemak en integratie met andere projecten.
    • Gerelateerd: we zijn bijna klaar met het implementeren van het nieuwe decorators-voorstel in Babel, met dank aan Nicolò. Het is een lange reis geweest (het heeft meer dan een jaar geduurd!) omdat het nieuwe voorstel compleet anders en veel krachtiger is dan het oude, maar het is bijna zover 🎉. Je kunt het verwachten in een van de volgende kleine versies, samen met een blog post die de veranderingen in detail zal uitleggen.
  • Boopathi heeft hard gewerkt aan het onderhoud van babel-minify, dus daar gaan we nu een 1.0 voor maken!
  • Er zijn veel nieuwe functies in de maak: plugin-ordening, betere validatie/fouten, snelheid, heroverweging van losse/spec-opties, caching, asynchroon gebruik van Babel, bouwen tegen zichzelf vanuit CI, rooktests, het uitvoeren van test262. Bekijk deze roadmap voor meer ideeën!

We hebben geen geheime plannen: we doen ons best met wat we hebben om deze gemeenschap te dienen.

Open Source is a Mirror

Ik zou het geweldig vinden als we de tijd en de middelen zouden hebben om al deze ideeën uit te voeren en om het goed te doen. Maar zoals we hebben laten zien met deze huidige release, duurt het veel langer dan verwacht!

Waarom duren deze releases eigenlijk zo lang? Komt het door de feature creep, zowel van onszelf als van onze gebruikers? Is het omdat we niet begrijpen hoe we prioriteiten moeten stellen tussen alle mogelijke dingen om toe te voegen of te repareren? Beslissen om laaghangend fruit te repareren in plaats van fundamentele problemen tot het einde? Of “afleiding” van het helpen van anderen op GitHub, Slack, Twitter? Zijn we gewoon slecht in het inschatten van onze tijd, het begrijpen van de complexiteit van deze problemen, overcommitteren als vrijwilligers?

Of zijn we gewoon het stellen van een te hoge verwachting van onszelf, of voelen we ons zo onder druk gezet door anderen om te presteren en aan hun behoeften te voldoen ten koste van onszelf? Ik kan het alleen maar omschrijven als angst als ik een bericht zie van iemand online die zich afvraagt waarom iets nog niet is uitgebracht, terwijl een ander vraagt waarom deze bug nog niet is opgelost. Ik wil het gewoon snel uitbrengen en er klaar mee zijn, maar ik heb ook het verlangen om dit serieus te nemen.

Ik heb geprobeerd om een aantal van deze gedachten en worstelingen te verwoorden in mijn toespraak van vorige week bij React Rally: Through the (Open Source) Looking Glass, waarvan ik hoop dat je de gelegenheid te baat kunt nemen om ernaar te luisteren. De vraag die ik mezelf stel: Wat kan ik doen aan de onvermijdelijke cyclus van onderhouder burn-out, constante angst, en onrealistische verwachtingen?

Net als veel van het leven, weerspiegelen de dingen die we doen ons karakter en laten we zien hoe we echt zijn. De acties die we ondernemen kunnen ons op zichzelf veranderen, ten goede of ten kwade. Als we ons werk serieus willen nemen, moeten we elkaar verantwoordelijk houden voor deze gewoonten die zo ingebakken lijken in onze cultuur: van onmiddellijke bevrediging, succes in termen van metriek, aanspraak versus dankbaarheid, en trots op overwerken.

Maar ondanks dit alles is het werken aan deze release zo de moeite waard geweest.

Bedankt

Dit is echt een opwindende release, niet alleen door terug te kijken op wat we hebben bereikt en mogelijk hebben gemaakt, maar nog veel meer door te weten hoeveel tijd en hart erin is gestoken om dit het afgelopen jaar te realiseren. Het is moeilijk te geloven welke kansen en ervaringen zich onderweg hebben voorgedaan: interactie met en het helpen van bedrijven van over de hele wereld, het vinden van vrienden in bijna elke stad die ik heb bezocht, en eerlijk spreken over de ongelooflijke reis die deze groep samen heeft ondernomen.

Persoonlijk heb ik nog nooit zoveel mentale energie gestoken in iets van deze omvang en ik wil graag zoveel mensen bedanken voor het oppeppen van ons langs de weg. In het bijzonder wil ik Logan Smyth bedanken, die ontelbare tijd heeft besteed aan het veranderen van de kern van het programma en altijd de tijd neemt om zo behulpzaam te zijn in onze Slack terwijl hij ook freelance werkt, en Brian Ng, die zo’n grote bijdrage heeft geleverd om Babel te blijven onderhouden en al mijn blog posts en gesprekken te reviewen. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo, en Justin Ridgewell hebben allemaal hun steentje bijgedragen om deze release mogelijk te maken en plezierig om aan te werken.

Shoutout aan alle vele leden van de gemeenschap op Slack, Twitter, en over alle projecten op GitHub die ook moeten begrijpen wat we aan het doen zijn voor hun eigen gebruikers. Ik wil graag mijn vrienden bij Behance/Adobe enorm bedanken voor het sponsoren van mij voor bijna een jaar om halftijds aan Babel te werken voordat ik besloot om voltijds te gaan (en ook voor het helpen testen van Babel 7 in productie gedurende de hele tijd dat ik daar was). Grote dank aan al onze sponsors voor onze Open Collective, in het bijzonder Trivago en Handshake. En dank aan onze vrienden en familie voor al hun liefde en steun.

We zijn allemaal behoorlijk moe op dit punt, maar het is echt een eer en voorrecht geweest om op deze manier te dienen, dus we hopen dat u de release waardeert.