Babel 7 megjelent

Majdnem 2 év, 4k commit, több mint 50 előzetes kiadás és rengeteg segítség után örömmel jelentjük be a Babel 7 kiadását. Majdnem 3 év telt el a Babel 6 kiadása óta! Rengeteg mozgó alkatrész van, ezért kérjük, legyetek elnézőek velünk a kiadás első heteiben. A Babel 7 egy hatalmas kiadás: gyorsabbá tettük, létrehoztunk egy frissítő eszközt, JS konfigurációkat, konfigurációs “felülírásokat”, több lehetőséget a méretre/minimalizálásra, JSX Fragments, TypeScript, új javaslatok és még sok más!

Ha értékeled a munkát, amit a Babelen végzünk, akkor szponzorálhatod a Babelt az Open Collective-on, támogathatsz engem a Patreon-on, vagy a munka részeként bevonhatod magad vagy a céged a Babelbe. Nagyra értékelnénk, ha a JavaScript közösségben kollektíven magunkénak éreznénk ezt a létfontosságú projektet!

Megtörténik! 🎉

A szoftver sosem lesz tökéletes, de készen állunk arra, hogy olyasmit szállítsunk, amit már egy ideje gyártásban használnak! @babel/core már 5,1 millió letöltés/hónapnál tart, mivel olyan eszközökben használják, mint a Next.js 6, vue-cli 3.0, React Native 0.56, és még a WordPress.com frontendje is 🙂!

Babel szerepe

Ezt a bejegyzést azzal szeretném kezdeni, hogy újra bemutatom a Babel szerepét a JavaScript ökoszisztémában az elmúlt néhány évben.

A kezdeti probléma az volt, hogy a szervernyelvekkel ellentétben nem lehetett garantálni, hogy minden felhasználó ugyanolyan támogatással rendelkezik a JavaScripthez, mivel a felhasználók különböző böngészőket használhattak különböző szintű támogatással (különösen az Internet Explorer régebbi verzióit). Ha a fejlesztők új szintaxist akartak használni (pl. class A {}), a régi böngészők felhasználói a SyntaxError miatt csak egy üres képernyőt kaptak.

A Babel lehetőséget adott a fejlesztőknek a legújabb JavaScript-szintaxis használatára, miközben lehetővé tette számukra, hogy ne kelljen azon aggódniuk, hogyan tegyék visszafelé kompatibilissé a felhasználók számára a fordítással (class A {} var A = function A() {}-re).

A JavaScript kód átalakítására való képessége miatt új funkciók megvalósítására is használható: így híd lett a TC39 (a JavaScript nyelvet specifikáló bizottság) számára, hogy visszajelzést kapjon a javasolt JavaScript-ötletekről, és hogy a közösség beleszólhasson a nyelv jövőjébe.

A Babel ma alapvető fontosságú a JavaScript fejlesztésében. Jelenleg több mint 1,3 millió függő repos van a GitHubon, havonta 17 millió letöltés az npm-en, és több száz felhasználó, köztük számos jelentős keretrendszer (React, Vue, Ember, Polymer) és vállalat (Facebook, Netflix, Airbnb). Olyannyira a JavaScript fejlesztés alapjává vált, hogy sokan nem is tudják, hogy használják. Még ha te magad nem is használod, nagy valószínűséggel a függőségeid a Babel-t használják.

A karbantartók emberek

A Babel óriási hatással van nemcsak magának a nyelvnek a jövőjére, hanem a közösségére és az ökoszisztémájára is. De még ennyi felelősség mellett is, a Babel csak egy közösség által irányított projekt, amelyet néhány önkéntes vezet.

A csapat néhány tagja csak az elmúlt évben találkozhatott először személyesen:

Az eredeti @babeljs csapat, végre együtt. Balról jobbra: @left_pad, @jamiebuilds, @sebmck, yours truly, and @loganfsmyth pic.twitter.com/XfPj6OhZfA

– Amjad Masad (@amasad) May 3, 2018

Amíg ez egy bejelentő poszt, szeretném megragadni az alkalmat, hogy mindenkit emlékeztessek a projekt állapotára.

Jómagam néhány hónappal a 6.0-s kiadás előtt csatlakoztam, ami a maga ellentmondásosságával és ellenérzéseivel járt. Az ottani fogadtatás nagy része a meglévő karbantartók kiégéséhez vezetett (beleértve Sebastiant, a Babel alkotóját is), és néhányan közülünk, akik megmaradtak, átvették a gyeplőt.

Mint sok karbantartó, mi is véletlenül botlottunk bele ebbe a szerepbe. Sokunknak nem volt semmilyen formális képzése arról, hogyan működnek a fordítók, vagy hogyan kell egy nyílt forráskódú projektet karbantartani. Ironikus módon, én még a főiskolán is szándékosan kerültem az informatika szakot, mert nem akartam fordítókról vagy bármi alacsony szintű dologról órákat venni, mert érdektelennek és nehéznek tűnt. Mégis vonzottak az eszközök, a linterek, a Babel és a JavaScript, mint nyelv.

Mindenkit arra szeretnék bátorítani, hogy nézzen utána azoknak a nyílt forráskódú projekteknek, amelyektől függ, és támogassa őket (mind idővel, mind pénzbeli támogatással, ha lehetséges).

Sok karbantartó nem eleve szakértője annak, amin dolgozik; és sok mindent el lehet érni azzal, ha először csak elkezdjük a munkát. Kíváncsisággal és alázattal fogsz hozzáfogni, mindkettő nagyszerű tulajdonság, ha karbantartó vagy. A vágyam a projekt víziójának reménye, szemben azzal, hogy mindannyian csak “feladatokat” végzünk.

A Babel nem egy vállalat, vagy egy nyílt forráskódú csapat egy olyan nagyvállalatnál, mint a Facebook. Csak egy maroknyi önkéntes dolgozik a Babelen, és csak néhány hónap telt el azóta, hogy megtettem a lépést, hogy otthagyjam a munkahelyemet, és eddig az egyetlen, aki teljes munkaidőben nyílt forráskóddal foglalkozik. De az emberek jönnek-mennek, életük van ezen a “hobbin” kívül is, családot alapítanak, más dolgokkal foglalkoznak, munkahelyet váltanak vagy munkát keresnek stb. Közösen megtesszük-e, amit tudunk, hogy fenntartsuk azokat a dolgokat, amelyek olyan alapvetőek a munkánk szempontjából, vagy hagyjuk, hogy az alapok lassan összeomoljanak? Hogyan tudjuk a nyílt forráskódot befogadó és befogadó, de világos határok között tartani? Tanulhatunk más karbantartók tapasztalataiból?

Noha a nyílt forráskód egyértelműen átvette a szoftverek irányítását, valóban egészséges állapotúnak tekinthetjük-e anélkül, hogy figyelembe vennénk a mögötte álló embereket?

#BabelSponsorsEverything

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

– Harry Wolff (@hswolff) August 17, 2018

A nyílt forráskód fenntarthatósága jelenleg olyan, mintha adománykosarat osztanánk. Nem nehéz kimondani, hogy a projektek milyen értéket nyújtanak a nyílt forráskódot használó emberek és cégek ezreinek, de mégsem látjuk, hogy ez az érték megmutatkozna azon kevesek számára, akik hajlandóak beletenni a munkát. Nagyon sokféleképpen lehet támogatni a nyílt forrást, és mégsem működik minden megközelítés minden projekt vagy ember számára.

Most térjünk rá a változásokra!!!

Major Breaking Changes

A migrációs útmutatóban dokumentáljuk ezeket. Sok ilyen változtatás automatikusan elvégezhető az új babel-upgrade eszközünkkel, vagy a jövőben hozzáadható.

• Elhagyjuk a nem karbantartott Node verziók támogatását: 0.10, 0.12, 4, 5 (részletek)
• A @babel névtérbe költözünk a “scoped” csomagok használatára való áttéréssel (részletek). Ez segít megkülönböztetni a hivatalos csomagokat, így a babel-core-ból @babel/core lesz (és nincs guggolás)
• Távolítsuk el (és hagyjuk abba az éves előbeállítások (preset-es2015, stb.) közzétételét) (részletek). A @babel/preset-env kiváltja ezek szükségességét, mivel tartalmazza az összes éves kiegészítést, valamint a böngészők egy meghatározott csoportjának megcélzását
• Elhagyja továbbá a “Stage” előbeállításokat (@babel/preset-stage-0, stb.) az egyéni javaslatok választása javára. Hasonlóképpen a @babel/polyfill javaslatok alapértelmezett eltávolítása (részletek). Kérjük, fontolja meg az ezzel kapcsolatos teljes bejegyzés elolvasását a további magyarázatért.
• Egyes csomagok átnevezése: bármelyik TC39 javaslati plugin mostantól -proposal lesz -transform helyett (részletek). Így a @babel/plugin-transform-class-properties-ból @babel/plugin-proposal-class-properties lesz.
• Egy peerDependency bevezetése a @babel/core-re bizonyos, a felhasználóval szemben álló csomagoknál (pl. babel-loader, @babel/cli, stb.) (részletek)

babel-upgrade

babel-upgrade egy új eszköz, amit elindítottunk, és amely megpróbálja automatikusan elvégezni a frissítési módosításokat: jelenleg a package.json és .babelrc config függőségekkel.

Azt javasoljuk, hogy futtasd közvetlenül egy git repón a npx babel-upgrade segítségével, vagy telepítheted globálisan a npm i babel-upgrade -g segítségével.

Ha módosítani szeretnéd a fájlokat, akkor a --write, valamint a --install átadhatod.

npx babel-upgrade --write --install

Kérlek, fontold meg a hozzájárulást problémák vagy PR-ok bejelentésével, hogy mindenki átállhasson a Babel 7-re! A jövőre nézve reméljük, hogy ugyanezt az eszközt használjuk minden jövőbeli törésváltoztatáshoz, és létrehozunk egy botot a PR-projektek frissítéséhez.

JavaScript konfigurációs fájlok

Elvezetjük a babel.config.js. Ez nem követelmény, és nem is helyettesíti a .babelrc-et, de ennek megléte bizonyos esetekben hasznos lehet.

*.js A konfigurációs fájlok meglehetősen gyakoriak a JavaScript ökoszisztémában. Az ESLint és a Webpack is lehetővé teszi a .eslintrc.js, illetve a webpack.config.js konfigurációs fájlok használatát.

Az alábbi esetben csak “production” állapotban fordíthatunk egy pluginnal (ezt már megtehetjük a .babelrc fájlban lévő "env" opcióval):

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

babel.config.js más konfigurációs felbontással rendelkezik, mint egy .babelrc. Mindig ebből a fájlból fogja feloldani a configot, szemben az eredetivel, amikor a Babel minden egyes fájlból felfelé keresett, amíg nem talált egy configot. Ez lehetővé teszi, hogy kihasználjuk az alább közzétett következő funkció, a overrides előnyeit.

Szelektív konfiguráció felülbírálatokkal

A közelmúltban közzétettem egy bejegyzést, amelyben mind az ES2015+ csomagok közzétételével, mind pedig azok fogyasztásával/fordításával kapcsolatos gondolataim vannak.

Van egy szakasz, amely a Babel configjában egy új, overrides nevű kulcs használatával foglalkozik, amely lehetővé teszi, hogy globonként különböző configokat adjunk meg.

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

Ez lehetővé teszi, hogy egy olyan alkalmazás, amely különböző fordítási konfigurációkat igényel a tesztjeihez, az ügyfélkódhoz és a szerverkódhoz, kihagyja, hogy mappánként egy új .babelrc fájlt kelljen létrehoznia.

Sebesség 🏎

A Babel maga gyorsabb, így kevesebb időt kell igénybe vennie az építésnek! Sok változtatást végeztünk a kód optimalizálása érdekében, valamint elfogadtuk a v8-as csapattól érkező javításokat. Örülünk, hogy a Web Tooling Benchmark része lehetünk sok más nagyszerű JavaScript eszköz mellett.

Output Options

A Babel már egy ideje támogatja a preset és plugin opciókat. Összefoglalva, a bővítményt egy tömbbe csomagolhatja, és átadhat egy opciók objektumot a bővítménynek:

{ "plugins": , ]}

Megváltoztattuk néhány bővítmény loose opcióját, és néhány új opciót adtunk hozzá másokhoz! Vedd figyelembe, hogy ezeknek az opcióknak a használatával a specifikációnak nem megfelelő viselkedést választod, és tudnod kell, hogy mit csinálsz; ez akkor válhat problémává, ha kikapcsolod a fordítást, hogy natívan használd a szintaxist. Az ilyen típusú opciókat legjobb könyvtárban használni, ha egyáltalán használod.

• Az osztályok esetében a class A {} mostantól nem tartalmazza a classCallCheck segédprogramot.

class A {}

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

• Új opció, ha a for-of ciklus minden használata csak egy tömb:

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

• Kizárjuk a transform-typeof-symbol bővítményt loose módban a preset-env #6831

Egy csomó könyvtárban találtunk már ilyet, ezért úgy döntöttünk, hogy alapértelmezetten ezt csináljuk.

Megjegyezzük, hogy az alapértelmezett viselkedés a lehető legjobban megfelel a specifikációnak, hogy a Babel kikapcsolása vagy a preset-env használata zökkenőmentes legyen, szemben a kisebb kimenet engedélyezésével csak azért, hogy bájtokat takarítsunk meg (ez egy kompromisszum, amit minden projekt megtehet). Tervezzük, hogy jobb dokumentáción és eszközökön dolgozunk, hogy ezt megkönnyítsük.

“Pure” Annotation Support

A #6209 után az átfordított ES6 osztályok egy /*#__PURE__*/ megjegyzéssel vannak ellátva, ami lehetővé teszi, hogy a Uglify és babel-minify típusú minifikátoroknak adjon egy tippet a halott kód eltávolítására. Ezek a megjegyzések más segédfüggvényekhez is hozzáadódnak.

class C { m() {}}

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

Elképzelhető, hogy még több lehetőség van a bontókra vonatkozó tippekre és optimalizálásokra, szóljon nekünk!

Szintaxis

TC39 javaslatok támogatása

Megismételném, hogy eltávolítottuk a Stage előbeállításokat egy olyan politika javára, amely arra kéri a felhasználókat, hogy kifejezetten jelentkezzenek be a javaslatok < Stage 4.

Az az aggodalom, hogy automatikusan olyan szintaxisra jelentkeznek az emberek, ami nincs rögzítve, vagy azzal az elvárással történik, hogy az nem fog változni. De ez nem így van, különösen a 0. vagy 1. fázisú javaslatok esetében. Ez a bejegyzés egy kicsit elmagyarázza, hogy milyen gondolkodás áll az újabb ötletek mögött.

Itt van egy kis felsorolás néhány új szintaxisról, amit a Babel támogat (ne feledjük, hogy ez a funkciókészlet egy mozgó célpont, ami hozzáadható/eltávolítható/megszüntethető), és hogy melyiket adtuk hozzá a v7-ben:

• ES2018:
• ES2018 (új): Object Rest Spread (var a = { b, ...c })
• ES2018 (új):
• ES2018 (új): Unicode Property Regex
• ES2018 (új): JSON Superset
• ES2015 (új): JSON Superset
• ES2015 (új): (új): new.target
• SESES 3 (új): (class A { #b = 2 })
• 3. szakasz (WIP): Class Private Instance Fields (class A { #b = 2 })
• 3. szakasz (WIP): Class Private Instance Fields (class A { #b = 2 }): (class A { static #a() {} })
• 3. szakasz (új): Statikus osztálymezők, privát statikus metódusok (class A { static #a() {} })
• 3. szakasz (új): try { throw 0 } catch { do() }
• 3. szakasz (új): Választható Catch Binding try { throw 0 } catch { do() }
• 3. szakasz (új): (új): BigInt (csak szintaxis)
• 3. szakasz: Dinamikus importálás (import("a"))
• 2. szakasz (új): (import.meta.url)
• 2. szakasz (új): import.meta (csak szintaxis) (import.meta.url)
• 2. szakasz (új): (
• 2. szakasz (új): Numerikus elválasztójelek (1_000)
• 2. szakasz (új): function.sent
• 2. szakasz: export-namespace-from (export * as ns from 'mod'), osztva a export-extensions
• 2. szakasz: Díszítők. Az alábbiakban tájékozódhatsz az előrehaladásunkról!
• Stage 1: export-default-from (export v from 'mod'), osztva: export-extensions
• 1. szakasz (új):
• 1. szakasz (új): Választható láncolás (a?.b)
• 1. szakasz (új): (a &&= b; a ||= b)
• 1. szakasz (új): Logikai hozzárendelési operátorok (a &&= b; a ||= b)
• 1. szakasz (új): (a ?? b)
• 1. szakasz (új): (a |> b)
• 1. szakasz (új): Throw Expressions (() => throw new Error("a"))

Nehéz bárkinek is nyomon követni az összes javaslatot, ezért ezt a babel/proposals oldalon próbáljuk megtenni.

TypeScript támogatás (@babel/preset-typescript)

A TypeScript csapattal azon dolgoztunk, hogy a Babel a @babel/preset-typescript segítségével elemezze/átalakítsa a típusszintaxist, hasonlóan ahhoz, ahogy a Flow-t a @babel/preset-flow segítségével kezeljük.

További részletekért nézd meg ezt a bejegyzést a TypeScript csapattól!

Előbb (típusokkal):

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

Azután (típusok eltávolítása):

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

A Flow és a Typescript is olyan eszközök, amelyek lehetővé teszik a JavaScript felhasználók számára a fokozatos tipizálás előnyeinek kihasználását, és szeretnénk mindkettőt engedélyezni a Babelben. Tervezzük, hogy továbbra is szorosan együttműködünk mindkettőjük FB és Microsoft csapatával (a teljes közösségen kívül) a kompatibilitás fenntartása és az új funkciók támogatása érdekében.

Ez az integráció meglehetősen új, így lehetséges, hogy egyes szintaxisok nem támogatottak teljes mértékben. Nagyra értékelnénk a segítségét a problémák jelentésében és esetleg egy PR küldésében!

JSX Fragment támogatás (<>)

Amint azt a React Blogban említettük, a JSX Fragment támogatás beta.31 óta elérhető.

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

Babel Helpers Changes

A babel-upgrade PR folyamatban van

@babel/runtime felosztásra került @babel/runtime és @babel/runtime-corejs2 (PR). Az előbbi csak a Babel segédfüggvényeit tartalmazza, az utóbbi pedig azt, valamint minden polyfill függvényt (pl. Symbol, Promise).

A Babelnek szüksége lehet bizonyos függvények befecskendezésére a kódba, amelyek újra felhasználhatók. Ezeket egyszerűen “segédfüggvényeknek” nevezzük, akárcsak a modulok között megosztott függvényeket.

Egy példa erre a class fordítása (bekapcsolt loose mód nélkül):

A specifikáció azt mondja, hogy egy osztályt new Person()-vel kell meghívni, de ha ez egy függvénybe van fordítva, akkor technikailag egyszerűen csak Person()-t tehetünk, ezért tartalmazunk egy futásidejű ellenőrzést erre vonatkozóan.

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

A @babel/plugin-transform-runtime és @babel/runtime (mint függőség) esetén a Babel ki tudja vonni az egyes függvényeket, és csak a moduláris függvényeket kéri a kisebb kimenet lehetővé tételéhez, így:

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

Az external-helpers és rollup-plugin-babel esetén ugyanezt lehet tenni. Megvizsgáljuk, hogy a jövőben ezt automatikusan meg tudjuk-e tenni. Hamarosan várunk egy önálló bejegyzést a Babel segítőiről.

Automatikus polikitöltés (kísérleti)

A polikitöltés szükséges az olyan funkciók engedélyezéséhez, mint a Promise, Symbol olyan környezetekben, amelyek nem támogatják ezeket. Ez fontos, amikor különbséget teszünk aközött, amit a Babel fordítóként csinál (átalakítja a szintaxist) vs. a polyfill (beépített függvényeket/objektumokat valósít meg).

Elég egyszerű csak importálni valamit, ami mindent lefed, mint @babel/polyfill:

import "@babel/polyfill";

De ez tartalmazza a teljes polyfillt, és lehet, hogy nem kell mindent importálni, ha a böngészők már támogatják. Ez ugyanaz a probléma, amit a @babel/preset-env a szintaxissal próbál megoldani, ezért itt a polyfillekkel alkalmazzuk. A useBuiltins: "entry" opció ezt úgy éri el, hogy az eredeti importot csak a szükséges importokra bontja.

De jobban járunk, ha csak a kódbázisban használt polyfilleket importáljuk. A "useBuiltIns: "usage" opció az első kísérletünk arra, hogy valami ilyesmit engedélyezzünk (docs).

Ez végigfut minden egyes fájlon, és minden fájl elejére befecskendez egy importot, ha az adott built-in “használatos” a kódban. Például:

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

A következtetés nem tökéletes, így előfordulhatnak hamis pozitív eredmények.

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

Egy másik ötlet ezen a téren a polyfill.io használata, ha nem gond, hogy egy szolgáltatásra támaszkodik (vagy olvassa el, hogy Kent C. Dodds használta a PayPal-nál egy hosztolt szolgáltatás létrehozására).

Egyéb

Babel makrók 🎣

A Babel egyik legjobb része az eszköz bővíthetősége. Az évek során a Babel egy egyszerű “6to5” fordítóból egy kódtranszformációs platformmá vált, ami lehetővé tett néhány fantasztikus optimalizálást mind a felhasználói, mind a fejlesztői élmény szempontjából. Több tonna Babel plugint fejlesztettek ki speciális könyvtárakhoz és felhasználási esetekhez, hogy javítsák a teljesítményt és a könyvtári API-k képességeit, ami egyébként nem lenne lehetséges (néhány “könyvtár” teljesen el van fordítva, ami egyáltalán nem eredményez futási időt).

Sajnos, ezeknek a plugineknek a kódbázishoz való hozzáadása a konfiguráció megváltoztatását igényli (amit néhány eszközkészlet, például a create-react-app nem tesz lehetővé), és ez növeli a kód összetettségét, mivel a fejlesztőknek tudniuk kell, hogy milyen Babel pluginek működnek egy fájlon, hogy tudják, mi fog történni a kóddal, amit írnak. Ezeket a problémákat oldotta meg a Kent C. Dodds által készített babel-plugin-macros!

Amint a babel-plugin-macros telepítve és hozzáadva a konfigurációdhoz (a create-react-app v2 tartalmazza), nem kell a konfigurációddal bajlódnod ahhoz, hogy makrókat használj. Ráadásul még egyszerűbb saját egyedi transzformációkat írni az alkalmazásodra vagy a kódod egy részére jellemző felhasználási esetekhez.

A babel-plugin-macros-ről többet megtudhatsz az eredeti bejegyzésünkben “Zeroconfig code transformation with babel-plugin-macros”.

Module Targeting

A Babel mindig is igyekezett egyensúlyt teremteni a transzformációk méretre gyakorolt hatása és az általuk a JavaScript szerzőknek nyújtott lehetőségek között. A Babel 7-ben sokkal könnyebbé vált a Babel konfigurálása a modul/nomodul minta növekvő népszerűségének támogatására.

Megjegyzendő, hogy számos CLI eszköz a népszerű webes keretrendszerekhez (1, 2) már kihasználja a támogatást, ami a Babel által átfordított alkalmazások fogyasztóinak szállított JavaScript nagyjából 20%-os csökkenéséhez vezet.

Hívó metaadatok és jobb alapértelmezések

Egy caller opciót adtunk a @babel/core-hez, így az eszközeink képesek metaadatokat átadni a preset/pluginoknak. Például: babel-loader hozzáadhat valami ilyesmit, így a preset-env automatikusan letilthatja a modul átalakítását (ugyanez a rollup:

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

Ez izgalmas, mivel lehetővé teszi, hogy a tooling jobb alapértelmezéseket és kevesebb konfigurációt biztosítson! A webpack/rollup esetében: automatikusan átállhatunk arra, hogy az ő modul transzformációjukat használjuk a Babelé helyett (ugyanez a import("a")-val). Vigyázzunk, hogy a jövőben több tooling is kihasználja ennek előnyeit!

class C extends HTMLElement {}

Az egyik legrégebbi problémánk saját címet kap (részletek)

A Babelnek mindig is volt az a kikötése, hogy nem tudta támogatni a natív beépített modulok kiterjesztését (Array, Error, stb.), de most már tudja! Rengeteg problémát kaptunk ezzel kapcsolatban; 🎉 ünnepelni kell, mint Andrea!

Ez a változás a class pluginban történt, így automatikusan engedélyezve kell lennie, ha a preset-env-t használod.

Weboldal változások 🌏

A weboldalunkat a Jekyllről a Docusaurusra költöztettük!

Még folyamatban van a fordítások beállítása a Crowdin segítségével, és a Babel 7 megjelenésével jobb helyzetben leszünk, hogy elkezdjük ezt a folyamatot.

REPL

Újraírtuk a REPL-t React komponensként, és Ives-szel azon dolgozunk, hogy jobban integráljuk a CodeSandbox-szal. Ez lehetővé teszi, hogy bármilyen plugint vagy előbeállítást telepíthess az npm-ből a REPL-be, valamint hogy megkapj minden frissítést, amit a CodeSandbox kap.

Újra részt veszünk a Rails Girls Summer of Code-ban! Ezúttal Gyujin és Sujin keményen dolgozott azon, hogy Boopathi babel-time-traveljét integráljuk a REPL-be, amit már most tesztelhetsz!

Ez itt nagyon sok lehetőség van arra, hogy részt vegyél a Babel, az AST és más eszközök jobb működésében!

Van egy dalunk 🎶

Halleluja-In Praise of Babel

Egy nap Angus kegyesen átadott nekünk egy dalt, amit csodálatosnak találtam, miért ne lehetne a “hivatalos” dalunk? És Shawn itt egy zseniális feldolgozást készített.

Ezt megtaláljátok a repónkban a SONG.md címen. Reméljük, hogy más projektek is követni fogják ezt!

What’s Next?

• A Babel eredendően ahhoz kötődik, amit összeállít: JavaScript. Amíg új kiegészítéseket lehet javasolni/dolgozni rajta, addig van mit tenni. Ez magában foglalja a szintaxis implementálására és karbantartására fordított időt/fáradságot még azelőtt, hogy “stabil” lenne. Törődünk az egész folyamattal: a frissítési útvonallal, az új funkciók oktatásával, a szabványok/nyelvtervezés tanításával, a könnyű használhatósággal és a más projektekkel való integrációval.
  • Hoz kapcsolódóan: Nicolònak köszönhetően majdnem befejeztük az új dekorátor javaslat megvalósítását a Babelben. Hosszú volt az út (több mint egy évig tartott!), mert az új javaslat teljesen más és sokkal erősebb, mint a régi, de már majdnem kész 🎉. Várhatóan a következő minor verziók egyikében fog megjelenni, egy blogbejegyzéssel együtt, ami részletesen elmagyarázza a változásokat.
• Boopathi szorgalmasan karbantartja a babel-minify-t, így legközelebb egy 1.0-t fogunk készíteni hozzá!
• Egy csomó újdonság van készülőben: plugin rendezés, jobb validáció/hibák, sebesség, loose/spec opciók újragondolása, caching, Babel aszinkron használata, építés saját maga ellen CI-ből, füsttesztek, test262 futtatása. Nézd meg ezt az útiterv-dokumentumot néhány további lehetséges ötletért!

Nincsenek titkos terveink: megpróbáljuk a legjobbat kihozni abból, amink van, hogy szolgáljuk ezt a közösséget.

Open Source is a Mirror

Szeretném, ha lenne időnk és erőforrásunk, hogy mindezeket az ötleteket megvalósítsuk, és jól csináljuk. De ahogy a mostani kiadással megmutattuk, a dolgok sokkal tovább tartanak a vártnál!

Miért tartanak ezek a kiadások egyáltalán ilyen sokáig? Ez a feature creep miatt van, mind a saját magunk, mind a felhasználóink részéről? Azért, mert nem értjük, hogyan állítsunk fel fontossági sorrendet az összes lehetséges hozzáadandó vagy javítandó dolog között? Az alacsonyan lógó gyümölcsök helyett az alapvető problémák kijavítása mellett döntöttünk a végéig? Vagy a GitHubon, Slacken, Twitteren mások segítésével kapcsolatos “figyelemelterelés”? Csak rosszul becsüljük meg az időnket, nem értjük meg a problémák összetettségét, túlságosan elkötelezzük magunkat önkéntesként?

Vagy csak túl magas elvárásokat támasztunk magunkkal szemben, vagy úgy érezzük, hogy mások nyomást gyakorolnak ránk, hogy teljesítsünk és megfeleljünk az ő igényeiknek a saját kárunkra? Csak úgy tudom leírni, hogy rettegek, amikor látok egy üzenetet valakitől online, aki csodálkozik, hogy miért nem adtak ki valamit, míg egy másik azt kérdezi, hogy miért nincs ez a hiba még kijavítva. Legszívesebben csak elsietném, és végeznék vele, de van bennem egy olyan vágy is, hogy ezt komolyan vegyem.

Ezeknek a gondolatoknak és küzdelmeknek egy részét megpróbáltam kifejezni a múlt heti előadásomban a React Rallyn: Through the (Open Source) Looking Glass, amit remélem, hogy megragadjátok a lehetőséget, hogy meghallgassátok. A kérdés, amit felteszek magamnak: Mit tehetek a karbantartói kiégés, az állandó szorongás és az irreális elvárások elkerülhetetlen körforgása ellen?

Mint az élet nagy része, a dolgok, amiket teszünk, tükrözik a jellemünket, és megmutatják, milyenek vagyunk valójában. A cselekedeteink önmagukban is megváltoztathatnak minket, jobbra vagy rosszabbra. Ha komolyan akarjuk venni a munkánkat, számon kell tartanunk egymást ezeken a szokásokon, amelyek annyira beágyazódni látszanak a kultúránkba: az azonnali kielégülés, a mérőszámok szerinti siker, a jogosultság kontra hála, és a túlhajszoltság büszkesége.

De mindezek ellenére annyira megérte dolgozni ezért a kiadásért.

Köszönöm

Ez egy igazán izgalmas kiadás, nem csak azáltal, hogy visszatekintünk arra, amit elértünk és lehetővé tettünk, hanem sokkal inkább azzal, hogy tudjuk, mennyi időt és szívet fektettünk a megvalósításába az elmúlt évben. Nehéz elhinni, milyen lehetőségek és élmények adódtak az út során: a világ minden tájáról érkező cégekkel való interakció és segítségnyújtás, barátokra találás szinte minden városban, ahol megfordultam, és őszintén beszélni arról a hihetetlen utazásról, amit ez a csoport együtt tett meg.

Személyesen még soha nem fektettem ennyi mentális energiát ilyen nagyságrendű dologba, és szeretnék köszönetet mondani sok embernek, hogy felemeltek minket az út során. Shoutouts különösen Logan Smyth, aki számtalan időt töltött, hogy megváltoztassa annyi mindent, hogyan működik a mag, és mindig vesz időt, hogy annyira hasznos legyen a Slack, miközben szabadúszóként is dolgozik, és Brian Ng, aki lépett fel olyan nagy módon, hogy továbbra is fenntartja a Babel, valamint felülvizsgálja az összes blogbejegyzést és beszélgetéseket. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo és Justin Ridgewell mindannyian csak hozzájárultak ahhoz, hogy ez a kiadás lehetővé vált és élvezetes volt rajta dolgozni.

Shoutout to all the many community members on Slack, Twitter, and across all the projects on GitHub that also have to understand what we are doing for their own users. Szeretnék hatalmas köszönetet mondani a Behance/Adobe barátaimnak, hogy majdnem egy évig szponzoráltak, hogy félállásban dolgozhassak a Babelen, mielőtt úgy döntöttem, hogy teljes munkaidőben dolgozom (valamint hogy végig segítettek tesztelni a Babel 7-et a termelésben, amíg ott voltam). Nagy köszönet a Nyílt Kollektívánk minden szponzorának, különösen a Trivagónak és a Handshake-nek. És köszönet a barátainknak és a családunknak a szeretetükért és támogatásukért.

Mindannyian elég fáradtak vagyunk ezen a ponton, de valóban megtiszteltetés és kiváltság volt ilyen módon szolgálni, így reméljük, hogy értékelitek a kiadást!