Babel 7 frigivet

BY admin
|

Efter næsten 2 år, 4k commits, over 50 præudgivelser og en masse hjælp er vi glade for at kunne annoncere udgivelsen af Babel 7. Der er gået næsten 3 år siden udgivelsen af Babel 6! Der er mange bevægelige dele, så hav tålmodighed med os i de første uger efter udgivelsen. Babel 7 er en stor udgivelse: vi har gjort den hurtigere, skabt et opgraderingsværktøj, JS-konfigurationer, config “overrides”, flere muligheder for størrelse/minificering, JSX Fragments, TypeScript, nye forslag og meget mere!

Hvis du sætter pris på det arbejde, vi laver på Babel, kan du sponsorere Babel på Open Collective, støtte mig på Patreon eller få dig eller din virksomhed involveret i Babel som en del af arbejdet. Vi ville sætte pris på det kollektive ejerskab af dette vigtige projekt i JavaScript-fællesskabet!

Det sker! 🎉

Software bliver aldrig perfekt, men vi er klar til at sende noget, der allerede er blevet brugt i produktion i et stykke tid nu! @babel/core er allerede på 5,1 mil downloads/måned på grund af dets brug i værktøjer som Next.js 6, vue-cli 3.0, React Native 0.56 og endda WordPress.com’s frontend 🙂!

Babels rolle

Jeg vil gerne starte dette indlæg med at genintroducere Babels rolle i JavaScript-økosystemet i løbet af de sidste par år.

Det oprindelige problem var, at der i modsætning til serversprog ikke var nogen måde at garantere, at alle brugere har den samme understøttelse af JavaScript, fordi brugerne kunne bruge forskellige browsere med forskellige understøttelsesniveauer (især ældre versioner af Internet Explorer). Hvis udviklere ønskede at bruge ny syntaks (f.eks. class A {}), ville brugere på gamle browsere blot få en tom skærm på grund af SyntaxError.

Babel gav udviklerne mulighed for at bruge den nyeste JavaScript-syntaks, samtidig med at de ikke behøvede at bekymre sig om, hvordan de skulle gøre den bagudkompatibel for deres brugere ved at oversætte den (class A {} til var A = function A() {}).

På grund af dets evne til at omdanne JavaScript-kode kan det også bruges til at implementere nye funktioner: det er således blevet en bro til at hjælpe TC39 (den komité, der specificerer JavaScript-sproget) med at få feedback på foreslåede JavaScript-idéer og for fællesskabet at få indflydelse på sprogets fremtid.

Babel er grundlæggende for JavaScript-udviklingen i dag. Der er i øjeblikket over 1,3 millioner afhængige repos på GitHub, 17 millioner downloads på npm om måneden og hundredvis af brugere, herunder mange store frameworks (React, Vue, Ember, Polymer) og virksomheder (Facebook, Netflix, Airbnb). Det er blevet et sådant fundament for JavaScript-udvikling, at mange mennesker ikke engang ved, at det bliver brugt. Selv hvis du ikke selv bruger det, er der stor sandsynlighed for, at dine afhængigheder bruger Babel.

Maintainers are People

Babel har en enorm indflydelse ikke kun på selve sprogets fremtid, men også på dets fællesskab og økosystem. Men selv med alt dette ansvar er Babel blot et fællesskabsdrevet projekt af et par frivillige.

Det var først i det forgangne år, at nogle af holdet kunne mødes for første gang personligt:

Det oprindelige @babeljs-hold, endelig samlet. Fra venstre til højre: @left_pad, @jamiebuilds, @sebmck, undertegnede og @loganfsmyth pic.twitter.com/XfPj6OhZfA

– Amjad Masad (@amasad) May 3, 2018

Så meget som dette er et annonceringsindlæg, vil jeg gerne benytte lejligheden til at minde alle om status for dette projekt.

Jeg selv sluttede mig til et par måneder før udgivelsen af 6.0, som havde sin egen mængde af kontroverser og modspil. En stor del af modtagelsen der førte til udbrændthed hos de eksisterende vedligeholdere (herunder Sebastian, Babels skaber), og et par af os, der var tilbage, overtog tøjlerne.

Lige mange vedligeholdere snublede vi tilfældigt ind i rollen. Mange af os havde ikke nogen formel uddannelse i, hvordan compilere fungerede, eller hvordan man vedligeholder et open source-projekt. Ironisk nok undgik jeg endda bevidst at vælge datalogi som hovedfag på universitetet, fordi jeg ikke ønskede at tage kurser om compilere eller noget andet på lavt niveau, fordi det virkede uinteressant og svært. Alligevel blev jeg tiltrukket af tooling, linters, Babel og JavaScript som sprog.

Jeg vil gerne opfordre alle til at undersøge de open source-projekter, som man er afhængig af, og til at støtte dem (både med tid og økonomisk støtte, hvis det er muligt).

Mange vedligeholdere er ikke i sagens natur eksperter i de ting, de arbejder på; og der er meget at opnå ved bare at begynde på arbejdet først. Du vil komme ind med både nysgerrighed og ydmyghed, hvilket begge er gode egenskaber at have som vedligeholder. Mit ønske er et håb om visionen for projektet frem for at vi alle bare laver “opgaver”.

Babel er ikke et firma, eller et open source-team i en stor virksomhed som Facebook. Der er kun en håndfuld frivillige, der arbejder på Babel, og det er kun et par måneder siden, at jeg tog springet til at forlade mit job og være den eneste indtil videre til at arbejde på open source på fuld tid. Men folk kan komme og gå, have liv uden for denne “hobby”, stifte familie, gå videre til andre ting, skifte job eller søge job osv. Gør vi kollektivt det, vi kan, for at opretholde de ting, der er så grundlæggende for vores måde at arbejde på, eller vil vi tillade, at fundamentet langsomt smuldrer? Hvordan kan vi holde open source indbydende og inkluderende, men med klare grænser? Kan vi lære af andre vedligeholderes erfaringer?

Selv om open source klart har overtaget softwaren, kan vi så virkelig betragte den som værende i en sund tilstand uden at tage hensyn til de mennesker, der står bag den?

#BabelSponsorsEverything

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

– Harry Wolff (@hswolff) August 17, 2018

Open Source sustainability feels like giving out a offerkurv at the moment. Det er ikke svært at angive den værdi, som projekterne giver til de tusindvis af mennesker og virksomheder, der bruger open source, men alligevel ser vi ikke, at den værdi bliver vist til de få, der er villige til at lægge arbejde i det. Der kan være så mange måder at støtte open source på, og alligevel er det ikke alle tilgange, der fungerer for hvert enkelt projekt eller folk.

Nu går vi til ændringerne!!!

Større brud på ændringer

Vi dokumenterer disse i vores migrationsvejledning. Mange af disse ændringer kan udføres automatisk med vores nye babel-upgrade værktøj, eller kan tilføjes i fremtiden.

  • Faldt understøttelse af ikke-vedligeholdte Node-versioner bort: 0.10, 0.12, 4, 5 (detaljer)
  • Flyt os til @babel-navneområdet ved at skifte til at bruge “scoped”-pakker (detaljer). Dette hjælper med at differentiere officielle pakker, så babel-core bliver til @babel/core (og ingen squatting)
  • Fjern (og stop med at udgive) alle årlige forudindstillinger (preset-es2015, osv.) (detaljer). @babel/preset-env erstatter behovet for disse, da det omfatter alle årlige tilføjelser samt muligheden for at målrette et specifikt sæt browsere
  • Fald også bort med “Stage”-forindstillingerne (@babel/preset-stage-0 osv.) til fordel for valg af individuelle forslag. Ligeledes fjernes forslag fra @babel/polyfill som standard (detaljer). Overvej venligst at læse hele indlægget om dette for at få en nærmere forklaring.
  • Nogle pakker har fået nye navne: Ethvert plugin til TC39-forslag vil nu være -proposal i stedet for -transform (detaljer). Så @babel/plugin-transform-class-properties bliver til @babel/plugin-proposal-class-properties.
  • Indfører et peerDependency på @babel/core for visse brugervendte pakker (f.eks. babel-loader, @babel/cli osv.) (detaljer)

babel-upgrade

babel-upgrade er et nyt værktøj, som vi har startet, der forsøger at foretage automatiske opgraderingsændringer: i øjeblikket med afhængigheder i package.json og .babelrc config.

Vi anbefaler at køre det direkte på et git-repo med npx babel-upgrade, eller du kan installere det globalt med npm i babel-upgrade -g.

Hvis du ønsker at ændre filerne, kan du videregive --write samt --install.

npx babel-upgrade --write --install

Vis venligst at overveje at bidrage ved at rapportere problemer eller PR’er for at hjælpe alle med overgangen til Babel 7! Et håb for fremtiden er, at vi bruger dette samme værktøj til alle fremtidige brudændringer og opretter en bot til PR-projekter, der skal opdateres.

JavaScript-konfigurationsfiler

Vi introducerer babel.config.js. Det er ikke et krav eller endog en erstatning for .babelrc, men det kan være nyttigt at have dette i visse tilfælde.

*.js Konfigurationsfiler er ret almindelige i JavaScript-økosystemet. ESLint og Webpack giver begge mulighed for henholdsvis .eslintrc.js og webpack.config.js konfigurationsfiler.

Nedenfor er der et tilfælde, hvor der kun kompileres med et plugin i “produktion” (du kan allerede gøre dette med "env"-indstillingen i en .babelrc-fil):

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

babel.config.js har en anden konfigurationsopløsning end en .babelrc. Den vil altid opløse config’en fra denne fil i modsætning til oprindeligt, hvor Babel ville foretage et opslag fra hver fil og opefter, indtil den fandt en config. Dette gør det muligt at drage fordel af den næste funktion, der er offentliggjort nedenfor, overrides.

Selektiv konfiguration med overrides

For nylig offentliggjorde jeg et indlæg med tanker om både udgivelse af ES2015+-pakker og også forbrug/kompilering af dem.

Der er et afsnit, der går ind på brugen af en ny nøgle i Babels config kaldet overrides, som giver dig mulighed for at angive forskellige configs pr. glob.

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

Dette gør det muligt for et program, der kræver forskellige kompilerings-konfigurationer for sine tests, klientkode og serverkode, at springe over at skulle oprette en ny .babelrc-fil pr. mappe.

Hastighed 🏎

Babel selv er hurtigere, så det skulle tage mindre tid at bygge! Vi har foretaget en masse ændringer for at optimere koden samt acceptere patches fra v8-holdet. Vi er glade for at være en del af Web Tooling Benchmark sammen med mange andre gode JavaScript-værktøjer.

Output Options

Babel har understøttet forudindstillede og plugin-indstillinger i et stykke tid nu. For at opsummere kan du pakke plugin’et ind i et array og sende et optionsobjekt til plugin’et:

{ "plugins": , ]}

Vi har foretaget nogle ændringer i loose-indstillingen for nogle plugins og tilføjet nogle nye indstillinger for andre! Bemærk ved at bruge disse indstillinger vælger du en adfærd, der ikke er i overensstemmelse med specifikationerne, og du bør vide, hvad du gør; dette kan blive et problem, når du slår fra kompileringen for at bruge syntaksen nativt. Denne slags indstillinger bruges bedst i et bibliotek, hvis overhovedet.

  • For klasser vil class A {} nu ikke inkludere classCallCheck-hjælperen.
class A {}
var A = function A() {- _classCallCheck(this, A);};
  • Der er en ny indstilling, hvis hver brug af en for-of-loop kun er et 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 udelukker transform-typeof-symbol-plugin i loose-tilstand for #6831

Vi har fundet en masse biblioteker, der allerede gør dette, så vi besluttede at gøre dette som standard.

Bemærk, at standardadfærden er at være så spec-kompatibel som muligt, så det er problemfrit at slå Babel fra eller bruge preset-env i forhold til at tillade mindre output bare for at spare bytes (der er en afvejning der, som hvert projekt kan foretage). Vi planlægger at arbejde på bedre docs og værktøj for at gøre det nemmere.

“Ren” Annotation Support

Efter #6209 er transpilerede ES6-klasser annoteret med en /*#__PURE__*/-kommentar, der giver mulighed for at give et hint til minifiers som Uglify og babel-minify til eliminering af død kode. Disse annotationer tilføjes også til andre hjælpefunktioner. 

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

Der er måske flere muligheder for minifier-hints og optimeringer, lad os vide det!

Syntaks

TC39 Forslag Support

Jeg vil gerne gentage, at vi har fjernet Stage presets til fordel for en politik, hvor vi beder brugerne om udtrykkeligt at tilvælge forslag < Stage 4.

Bekymringen er, at vi automatisk tilvælger folk til syntaks, der ikke er fastsat eller udført med en forventning om, at den ikke vil ændre sig. Men det er ikke tilfældet, især ikke for forslag, der er Stage 0 eller 1. Dette indlæg forklarer lidt om den slags tankegang bag nyere idéer.

Her er en lille liste over nogle af de nye syntakser, som Babel understøtter (husk på, at dette funktionssæt er et bevægeligt mål, der kan blive tilføjet/fjernet/afbrudt), og hvilke der er blevet tilføjet i v7:

  • ES2018: Objekt Rest Spread (var a = { b, ...c })
  • ES2018 (ny): Unicode Property Regex
  • ES2018 (ny): (ny): JSON Superset
  • ES2015 (ny): JSON Superset
  • ES2015 (ny): new.target
  • Stage 3 (ny): new.target
  • Stage 3 (ny): Class Private Instance Fields (class A { #b = 2 })
  • Stage 3 (WIP): Statiske klassefelter, private statiske metoder (class A { static #a() {} })
  • Fase 3 (ny): Statiske klassefelter, private statiske metoder (class A { static #a() {} })
  • Fase 3 (ny): Valgfri Catch Binding try { throw 0 } catch { do() }
  • Strækning 3 (ny): BigInt (kun syntaks)
  • Fase 3: Dynamisk import (import("a"))
  • Fase 2 (ny): Dynamisk import (import("a"))
  • Fase 2 (ny): import.meta (kun syntaks) (import.meta.url)
  • Strin 2 (nyt): import.meta (kun syntaks) (import.meta.url)
  • Strin 2 (nyt): Numeriske separatorer (1_000)
  • Strin 2 (ny): (1_000)
  • Strin 2 (ny): function.sent
  • Fase 2: export-namespace-from (export * as ns from 'mod'), opdelt fra export-extensions
  • Fase 2: Dekorationselementer. Se nedenfor for en opdatering af vores fremskridt!
  • Stadie 1: export-default-from (export v from 'mod'), opdelt fra export-extensions
  • Stadie 1 (ny): export-extensions
  • (a?.b)
  • Stadie 1 (ny): Valgfri kæde (a?.b)
  • Stadie 1 (ny): Logiske tildelingsoperatorer (a &&= b; a ||= b)
  • Fase 1 (ny): Nullish Coalescing Operator (a ?? b)
  • Fase 1 (ny): Pipelineoperatør (a |> b)
  • Strækning 1 (ny): Throw Expressions (() => throw new Error("a"))

Det er svært for nogen at holde styr på alle forslagene, så vi forsøger at gøre det på babel/proposals.

TypeScript-understøttelse (@babel/preset-typescript)

Vi arbejdede sammen med TypeScript-holdet om at få Babel til at analysere/transformere typesyntaks med @babel/preset-typescript, i lighed med hvordan vi håndterer Flow med @babel/preset-flow.

For flere detaljer se dette indlæg fra TypeScript-holdet!

For (med typer):

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

Efter (typer fjernet):

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

Både Flow og Typescript er værktøjer, der gør det muligt for JavaScript-brugere at drage fordel af gradvis typning, og vi vil gerne aktivere begge dele i Babel. Vi planlægger fortsat at arbejde tæt sammen med begge deres respektive teams hos FB og Microsoft (ud over fællesskabet som helhed) for at opretholde kompatibilitet og understøtte nye funktioner.

Denne integration er ret ny, så det er muligt, at nogle syntakser ikke understøttes fuldt ud. Vi vil sætte pris på din hjælp med at rapportere problemer og måske sende en PR!

JSX Fragment Support (<>)

Som nævnt i React-bloggen har JSX Fragment support været tilgængelig fra beta.31.

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

Ændringer af Babel-hjælpere

Babel-upgrade-PR’en er i gang

@babel/runtime er blevet opdelt i @babel/runtime og @babel/runtime-corejs2 (PR). Førstnævnte indeholder kun Babels hjælpefunktioner og sidstnævnte indeholder dette samt eventuelle polyfill-funktioner (f.eks. Symbol, Promise).

Babel kan have behov for at injicere visse funktioner i den kode, der kan genbruges. Vi kalder bare disse “hjælpefunktioner” ligesom funktioner, der deles mellem moduler.

Et eksempel på dette er med kompilering af en class (uden loose-tilstand slået til):

Specifikationen siger, at du skal kalde en klasse med new Person(), men hvis den er kompileret til en funktion, kan du teknisk set bare bruge Person(), så vi inkluderer en køretidskontrol for dette.

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 og @babel/runtime (som en afhængighed) kan Babel udtrække de enkelte funktioner og blot kræve de modulære funktioner for at muliggøre mindre output på følgende måde: 

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

Det samme kan gøres med external-helpers og rollup-plugin-babel. Vi er ved at undersøge, om vi kan gøre dette automatisk i fremtiden. Hold øje med et selvstændigt indlæg om Babels hjælpere snart.

Automatisk polyfilling (eksperimentel)

Polyfills er nødvendige for at aktivere funktioner som Promise, Symbol i miljøer, som ikke har understøttelse for dem. Dette er vigtigt, når man skelner mellem hvad Babel gør som en compiler (transformerer syntaks) vs. en polyfill (implementerer indbyggede funktioner/objekter).

Det er nemt nok bare at importere noget, der dækker alt som @babel/polyfill:

import "@babel/polyfill";

Men det omfatter hele polyfill, og du behøver måske ikke at importere alt, hvis browsere allerede understøtter det. Dette er det samme problem, som @babel/preset-env forsøger at løse med syntaks, så vi anvender det her med polyfills. Indstillingen useBuiltins: "entry" gør dette ved at opdele den oprindelige import i kun de importer, der er nødvendige.

Men vi kan gøre det bedre ved kun at importere de polyfills, der bruges i kodebasen. Indstillingen "useBuiltIns: "usage" er vores første forsøg på at aktivere noget lignende (docs).

Den vil køre gennem hver fil og injicere en import øverst i hver fil, hvis den indbyggede er “brugt” i koden. For eksempel:

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

Inferencen er ikke perfekt, så der kan være falske positiver.

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

Andre ideer i dette rum er at bruge polyfill.io, hvis du er ok med at stole på en tjeneste (eller læs, hvordan Kent C. Dodds brugte det til at opbygge en hosted service hos PayPal).

Diverse

Babel Macros 🎣

En af de bedste dele af Babel er værktøjets tilslutningsmuligheder. I løbet af årene er Babel gået fra blot at være en “6to5”-kompiler til en platform til kodetransformation, hvilket muliggør nogle fantastiske optimeringer for både bruger- og udvikleroplevelsen. Tonsvis af Babel-plugins er blevet udviklet til specifikke biblioteker og use cases for at forbedre ydeevnen og mulighederne for bibliotekets API’er, som ellers ikke ville være muligt (nogle “biblioteker” er helt transpileret væk, hvilket resulterer i ingen runtime overhovedet).

Det kræver desværre at tilføje disse plugins til din kodebase at ændre konfigurationen (hvilket nogle toolkits som create-react-app ikke tillader), og det tilføjer kompleksitet til din kode, fordi udviklerne skal vide, hvilke Babel-plugins der opererer på en fil for at vide, hvad der vil ske med den kode, de skriver. Disse problemer er blevet løst med babel-plugin-macros af Kent C. Dodds!

Når babel-plugin-macros er blevet installeret og tilføjet til din config (det er inkluderet i create-react-app v2), behøver du ikke at bekymre dig om din konfiguration for at bruge nogen makroer. Derudover er det endnu nemmere at skrive dine egne brugerdefinerede transformationer til anvendelsestilfælde, der er specifikke for din app eller en del af din kode.

Læs mere om babel-plugin-macros i vores oprindelige indlæg “Zero-config code transformation with babel-plugin-macros”.

Module Targeting

Babel har altid forsøgt at afbalancere størrelsespåvirkningen af transformationer og de muligheder, de giver JavaScript-forfattere. I Babel 7 er det blevet meget nemmere at konfigurere Babel til at understøtte den voksende popularitet af modul/nomodul-mønstret.

Nærmere bestemt udnytter flere CLI-værktøjer til populære webframeworks (1, 2) allerede understøttelsen, hvilket fører til en reduktion på ca. 20 % af det afsendte JavaScript til forbrugere af applikationer, der er transponeret af Babel.

Caller Metadata og bedre standardindstillinger

Vi har tilføjet en caller indstilling til @babel/core, så vores værktøj kan videregive metadata til forudindstillinger/plugins. For eksempel: babel-loader kan tilføje noget som dette, så preset-env automatisk kan deaktivere modultransformationen (det samme med rollup:

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

Dette er spændende, da det muliggør en måde for værktøjet at levere bedre standardindstillinger og mindre konfiguration! For tilfældet webpack/rollup: Vi kan automatisk udskyde til at bruge deres modultransformation i stedet for Babels (det samme med import("a")). Hold øje med flere værktøjer til at drage fordel af dette i fremtiden!

class C extends HTMLElement {}

Et af vores ældste problemer får sin egen overskrift (detaljer)

Babel har altid haft det forbehold, at det ikke kunne understøtte udvidelse af native built-ins (Array, Error osv.), og det kan det nu! Vi har fået mange spørgsmål om dette; 🎉 du bør fejre det som Andrea!

Denne ændring blev foretaget i class-plugin’et, så det bør automatisk være aktiveret, hvis du bruger preset-env.

Ændringer på webstedet 🌏

Vi har flyttet vores websted fra Jekyll til Docusaurus!

Vi er stadig i gang med at opsætte oversættelser med Crowdin, og med Babel 7 ude, vil vi være bedre i stand til at starte den proces.

REPL

Vi har omskrevet REPL’en som en React-komponent og har arbejdet sammen med Ives om at integrere bedre med CodeSandbox. Dette giver dig mulighed for at installere ethvert plugin eller preset fra npm i REPL’en samt at få alle opdateringer, som CodeSandbox får.

Vi deltager igen i Rails Girls Summer of Code! Denne gang har Gyujin og Sujin arbejdet hårdt på at integrere Boopathis babel-time-travel i REPL’en, som du allerede kan teste nu!

Der er så mange muligheder her for at blive involveret i at få Babel, AST’er og andre værktøjer til at fungere bedre!

Vi har en sang 🎶

Hallelujah-In Praise of Babel

En dag gav Angus os nådigt en sang, som jeg syntes var fantastisk, så hvorfor ikke gøre den til vores “officielle” sang? Og Shawn lavede et genialt cover her.

Du kan finde den i vores repo på SONG.md. Vi håber at se andre projekter følge op på dette!

Hvad er det næste?

  • Babel er i sagens natur bundet til det, den kompilerer: JavaScript. Så længe der er nye tilføjelser at foreslå/arbejde på, er der arbejde at gøre der. Det inkluderer den tid/indsats der skal bruges på at implementere og vedligeholde syntaksen, selv før den bliver “stabil”. Vi bekymrer os om hele processen: opgraderingsvejen, undervisning i nye funktioner, undervisning i standarder/sprogdesign, brugervenlighed og integration med andre projekter.
    • Relateret: Vi er næsten færdige med at implementere det nye decorators-forslag i Babel takket være Nicolò. Det har været en lang rejse (det har taget mere end et år!), fordi det nye forslag er helt anderledes og meget mere kraftfuldt end det gamle, men det er næsten færdigt 🎉. Du kan forvente, at det vil blive frigivet i en af de næste mindre versioner sammen med et blogindlæg, som vil forklare ændringerne i detaljer.
  • Boopathi har flittigt vedligeholdt babel-minify, så vi vil lave en 1.0 for det næste!
  • Der er mange nye funktioner på vej: plugin-ordning, bedre validering/fejl, hastighed, nytænkning af løse/spec-indstillinger, caching, brug af Babel asynkront, opbygning mod sig selv fra CI, røgtests, kørsel af test262. Tjek dette roadmap-dokument for nogle flere mulige idéer!

Vi har ingen hemmelige planer: Vi prøver det bedste vi kan med det vi har for at tjene dette fællesskab.

Open Source is a Mirror

Jeg ville elske, hvis vi havde tid og ressourcer til at gennemføre alle disse idéer og gøre det godt. Men som vi har vist med denne aktuelle udgivelse, tager tingene meget længere tid end forventet!

Hvorfor tager disse udgivelser egentlig så lang tid? Er det på grund af feature creep, både fra os selv og vores brugere? Var det fordi vi ikke forstår hvordan vi skal prioritere blandt alle de mulige ting der skal tilføjes eller rettes? Beslutter at rette lavthængende frugter vs. fundamentale problemer til sidst? Eller “distraktioner” fra at hjælpe andre på GitHub, Slack, Twitter? Er vi bare dårlige til at vurdere vores tid, forstå kompleksiteten af disse problemer, og overforpligter vi os som frivillige?

Og stiller vi bare for høje forventninger til os selv, eller føler vi os presset af andre til at præstere og tilpasse os deres behov på bekostning af os selv? Jeg kan kun beskrive det som frygt, når jeg ser en besked fra en online, der undrer sig over, hvorfor noget ikke er blevet frigivet, mens en anden spørger, hvorfor denne fejl ikke er rettet endnu. Jeg har lyst til bare at haste det ud og være færdig med det, men jeg har også et ønske om at tage dette alvorligt.

Jeg har forsøgt at udtrykke nogle af disse tanker og kampe i mit foredrag i sidste uge på React Rally: Through the (Open Source) Looking Glass, som jeg håber, at du kan benytte dig af muligheden for at lytte til. Det spørgsmål, jeg stiller mig selv:

Som meget andet i livet afspejler de ting, vi gør, vores karakter og viser os, hvordan vi virkelig er. De handlinger, vi foretager, kan i sig selv ændre os, til det bedre eller værre. Hvis vi skal tage vores arbejde alvorligt, bør vi holde hinanden ansvarlige for disse vaner, der synes at være så indlejret i vores kultur: om øjeblikkelig tilfredsstillelse, succes i form af målinger, berettigelse i forhold til taknemmelighed og stolthed over at overarbejde.

Men på trods af alt dette har arbejdet hen imod denne udgivelse været det så meget værd.

Tak

Dette er virkelig en virkelig spændende udgivelse, ikke kun ved at se tilbage på, hvad vi har opnået og muliggjort, men meget mere bare ved at vide, hvor meget tid og hjerte der blev lagt i at få det til at ske i løbet af det sidste år. Det er svært at tro på de muligheder og oplevelser, der er sket undervejs: at interagere med og hjælpe virksomheder fra hele verden, at finde venner i næsten alle de byer, jeg har besøgt, og at tale ærligt om den utrolige rejse, som denne gruppe har taget op sammen.

Personligt har jeg aldrig rigtig lagt så meget af min mentale energi i noget af denne størrelsesorden, og jeg vil gerne takke så mange mennesker for at løfte os op undervejs. Shoutouts især til Logan Smyth, der har brugt utallige gange tid på at ændre så meget af, hvordan kernen fungerer og altid tager sig tid til at være så hjælpsom i vores Slack, mens han også arbejder freelance, og Brian Ng, der er trådt frem på en så stor måde for at fortsætte med at vedligeholde Babel samt gennemgå alle mine blogindlæg og foredrag. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo og Justin Ridgewell har alle bare været med til at gøre denne udgivelse mulig og behagelig at arbejde på.

Shoutout til alle de mange medlemmer af fællesskabet på Slack, Twitter og på tværs af alle projekterne på GitHub, som også skal forstå, hvad vi gør for deres egne brugere. Jeg vil gerne give en stor tak til mine venner på Behance/Adobe for at sponsorere mig i næsten et år for at arbejde på Babel på halv tid, før jeg besluttede mig for at gå på fuld tid (samt at hjælpe med at teste Babel 7 i produktion i hele den tid, jeg var der). Stor tak til alle vores sponsorer for vores Open Collective, især Trivago og Handshake. Og tak til vores venner og familie for al deres kærlighed og støtte.

Vi er alle temmelig trætte på dette tidspunkt, men det har virkelig været en ære og et privilegium at tjene på denne måde, så vi håber, at I sætter pris på udgivelsen!