Babel 7 släppt

Efter nästan två år, 4k commits, över 50 förhandsutgåvor och mycket hjälp är vi glada att kunna meddela att Babel 7 är släppt. Det har gått nästan tre år sedan Babel 6 släpptes! Det finns många rörliga delar så ha tålamod med oss under de första veckorna av lanseringen. Babel 7 är en enorm version: vi har gjort den snabbare, skapat ett uppgraderingsverktyg, JS-konfigurationer, ”overrides” för konfigurationer, fler alternativ för storlek/minifiering, JSX Fragments, TypeScript, nya förslag och mycket mer!

Om du uppskattar det arbete vi gör på Babel kan du sponsra Babel på Open Collective, stödja mig på Patreon eller få dig eller ditt företag att engagera dig i Babel som en del av arbetet. Vi skulle uppskatta det kollektiva ägandet av detta viktiga projekt i JavaScript-communityt!

Det händer! 🎉

Mjukvara kommer aldrig att vara perfekt, men vi är redo att leverera något som redan har använts i produktionen under en tid nu! @babel/core ligger redan på 5,1 miljoner nedladdningar/månad på grund av dess användning i verktyg som Next.js 6, vue-cli 3.0, React Native 0.56 och till och med WordPress.coms frontend 🙂!

Babels roll

Jag vill börja det här inlägget med att återigen presentera Babels roll i JavaScript-ekosystemet under de senaste åren.

Det ursprungliga problemet var att det till skillnad från serverspråk inte fanns något sätt att garantera att alla användare har samma stöd för JavaScript eftersom användarna kunde använda olika webbläsare med olika nivåer av stöd (särskilt äldre versioner av Internet Explorer). Om utvecklare ville använda ny syntax (t.ex. class A {}) skulle användare på gamla webbläsare bara få en tom skärm på grund av SyntaxError.

Babel erbjöd ett sätt för utvecklare att använda den senaste JavaScript-syntaxen samtidigt som de inte behövde oroa sig för hur de skulle göra den bakåtkompatibel för sina användare genom att översätta den (class A {} till var A = function A() {}).

På grund av dess förmåga att omvandla JavaScript-kod kan det också användas för att implementera nya funktioner: det har alltså blivit en bro för att hjälpa TC39 (den kommitté som specificerar JavaScript-språket) att få feedback på föreslagna JavaScript-idéer och för att samhället ska kunna påverka språkets framtid.

Babel är grundläggande för JavaScript-utvecklingen idag. Det finns för närvarande över 1,3 miljoner beroende repos på GitHub, 17 miljoner nedladdningar på npm per månad och hundratals användare inklusive många stora ramverk (React, Vue, Ember, Polymer) och företag (Facebook, Netflix, Airbnb). Det har blivit en sådan grund för JavaScript-utveckling att många inte ens vet att det används. Även om du inte använder det själv är det mycket troligt att dina beroenden använder Babel.

Maintainers are People

Babel har ett enormt inflytande inte bara på själva språkets framtid utan även på dess community och ekosystem. Men trots allt detta ansvar är Babel bara ett gemenskapsdrivet projekt som drivs av ett par frivilliga.

Det var först under det gångna året som en del av teamet kunde träffas för första gången personligen:

Det ursprungliga @babeljs-teamet, äntligen tillsammans. Från vänster till höger: @left_pad, @jamiebuilds, @sebmck, undertecknad och @loganfsmyth pic.twitter.com/XfPj6OhZfA

– Amjad Masad (@amasad) May 3, 2018

Så mycket som det här är ett tillkännagivande, vill jag ta tillfället i akt att påminna alla om projektets status.

Jag själv gick med några månader före 6.0-utgåvan, som hade sin egen mängd kontroverser och motreaktioner. Mycket av mottagandet där ledde till utbrändhet hos befintliga underhållare (inklusive Sebastian, Babels skapare) och några av oss som var kvar tog över tyglarna.

Likt många underhållare snubblade vi av misstag in i rollen. Många av oss hade ingen formell utbildning i hur kompilatorer fungerade eller hur man underhåller ett projekt med öppen källkod. Ironiskt nog undvek jag till och med medvetet att välja datavetenskap som huvudämne i college eftersom jag inte ville ta kurser om kompilatorer eller något på låg nivå eftersom det verkade ointressant och svårt. Ändå fann jag att jag drogs till verktyg, linters, Babel och JavaScript som språk.

Jag vill uppmuntra alla att titta på de öppen källkodsprojekt som ni är beroende av och att stödja dem (både med tid och monetärt stöd om det är möjligt).

Många underhållare är inte av naturen experter på de saker de arbetar med; och det finns mycket att åstadkomma genom att bara påbörja arbetet först. Du kommer in med både nyfikenhet och ödmjukhet, vilket båda är bra egenskaper att ha som underhållare. Min önskan är en förhoppning om projektets vision kontra att vi alla bara gör ”uppgifter”.

Babel är inte ett företag, eller ett open source-team på ett stort företag som Facebook. Det finns bara en handfull frivilliga som arbetar med Babel, och det har bara gått några månader sedan jag tog steget att lämna mitt jobb och vara den enda hittills som arbetar med öppen källkod på heltid. Men människor kan komma och gå, ha liv utanför denna ”hobby”, skaffa familj, gå vidare till andra saker, byta jobb eller söka jobb osv. Gör vi kollektivt vad vi kan för att upprätthålla de saker som är så grundläggande för hur vi arbetar, eller kommer vi att låta grunden sakta falla sönder? Hur håller vi öppen källkod välkomnande och inkluderande men med tydliga gränser? Kan vi lära oss av andra underhållares erfarenheter?

Och även om öppen källkod helt klart har tagit över programvaran, kan vi verkligen betrakta den som frisk utan att ta hänsyn till människorna bakom den?

#BabelSponsorsEverything

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

– Harry Wolff (@hswolff) August 17, 2018

Open Source sustainability känns som att dela ut en offerkorg just nu. Det är inte svårt att ange det värde som projekten ger till de tusentals människor och företag som använder öppen källkod, men ändå ser vi inte att det värdet visas för de få som är villiga att lägga ner arbetet. Det kan finnas så många sätt att stödja öppen källkod och ändå fungerar inte alla tillvägagångssätt för varje projekt eller person.

Nu går vi till förändringarna!!!

Större brytande förändringar

Vi dokumenterar dessa i vår migrationsguide. Många av dessa ändringar kan göras automatiskt med vårt nya babel-upgrade verktyg, eller kan läggas till i framtiden.

• Släpp stöd för ounderhållna Node-versioner: 0.10, 0.12, 4, 5 (detaljer)
• Förflyttar oss till @babel-namnområdet genom att byta till att använda ”scoped”-paket (detaljer). Detta hjälper till att särskilja officiella paket, så babel-core blir @babel/core (och ingen squatting)
• Förstör (och sluta publicera) alla årliga förinställningar (preset-es2015, etc) (detaljer). @babel/preset-env ersätter behovet av dessa eftersom den innehåller alla årliga tillägg samt möjligheten att rikta sig till en specifik uppsättning webbläsare
• Släpp också ”Stage”-förinställningarna (@babel/preset-stage-0, etc) till förmån för att välja enskilda förslag. På samma sätt ta bort förslag från @babel/polyfill som standard (detaljer). Överväg att läsa hela inlägget om detta för mer förklaring.
• Vissa paket har bytt namn: alla plugin för TC39-förslag kommer nu att vara -proposal istället för -transform (detaljer). Så @babel/plugin-transform-class-properties blir @babel/plugin-proposal-class-properties.
• Inför ett peerDependency på @babel/core för vissa användarvänliga paket (t.ex. babel-loader, @babel/cli, etc.) (detaljer)

babel-upgrade

babel-upgrade är ett nytt verktyg som vi startat och som försöker göra automatiska uppgraderingsändringar: för närvarande med beroenden i package.json och .babelrc config.

Vi rekommenderar att du kör det direkt på en git-repo med npx babel-upgrade, eller så kan du installera det globalt med npm i babel-upgrade -g.

Om du vill ändra filerna kan du passera --write samt --install.

npx babel-upgrade --write --install

Vänligen överväga att bidra genom att rapportera problem eller PR:s för att hjälpa alla att övergå till Babel 7! En förhoppning för framtiden är att vi använder samma verktyg för alla framtida ändringar och skapar en bot för att uppdatera PR-projekt.

JavaScript-konfigurationsfiler

Vi introducerar babel.config.js. Det är inte ett krav eller ens en ersättning för .babelrc, men att ha detta kan vara användbart i vissa fall.

*.js Konfigurationsfiler är ganska vanliga i JavaScript-ekosystemet. ESLint och Webpack tillåter båda .eslintrc.js respektive webpack.config.js konfigurationsfiler.

Nedan följer fallet att endast kompilera med ett insticksprogram i ”produktion” (du kan redan göra detta med alternativet "env" i en .babelrc-fil):

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

babel.config.js har en annan konfigurationsupplösning än en .babelrc. Den kommer alltid att lösa upp konfigurationen från den filen jämfört med när Babel ursprungligen skulle göra en sökning från varje fil och uppåt tills den hittade en config. Detta gör det möjligt att dra nytta av nästa funktion som publiceras nedan, overrides.

Selective Configuration with overrides

Nyligen publicerade jag ett inlägg med tankar om både publicering av ES2015+-paket och konsumtion/kompilering av dem.

Det finns ett avsnitt som handlar om hur man använder en ny nyckel i Babels config som heter overrides och som gör det möjligt att specificera olika configs per glob.

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

Detta gör det möjligt för en applikation som kräver olika kompileringskonfigurationer för sina tester, sin klientkod och sin serverkod att hoppa över behovet av att skapa en ny .babelrc-fil per mapp.

Snabbhet 🏎

Babel i sig självt är snabbare, så det borde ta mindre tid att bygga! Vi har gjort en hel del ändringar för att optimera koden samt för att acceptera patchar från v8-teamet. Vi är glada över att vara en del av Web Tooling Benchmark tillsammans med många andra bra JavaScript-verktyg.

Utdragningsalternativ

Babel har haft stöd för förinställnings- och insticksprogramalternativ sedan en tid tillbaka. För att sammanfatta kan du linda in insticksmodulen i en array och skicka ett optionsobjekt till insticksmodulen:

{ "plugins": , ]}

Vi har gjort några ändringar i loose-alternativet för vissa insticksmoduler och lagt till några nya alternativ för andra! Observera att genom att använda dessa alternativ väljer du ett beteende som inte följer specifikationerna och bör veta vad du gör; detta kan bli ett problem när du stänger av kompileringen för att använda syntaxen nativt. Den här typen av alternativ används bäst i ett bibliotek, om alls.

• För klasser kommer class A {} nu inte att inkludera classCallCheck-hjälpen.

class A {}

var A = function A() {- _classCallCheck(this, A);};

• Det finns ett nytt alternativ om varje användning av en for-of-slinga bara är en 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);}

• Vi utesluter transform-typeof-symbolinsticksmodulen i loose-läge för preset-env #6831

Vi har funnit många bibliotek som redan gör detta, så vi bestämde oss för att göra detta som standard.

Notera att standardbeteendet är att vara så spec-kompatibelt som möjligt så att det går smidigt att stänga av Babel eller använda preset-env jämfört med att tillåta mindre utdata bara för att spara bytes (det finns en avvägning där som varje projekt kan göra). Vi planerar att arbeta på bättre dokumentation och verktyg för att göra det lättare.

Stöd för ”ren” annotering

Efter #6209 annoteras transpilerade ES6-klasser med en /*#__PURE__*/-kommentar som gör det möjligt att ge en ledtråd till minifiers som Uglify och babel-minify för eliminering av död kod. Dessa annotationer läggs även till andra hjälpfunktioner.

class C { m() {}}

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

Det kan finnas fler möjligheter till tips och optimeringar för minifier, låt oss veta!

Syntax

TC39 Proposals Support

Jag vill återigen upprepa att vi har tagit bort Stage-förinställningarna till förmån för en policy där vi ber användarna att uttryckligen välja att ansluta sig till förslagen < Stage 4.

Oroblematiken är att vi automatiskt väljer in människor i syntax som inte är fixerad eller gjord med en förväntan om att den inte kommer att ändras. Men så är inte fallet, särskilt inte när det gäller förslag som är steg 0 eller 1. Det här inlägget förklarar lite om hur man tänker bakom nyare idéer.

Här är en liten lista över några av de nya syntaxer som Babel stöder (tänk på att denna funktionsuppsättning är ett rörligt mål som kan läggas till/tas bort/avstängas) och vilka som har lagts till i v7:

• ES2018: Object Rest Spread (var a = { b, ...c })
• ES2018 (ny): Unicode Property Regex
• ES2018 (ny): JSON Superset
• ES2015 (ny): new.target
• Steg 3 (nytt): new.target
• Steg 3 (nytt): Klass privata instansfält (class A { #b = 2 })
• Steg 3 (WIP): Statiska klassfält, privata statiska metoder (class A { static #a() {} })
• Steg 3 (nytt): Valfri fångstbindning try { throw 0 } catch { do() }
• Steg 3 (nytt): BigInt (endast syntax)
• Steg 3: Dynamisk import (import("a"))
• Steg 2 (nytt): import.meta (endast syntax) (import.meta.url)
• Steg 2 (nytt): Numeriska separatorer (1_000)
• Steg 2 (nytt): function.sent
• Steg 2: export-namespace-from (export * as ns from 'mod'), delad från export-extensions
• Steg 2: Dekoratorer. Se nedan för en uppdatering av våra framsteg!
• Steg 1: export-default-from (export v from 'mod'), delad från export-extensions
• Steg 1 (nytt): (a?.b)
• Steg 1 (nytt): Valfri kedja (a?.b)
• Steg 1 (nytt): Valfri kedja (a?.b): Logiska tilldelningsoperatorer (a &&= b; a ||= b)
• Steg 1 (nytt): Nulägesoperator för sammanslagning (a ?? b)
• Steg 1 (nytt): Pipeline Operator (a |> b)
• Steg 1 (nytt): Det är svårt för någon att hålla reda på alla förslag, så vi försöker göra det på babel/proposals.
  

  TypeScript-stöd (@babel/preset-typescript)

  Vi har samarbetat med TypeScript-teamet för att få Babel att analysera/omvandla typsyntax med @babel/preset-typescript, på samma sätt som vi hanterar Flow med @babel/preset-flow.

  För mer information, se det här inlägget från TypeScript-teamet!

  Förut (med typer):

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

  Efter (typerna borttagna):

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

  Både Flow och Typescript är verktyg som gör det möjligt för JavaScript-användare att dra nytta av gradvis typning, och vi skulle vilja aktivera båda i Babel. Vi planerar att fortsätta att samarbeta nära med deras respektive team på FB och Microsoft (förutom med samhället i stort) för att upprätthålla kompatibilitet och stödja nya funktioner.

  Den här integrationen är ganska ny, så det är möjligt att viss syntax inte stöds fullt ut. Vi skulle uppskatta din hjälp med att rapportera problem och kanske skicka en PR!

  Stöd för JSX-fragment (<>)

  Som nämnts i React-bloggen har stöd för JSX-fragment funnits tillgängligt från och med 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

  Babel-upgrade PR pågår

  @babel/runtime har delats upp i @babel/runtime och @babel/runtime-corejs2 (PR). Den förstnämnda innehåller endast Babels hjälpfunktioner och den sistnämnda innehåller det samt eventuella polyfillfunktioner (t.ex. Symbol, Promise).

  Babel kan behöva injicera vissa funktioner i den kod som kan återanvändas. Vi kallar dessa bara för ”hjälpfunktioner” precis som funktioner som delas mellan moduler.

  Ett exempel på detta är vid kompilering av en class (utan loose-läge på):

  Specifikationen säger att du måste anropa en klass med new Person(), men om den är kompilerad till en funktion kan du tekniskt sett bara använda Person(), så vi inkluderar en körtidskontroll för detta.

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

  Med @babel/plugin-transform-runtime och @babel/runtime (som ett beroende) kan Babel extrahera de enskilda funktionerna och bara kräva de modulära funktionerna för att möjliggöra mindre utdata på följande sätt:

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

  Det samma kan göras med external-helpers och rollup-plugin-babel. Vi undersöker om vi kan göra detta automatiskt i framtiden. Håll utkik efter ett fristående inlägg om Babels hjälpmedel snart.

  Automatisk polyfyllning (experimentell)

  Polyfyllningar är nödvändiga för att aktivera funktioner som Promise, Symbol i miljöer som inte har stöd för dem. Detta är viktigt när man skiljer mellan vad Babel gör som kompilator (omvandlar syntax) och vad en polyfill gör (implementerar inbyggda funktioner/objekt).

  Det är lätt att bara importera något som täcker allt som @babel/polyfill:

  import "@babel/polyfill";

  Men det inkluderar hela polyfill, och du kanske inte behöver importera allt om webbläsarna redan har stöd för det. Detta är samma problem som @babel/preset-env försöker lösa med syntax, så vi tillämpar det här med polyfills. Alternativet useBuiltins: "entry" gör detta genom att dela upp den ursprungliga importen i endast de importer som är nödvändiga.

  Men vi kan göra det bättre genom att endast importera de polyfills som används i kodbasen. Alternativet "useBuiltIns: "usage" är vårt första försök att aktivera något sådant (docs).

  Det kommer att köra igenom varje fil och injicera en import i början av varje fil om den inbyggda filen ”används” i koden. Till exempel:

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

  Den är inte perfekt så det kan förekomma falska positiva resultat.

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

  Andra idéer inom detta område är att använda polyfill.io om du är okej med att förlita dig på en tjänst (eller läs hur Kent C. Dodds använde det för att bygga en värdtjänst hos PayPal).

  Diverse

  Babel Macros 🎣

  En av de bästa delarna av Babel är att verktyget kan anslutas. Under årens lopp har Babel gått från att bara vara en ”6to5”-kompilator till en plattform för kodomvandling, vilket möjliggör några fantastiska optimeringar för både användarens och utvecklarens upplevelse. Massor av Babel-plugins har utvecklats för specifika bibliotek och användningsfall för att förbättra prestanda och möjligheter för biblioteks-API:er som annars inte skulle vara möjliga (vissa ”bibliotek” transpileras helt och hållet bort, vilket resulterar i att det inte finns någon körtid alls).

  Tyvärr krävs det att du ändrar konfigurationen för att lägga till dessa plugins till din kodbas (vilket vissa verktygslådor, som till exempel create-react-app, inte tillåter), och det gör koden mer komplex, eftersom utvecklarna måste veta vilka Babel-plugins som används för en fil för att veta vad som kommer att hända med koden de skriver. Dessa problem har lösts med babel-plugin-macros av Kent C. Dodds!

  När babel-plugin-macros har installerats och lagts till i din konfiguration (den ingår i create-react-app v2), behöver du inte bry dig om din konfiguration för att använda några makron. Dessutom är det ännu enklare att skriva egna anpassade transformationer för användningsfall som är specifika för din app eller en del av din kod.

  Lär dig mer om babel-plugin-macros i vårt originalinlägg ”Zero-config code transformation with babel-plugin-macros”.

  Module Targeting

  Babel har alltid försökt balansera storleksinverkan av transformationer och de möjligheter de ger JavaScript-författare. I Babel 7 har det blivit mycket enklare att konfigurera Babel för att stödja den växande populariteten av modul/nomodul-mönstret.

  Noterbart är att flera CLI-verktyg för populära webbramverk (1, 2) redan utnyttjar stödet, vilket leder till en minskning med ungefär 20 % av det skickade JavaScript till konsumenter av applikationer som transpilerats av Babel.

  Metadata för uppringare och bättre standardinställningar

  Vi har lagt till ett caller-alternativ till @babel/core så att våra verktyg kan skicka metadata till förinställningar/plugins. Till exempel: babel-loader kan lägga till något liknande så att preset-env automatiskt kan inaktivera modulomvandlingen (samma sak med rollup:

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

  Det här är spännande eftersom det möjliggör ett sätt för verktygen att tillhandahålla bättre standardinställningar och mindre konfiguration! För fallet webpack/rollup: vi kan automatiskt avvakta med att använda deras modultransformation istället för Babels (samma som import("a")). Håll utkik efter fler verktyg för att dra nytta av detta i framtiden!

  class C extends HTMLElement {}

  En av våra äldsta frågor får en egen rubrik (detaljer)

  Babel har alltid haft den invändningen att det inte kunde stödja utökning av inhemska inbyggda element (Array, Error, etc) och nu kan det! Vi har fått många frågor om detta; 🎉 du borde fira som Andrea!

  Den här ändringen gjordes i class-pluginet så det borde vara automatiskt aktiverat om du använder preset-env.

  Webbplatsändringar 🌏

  Vi har flyttat vår webbplats från Jekyll till Docusaurus!

  Vi håller fortfarande på att sätta upp översättningar med Crowdin, och med Babel 7 ute kommer vi att ha bättre förutsättningar att påbörja den processen.

  REPL

  

  Vi har skrivit om REPL:en som en React-komponent, och har samarbetat med Ives för att integrera bättre med CodeSandbox. Detta gör att du kan installera alla insticksprogram eller förinställningar från npm i REPL samt få alla uppdateringar som CodeSandbox får.

  Vi deltar i Rails Girls Summer of Code igen! Den här gången har Gyujin och Sujin arbetat hårt för att integrera Boopathis babel-time-travel i REPL som du kan testa redan nu!

  Det finns så många möjligheter här att engagera sig för att få Babel, ASTs och andra verktyg att fungera bättre!

  Vi har en sång 🎶

  Hallelujah-In Praise of Babel

  En dag gav Angus oss en sång som jag tyckte var fantastisk, så varför inte göra den till vår ”officiella” sång? Och Shawn gjorde en lysande cover här.

  Du kan hitta den i vår repo på SONG.md. Vi hoppas att andra projekt kommer att följa upp detta!

  Vad kommer härnäst?

  • Babel är av naturliga skäl knutet till vad det kompilerar: JavaScript. Så länge det finns nya tillägg att föreslå/arbeta med finns det arbete att göra där. Det inkluderar tid/ansträngning för att implementera och underhålla syntaxen även innan den blir ”stabil”. Vi bryr oss om hela processen: uppgraderingsvägen, utbildning om nya funktioner, undervisning om standarder/språksdesign, användarvänlighet och integration med andra projekt.
    • Relaterat: Vi är nästan klara med att genomföra det nya förslaget om dekoratorer i Babel tack vare Nicolò. Det har varit en lång resa (det har tagit mer än ett år!) eftersom det nya förslaget är helt annorlunda och mycket kraftfullare än det gamla, men det är nästan klart 🎉. Du kan förvänta dig att det kommer att släppas i en av de kommande mindre versionerna, tillsammans med ett blogginlägg som kommer att förklara ändringarna i detalj.
  • Boopathi har flitigt underhållit babel-minify, så vi kommer att göra en 1.0 för det härnäst!
  • Det finns många nya funktioner på gång: beställning av insticksmoduler, bättre validering/fel, snabbhet, omprövning av lösa/spec-alternativ, cachelagring, användning av Babel asynkront, byggande mot sig självt från CI, röktester, körning av test262. Kolla in det här roadmap-dokumentet för några fler möjliga idéer!

  Vi har inga hemliga planer: vi försöker göra det bästa vi kan med det vi har för att tjäna den här gemenskapen.

  Open Source is a Mirror

  Jag skulle älska om vi hade tid och resurser för att genomföra alla dessa idéer och att göra det bra. Men som vi har visat med den nuvarande versionen tar saker och ting mycket längre tid än väntat!

  Varför tar dessa versioner så lång tid egentligen? Är det på grund av funktionskräcken, både från oss själva och våra användare? Berodde det på att vi inte förstår hur vi ska prioritera bland alla möjliga saker att lägga till eller åtgärda? Beslutar vi oss för att fixa lågt hängande frukter jämfört med grundläggande problem till slutet? Eller ”distraktioner” från att hjälpa andra på GitHub, Slack, Twitter? Är vi bara dåliga på att uppskatta vår tid, förstå komplexiteten i dessa frågor och överengagera oss som volontärer?

  Och ställer vi bara för höga krav på oss själva, eller känner vi oss så pressade av andra att vi måste prestera och anpassa oss till deras behov på bekostnad av oss själva? Jag kan bara beskriva det som skräck när jag ser ett meddelande från någon på nätet som undrar varför något inte har släppts samtidigt som en annan frågar varför det här felet inte är åtgärdat ännu. Jag vill bara rusa ut det och vara klar med det, men jag har också en önskan att ta detta på allvar.

  Jag har försökt uttrycka några av dessa tankar och kamper i mitt föredrag förra veckan på React Rally: Through the (Open Source) Looking Glass, som jag hoppas att du kan passa på att lyssna på. Frågan jag ställer mig själv:

  Som mycket i livet speglar de saker vi gör vår karaktär och visar oss hur vi verkligen är. De åtgärder vi vidtar kan i sig själva förändra oss, på gott och ont. Om vi ska ta vårt arbete på allvar bör vi hålla varandra ansvariga för dessa vanor som verkar vara så inbäddade i vår kultur: om omedelbar tillfredsställelse, framgång i termer av mätvärden, berättigande kontra tacksamhet och stolthet över att överarbeta.

  Men trots allt detta har det varit så värt det att arbeta för detta släpp.

  Tack

  Detta är verkligen en riktigt spännande utgåva, inte bara genom att se tillbaka på vad vi har åstadkommit och möjliggjort, utan mycket mer bara genom att veta hur mycket tid och hjärta som lagts ner på att göra det möjligt under det senaste året. Det är svårt att tro på de möjligheter och upplevelser som har skett längs vägen: att interagera med och hjälpa företag från hela världen, att hitta vänner i nästan alla städer som jag har besökt och att tala ärligt om den otroliga resa som den här gruppen har gjort tillsammans.

  Personligen har jag aldrig lagt ner så mycket av min mentala energi på något i den här storleksordningen, och jag vill tacka så många människor för att de har lyft upp oss längs vägen. Shoutouts i synnerhet till Logan Smyth som har lagt ner otaliga mängder tid på att ändra så mycket av hur kärnan fungerar och alltid tar sig tid att vara så hjälpsam i vår Slack samtidigt som han jobbar frilans och Brian Ng som har klivit upp på ett så stort sätt för att fortsätta att underhålla Babel samt granska alla mina blogginlägg och föredrag. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo och Justin Ridgewell har alla varit avgörande för att göra den här utgåvan möjlig och trevlig att arbeta med.

  Shoutout till alla de många communitymedlemmarna på Slack, Twitter och i alla projekt på GitHub som också måste förstå vad vi gör för sina egna användare. Jag vill ge ett stort tack till mina vänner på Behance/Adobe för att de sponsrade mig i nästan ett år för att arbeta med Babel på halvtid innan jag bestämde mig för att gå på heltid (samt för att de hjälpte till att testa Babel 7 i produktion under hela tiden jag var där). Ett stort tack till alla våra sponsorer för vårt Open Collective, särskilt Trivago och Handshake. Och tack till våra vänner och vår familj för all deras kärlek och stöd.

  Vi är alla ganska trötta vid det här laget, men det har verkligen varit en ära och ett privilegium att tjäna på det här sättet, så vi hoppas att ni uppskattar releasen!