Babel 7 wydany

BY admin
|

Po prawie 2 latach, 4k commitów, ponad 50 przedpremierowych wydań i ogromnej pomocy jesteśmy podekscytowani mogąc ogłosić wydanie Babel 7. Minęły prawie 3 lata od wydania Babel 6! Jest wiele ruchomych części więc prosimy o wyrozumiałość w pierwszych tygodniach po wydaniu. Babel 7 jest ogromnym wydaniem: przyspieszyliśmy go, stworzyliśmy narzędzie do aktualizacji, konfiguracje JS, „nadpisania” konfiguracji, więcej opcji dla rozmiaru/minifikacji, Fragmenty JSX, TypeScript, nowe propozycje i wiele więcej!

Jeśli doceniasz pracę jaką wykonujemy nad Babel, możesz sponsorować Babel na Open Collective, wesprzeć mnie na Patreon, lub zaangażować siebie lub swoją firmę w Babel jako część pracy. Będziemy wdzięczni za zbiorowe posiadanie tego ważnego projektu w społeczności JavaScript!

It’s Happening! 🎉

Software nigdy nie będzie doskonały, ale jesteśmy gotowi do wysłania czegoś, co jest już używane w produkcji od jakiegoś czasu! @babel/core jest już na poziomie 5.1 miliona pobrań/miesiąc dzięki użyciu w narzędziach takich jak Next.js 6, vue-cli 3.0, React Native 0.56, a nawet we frontendzie WordPress.com 🙂!

Rola Babel

Chciałbym zacząć ten post od ponownego przedstawienia roli Babel w ekosystemie JavaScript w ciągu ostatnich kilku lat.

Początkowym problemem było to, że w przeciwieństwie do języków serwera, nie było sposobu by zagwarantować, że każdy użytkownik ma takie samo wsparcie dla JavaScript, ponieważ użytkownicy mogli używać różnych przeglądarek z różnym poziomem wsparcia (szczególnie starszych wersji Internet Explorera). Jeśli programiści chcieli użyć nowej składni (np. class A {}), użytkownicy na starych przeglądarkach po prostu dostaliby pusty ekran z powodu SyntaxError.

Babel zapewnił sposób dla programistów na użycie najnowszej składni JavaScript, pozwalając im nie martwić się o to, jak uczynić ją kompatybilną wstecz dla swoich użytkowników poprzez jej przetłumaczenie (class A {} na var A = function A() {}).

Przez swoją zdolność do przekształcania kodu JavaScript, może być również używany do implementacji nowych funkcji: w ten sposób stał się pomostem pomagającym TC39 (komitet, który określa język JavaScript) uzyskać informacje zwrotne na temat proponowanych pomysłów JavaScript i dla społeczności, aby mieć wpływ na przyszłość języka.

Babel jest fundamentalny dla rozwoju JavaScript dzisiaj. Obecnie istnieje ponad 1.3 miliona zależnych repozytoriów na GitHub, 17 milionów pobrań na npm miesięcznie, oraz setki użytkowników, w tym wiele głównych frameworków (React, Vue, Ember, Polymer), oraz firm (Facebook, Netflix, Airbnb). Stał się on takim fundamentem dla rozwoju JavaScript, że wiele osób nawet nie wie, że jest używany. Nawet jeśli sami go nie używacie, jest bardzo prawdopodobne, że wasze zależności używają Babel.

Maintainerzy to ludzie

Babel ma ogromny wpływ nie tylko na przyszłość samego języka, ale także jego społeczności i ekosystemu. Ale nawet z całą tą odpowiedzialnością, Babel jest tylko projektem prowadzonym przez społeczność przez kilku wolontariuszy.

Tylko w tym ostatnim roku niektórzy z zespołu mogli się spotkać po raz pierwszy osobiście:

Oryginalny zespół @babeljs, w końcu razem. Od lewej do prawej: @left_pad, @jamiebuilds, @sebmck, yours truly, and @loganfsmyth pic.twitter.com/XfPj6OhZfA

– Amjad Masad (@amasad) May 3, 2018

As much as this is an announcement post, I’d like to take the opportunity to remind everyone of the state of this project.

Ja sam dołączyłem kilka miesięcy przed wydaniem 6.0, które miało swoją własną ilość kontrowersji i backlash. Duża część odbioru doprowadziła do wypalenia się opiekunów (w tym Sebastiana, twórcy Babela) i kilku z nas, którzy pozostali, przejęło stery.

Jak wielu opiekunów, przypadkowo natknęliśmy się na tę rolę. Wielu z nas nie miało żadnego formalnego przeszkolenia na temat działania kompilatorów ani tego, jak utrzymywać projekt open source. Jak na ironię, nawet celowo unikałem kierunku informatyka na studiach, ponieważ nie chciałem brać udziału w zajęciach z kompilatorów lub czegokolwiek innego na niskim poziomie, ponieważ wydawało mi się to nieciekawe i trudne. Jednak znalazłem się przyciągnięty do narzędzi, linterów, Babel i JavaScript jako języka.

Chciałbym zachęcić wszystkich do przyjrzenia się projektom open source, od których jesteście zależni i do wspierania ich (zarówno poprzez czas jak i wsparcie finansowe, jeśli to możliwe).

Wielu opiekunów nie jest z natury ekspertami w rzeczach, nad którymi pracują; i jest wiele do osiągnięcia od rozpoczęcia pracy jako pierwsi. Będziesz miał zarówno ciekawość, jak i pokorę, które są wspaniałymi atrybutami opiekuna. Moim pragnieniem jest nadzieja na wizję projektu, w przeciwieństwie do nas wszystkich wykonujących „zadania”.

Babel nie jest firmą, ani zespołem open source w dużej firmie, takiej jak Facebook. Jest tylko garstka wolontariuszy pracujących nad Babel, a minęło tylko kilka miesięcy odkąd zdecydowałem się opuścić moją pracę i być jedynym jak dotąd, który pracuje nad open source w pełnym wymiarze godzin. Ale ludzie mogą przychodzić i odchodzić, mieć życie poza tym „hobby”, zakładać rodziny, przechodzić do innych rzeczy, zmieniać pracę lub jej szukać, itd. Czy wspólnie robimy co możemy by podtrzymać to co jest tak fundamentalne dla naszej pracy, czy pozwolimy by fundamenty powoli się rozpadały? Jak utrzymać otwarte źródło jako przyjazne i włączające, ale z jasnymi granicami? Czy możemy uczyć się z doświadczeń innych opiekunów?

Choć Open Source wyraźnie zawładnęło oprogramowaniem, czy naprawdę możemy uznać, że jest ono w zdrowym stanie, nie biorąc pod uwagę ludzi, którzy za nim stoją?

#BabelSponsorsEverything

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

– Harry Wolff (@hswolff) August 17, 2018

Open Source sustainability feels like giving giving out a offering basket at the moment. Nie jest trudno określić wartość, jaką projekty dostarczają tysiącom ludzi i firm korzystających z open source, ale mimo to nie widzimy, by ta wartość była pokazywana tym nielicznym, którzy są gotowi włożyć w to pracę. Może być tak wiele sposobów wspierania open source, a jednak nie wszystkie podejścia działają dla każdego projektu lub ludzi.

Teraz przejdźmy do zmian!!!

Główne zmiany

Dokumentujemy je w naszym Przewodniku Migracji. Wiele z tych zmian można wykonać automatycznie za pomocą naszego nowego babel-upgrade narzędzia, lub można je dodać w przyszłości.

  • Odrzuć wsparcie dla nieutrzymywanych wersji Node: 0.10, 0.12, 4, 5 (szczegóły)
  • Przeniesienie nas do przestrzeni nazw @babel poprzez przejście na używanie pakietów „scoped” (szczegóły). To pomaga odróżnić oficjalne pakiety, więc babel-core staje się @babel/core (i nie ma przysiadów)
  • Usuń (i przestań publikować) wszelkie roczne ustawienia wstępne (preset-es2015, itp.) (szczegóły). @babel/preset-env zastępuje potrzebę ich stosowania, ponieważ zawiera wszystkie coroczne dodatki, jak również możliwość kierowania na określony zestaw przeglądarek
  • Porzuć również presety „Etapowe” (@babel/preset-stage-0, itd.) na korzyść wyboru poszczególnych propozycji. Podobnie usuń domyślnie propozycje z @babel/polyfill (szczegóły). Proszę rozważyć przeczytanie całego postu na ten temat, aby uzyskać więcej wyjaśnień.
  • Niektóre pakiety zmieniły nazwy: każda wtyczka propozycji TC39 będzie teraz -proposal zamiast -transform (szczegóły). Tak więc @babel/plugin-transform-class-properties staje się @babel/plugin-proposal-class-properties.
  • Wprowadzono peerDependency na @babel/core dla niektórych pakietów skierowanych do użytkownika (np. babel-loader, @babel/cli, itd.) (szczegóły)

babel-upgrade

babel-upgrade jest nowym narzędziem, które uruchomiliśmy, które próbuje automatycznie wprowadzać zmiany aktualizacji: obecnie z zależnościami w package.json i .babelrc config.

Zalecamy uruchomienie go bezpośrednio na git repo za pomocą npx babel-upgrade, lub możesz zainstalować go globalnie za pomocą npm i babel-upgrade -g.

Jeśli chcesz zmodyfikować pliki, możesz przekazać --write jak również --install.

npx babel-upgrade --write --install

Proszę rozważyć wniesienie wkładu poprzez zgłaszanie problemów lub PR, aby pomóc wszystkim przejść na Babel 7! Mamy nadzieję, że w przyszłości użyjemy tego samego narzędzia dla wszystkich przyszłych zmian i stworzymy bota do PR-owania projektów do aktualizacji.

Pliki konfiguracyjne JavaScript

Wprowadzamy babel.config.js. Nie jest to wymóg ani nawet zamiennik dla .babelrc, ale posiadanie tego może być przydatne w niektórych przypadkach.

*.jspliki konfiguracyjne są dość powszechne w ekosystemie JavaScript. ESLint i Webpack pozwalają na pliki konfiguracyjne .eslintrc.js i webpack.config.js, odpowiednio.

Poniżej znajduje się przypadek kompilacji tylko z wtyczką w „produkcji” (możesz to zrobić już z opcją "env" w pliku .babelrc):

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

babel.config.js ma inną rozdzielczość config niż .babelrc. Zawsze będzie rozwiązywał config z tego pliku, w przeciwieństwie do pierwotnej sytuacji, gdy Babel wykonywałby lookup od każdego pliku w górę aż do znalezienia configu. Umożliwia to skorzystanie z następnej funkcji umieszczonej poniżej, overrides.

Konfiguracja selektywna z nadpisywaniem

Ostatnio opublikowałem post z przemyśleniami na temat zarówno publikowania pakietów ES2015+ jak i ich konsumowania/kompilowania.

Jest tam sekcja, która przechodzi do używania nowego klucza w Babel’s config zwanego overrides, który pozwala na określenie różnych konfiguracji na glob.

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

To pozwala aplikacji, która wymaga różnych konfiguracji kompilacji dla swoich testów, kodu klienta i kodu serwera, pominąć potrzebę tworzenia nowego pliku .babelrc dla każdego folderu.

Szybkość 🏎

Babel sam w sobie jest szybszy, więc jego budowa powinna zająć mniej czasu! Wprowadziliśmy wiele zmian, aby zoptymalizować kod, jak również zaakceptować poprawki od zespołu v8. Cieszymy się, że możemy być częścią Web Tooling Benchmark obok wielu innych wspaniałych narzędzi JavaScript.

Opcje wyjściowe

Babel wspiera opcje presetów i pluginów już od jakiegoś czasu. Aby podsumować, możesz zawinąć wtyczkę w tablicę i przekazać obiekt opcji do wtyczki:

{ "plugins": , ]}

Zrobiliśmy kilka zmian do opcji loose niektórych wtyczek i dodaliśmy kilka nowych opcji dla innych! Zauważ, że używając tych opcji decydujesz się na zachowanie niezgodne ze specyfikacją i powinieneś wiedzieć, co robisz; może to stać się problemem, gdy wyłączysz kompilację, aby używać składni natywnie. Tego rodzaju opcji najlepiej używać w bibliotece, jeśli w ogóle.

  • Dla klas, class A {} nie będzie teraz zawierać classCallCheck helpera.
class A {}
var A = function A() {- _classCallCheck(this, A);};
  • Jest nowa opcja, jeśli każde użycie pętli for-of jest po prostu tablicą: 
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);}
  • Wykluczamy wtyczkę transform-typeof-symbol w trybie loose dla preset-env #6831

Znaleźliśmy wiele bibliotek, które już to robią, więc postanowiliśmy zrobić to domyślnie.

Zauważ, że domyślnym zachowaniem jest bycie jak najbardziej zgodnym ze specyfikacją, tak aby wyłączenie Babel lub użycie preset-env było bezproblemowe vs. pozwalanie na mniejsze wyjście tylko po to, aby zaoszczędzić bajty (jest to kompromis, który każdy projekt może osiągnąć). Planujemy pracować nad lepszymi dokumentami i narzędziami, aby to ułatwić.

„Czysta” obsługa adnotacji

Po #6209, transpilowane klasy ES6 są opatrzone adnotacją /*#__PURE__*/ z komentarzem, który pozwala na udzielenie podpowiedzi minifikatorom takim jak Uglify i babel-minify w celu eliminacji martwego kodu. Te adnotacje są również dodawane do innych funkcji pomocniczych.

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

Może być więcej możliwości dla podpowiedzi minifikatorów i optymalizacji, daj nam znać!

Składnia

TC39 Proposals Support

Chciałbym powtórzyć, że usunęliśmy presety Stage na rzecz polityki proszenia użytkowników o wyraźne opt-in do propozycji < Stage 4.

Obawa jest taka, że automatycznie optujemy ludzi do składni, która nie jest ustalona lub zrobiona z oczekiwaniem, że się nie zmieni. Ale tak nie jest, zwłaszcza w przypadku propozycji, które są etapem 0 lub 1. Ten post wyjaśnia nieco rodzaj myślenia stojącego za nowszymi pomysłami.

Tutaj jest mała lista niektórych nowych składni obsługiwanych przez Babel (pamiętaj, że ten zestaw funkcji jest ruchomym celem, który może zostać dodany/usunięty/ustalony) i które zostały dodane w v7:

  • ES2018: Object Rest Spread (var a = { b, ...c })
  • ES2018 (nowy): Unicode Property Regex
  • ES2018 (nowy): JSON Superset
  • ES2015 (nowy): new.target
  • Stage 3 (nowy): Class Private Instance Fields (class A { #b = 2 })
  • Stage 3 (WIP): Static Class Fields, Private Static Methods (class A { static #a() {} })
  • Stage 3 (new): Optional Catch Binding try { throw 0 } catch { do() }
  • Stage 3 (new): BigInt (tylko składnia)
  • Etap 3: Dynamic Import (import("a"))
  • Etap 2 (nowy): import.meta (tylko składnia) (import.meta.url)
  • Etap 2 (nowy): Separatory numeryczne (1_000)
  • Etap 2 (nowy): function.sent
  • Etap 2: export-namespace-from (export * as ns from 'mod'), podzielony z export-extensions
  • Etap 2: Dekoratory. Sprawdź poniżej, aby uzyskać aktualizację na temat naszych postępów!
  • Etap 1: export-default-from (export v from 'mod'), podzielone z export-extensions
  • Etap 1 (nowy): Optional Chaining (a?.b)
  • Stage 1 (new): Logical Assignment Operators (a &&= b; a ||= b)
  • Stage 1 (new): Nullish Coalescing Operator (a ?? b)
  • Stage 1 (new): Pipeline Operator (a |> b)
  • Stage 1 (new): Throw Expressions (() => throw new Error("a"))

Ciężko jest komukolwiek śledzić wszystkie propozycje, więc próbujemy to robić na babel/proposals.

Wsparcie TypeScript (@babel/preset-typescript)

Pracowaliśmy z zespołem TypeScript nad tym, aby Babel parsował/transformował składnię typów za pomocą @babel/preset-typescript, podobnie do tego, jak obsługujemy Flow za pomocą @babel/preset-flow.

Po więcej szczegółów sprawdź ten post od zespołu TypeScript!

Przed (z typami):

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

Po (typy usunięte):

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

Oba Flow i Typescript są narzędziami, które pozwalają użytkownikom JavaScript na korzystanie ze stopniowego typowania, i chcielibyśmy włączyć oba w Babel. Planujemy kontynuować ścisłą współpracę z ich zespołami w FB i Microsoft (oprócz całej społeczności), aby utrzymać kompatybilność i wspierać nowe funkcje.

Ta integracja jest dość nowa, więc możliwe, że niektóre składnie nie są w pełni obsługiwane. Będziemy wdzięczni za pomoc w zgłaszaniu problemów i być może wysłaniu PR!

Obsługa fragmentów JSX (<>)

Jak wspomniano na blogu React, obsługa fragmentów JSX jest dostępna od beta.31.

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

Zmiany w Babel Helpers

Trwa PR babel-upgrade

@babel/runtime został podzielony na @babel/runtime i @babel/runtime-corejs2 (PR). Pierwsza zawiera tylko funkcje pomocnicze Babel, a druga zawiera to, jak również wszelkie funkcje polyfill (np. Symbol, Promise).

Babel może potrzebować wstrzyknąć pewne funkcje do kodu, które mogą być ponownie użyte. Nazywamy je po prostu „funkcjami pomocniczymi”, tak jak funkcje współdzielone między modułami.

Przykładem tego jest kompilacja class (bez włączonego trybu loose):

Specyfikacja mówi, że musisz wywołać klasę z new Person(), ale jeśli jest ona skompilowana do funkcji, możesz technicznie po prostu zrobić Person(), więc dołączamy sprawdzanie runtime dla tego.

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

W przypadku @babel/plugin-transform-runtime i @babel/runtime (jako zależności), Babel może wyodrębnić poszczególne funkcje i po prostu wymagać funkcji modułowych, aby umożliwić mniejsze wyjście, takie jak:

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

To samo można zrobić z external-helpers i rollup-plugin-babel. Sprawdzamy, czy możemy to zrobić automatycznie w przyszłości. Wypatruj wkrótce samodzielnego postu o pomocnikach Babel.

Automatyczne wypełnianie (eksperymentalne)

Wypełnienia są niezbędne do włączenia funkcji takich jak Promise, Symbol w środowiskach, które nie mają dla nich wsparcia. Jest to ważne przy rozróżnianiu tego, co Babel robi jako kompilator (przekształca składnię) vs. polyfill (implementuje wbudowane funkcje/obiekty).

Dość łatwo jest po prostu zaimportować coś, co obejmuje wszystko jak @babel/polyfill:

import "@babel/polyfill";

Ale zawiera to całą polyfill, i możesz nie potrzebować importować wszystkiego, jeśli przeglądarki już to obsługują. Jest to ten sam problem, który @babel/preset-env próbuje rozwiązać za pomocą składni, więc stosujemy go tutaj z polyfillami. Opcja useBuiltins: "entry" robi to przez podzielenie oryginalnego importu na tylko te importy, które są konieczne.

Możemy jednak zrobić to lepiej, importując tylko te polyfills, które są używane w bazie kodowej. Opcja "useBuiltIns: "usage" jest naszą pierwszą próbą włączenia czegoś takiego (docs).

Przebiegnie ona przez każdy plik i wstrzyknie import na górze każdego pliku, jeśli ten wbudowany jest „używany” w kodzie. Na przykład:

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

Wnioskowanie nie jest doskonałe, więc mogą wystąpić fałszywe pozytywy.

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

Inne pomysły w tej przestrzeni to użycie polyfill.io, jeśli jesteś w porządku z poleganiem na usłudze (lub przeczytaj, jak Kent C. Dodds użył go do zbudowania usługi hostowanej w PayPal).

Misc

Babel Macros 🎣

Jedną z najlepszych części Babel jest możliwość podłączenia narzędzia. Przez lata, Babel przeszedł od kompilatora „6to5” do platformy przekształcania kodu, umożliwiając fantastyczne optymalizacje zarówno dla użytkownika jak i dewelopera. Tony wtyczek Babel zostały stworzone dla konkretnych bibliotek i przypadków użycia, aby poprawić wydajność i możliwości API bibliotek, które nie byłyby możliwe w innym przypadku (niektóre „biblioteki” są całkowicie transpilowane, co skutkuje brakiem jakiegokolwiek runtime’u).

Niestety, dodanie tych wtyczek do twojej bazy kodu wymaga zmiany konfiguracji (na co nie pozwalają niektóre zestawy narzędzi takie jak create-react-app) i dodaje złożoności do twojego kodu, ponieważ programiści muszą wiedzieć jakie wtyczki Babel działają na pliku, aby wiedzieć co stanie się z kodem, który piszą. Te problemy zostały rozwiązane przez babel-plugin-macros autorstwa Kenta C. Doddsa!

Po zainstalowaniu babel-plugin-macros i dodaniu go do konfiguracji (jest zawarty w create-react-app v2), nie musisz zawracać sobie głowy konfiguracją, aby używać jakichkolwiek makr. Ponadto, jeszcze łatwiej jest pisać własne niestandardowe transformacje dla przypadków użycia specyficznych dla twojej aplikacji lub jednej części twojego kodu.

Dowiedz się więcej o babel-plugin-macros w naszym oryginalnym poście „Zero-config code transformation with babel-plugin-macros”.

Module Targeting

Babel zawsze starał się zrównoważyć wpływ rozmiaru transformacji i możliwości, jakie dają one autorom JavaScriptem. W Babel 7, stało się o wiele łatwiej skonfigurować Babel do wspierania rosnącej popularności wzoru moduł/nomoduł.

W szczególności, kilka narzędzi CLI dla popularnych frameworków internetowych (1, 2) już wykorzystują wsparcie prowadzące do około 20% redukcji wysyłanego JavaScriptu do konsumentów aplikacji transponowanych przez Babel.

Metadane rozmówcy i lepsze ustawienia domyślne

Dodaliśmy opcję caller do @babel/core, aby nasze narzędzia mogły przekazywać metadane do presetów/wtyczek. Na przykład: babel-loader może dodać coś takiego, aby preset-env mógł automatycznie wyłączyć transformację modułu (to samo z rollup:

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

To jest ekscytujące, ponieważ umożliwia sposób, w jaki tooling może zapewnić lepsze ustawienia domyślne i mniej konfiguracji! W przypadku webpack/rollup: możemy automatycznie odroczyć użycie ich transformacji modułu zamiast transformacji Babela (to samo z import("a")). Zwróć uwagę na więcej narzędzi do korzystania z tego w przyszłości!

class C extends HTMLElement {}

Jeden z naszych najstarszych problemów dostaje swój własny nagłówek (szczegóły)

Babel zawsze miał zastrzeżenie, że nie może wspierać rozszerzania natywnych wbudowanych elementów (Array, Error, itp.), a teraz może! Dostaliśmy wiele problemów na ten temat; 🎉 powinieneś świętować jak Andrea!

Ta zmiana została wprowadzona do wtyczki klasy, więc powinna być automatycznie włączona, jeśli używasz preset-env.

Zmiany na stronie 🌏

Przenosimy naszą stronę z Jekyll do Docusaurus!

Wciąż jesteśmy w trakcie konfigurowania tłumaczeń z Crowdin, a dzięki Babel 7 będziemy w lepszym miejscu, aby rozpocząć ten proces.

REPL

Przeredagowaliśmy REPL jako komponent React i pracowaliśmy z Ivesem nad lepszą integracją z CodeSandbox. Dzięki temu można zainstalować dowolny plugin lub preset z npm w REPLu, jak również otrzymywać wszelkie aktualizacje, które CodeSandbox dostaje.

Wzięliśmy udział w Rails Girls Summer of Code ponownie! Tym razem Gyujin i Sujin ciężko pracowali nad zintegrowaniem babel-time-travel Boopathi’ego z REPL, który możesz już teraz przetestować!

Jest tak wiele możliwości zaangażowania się, aby Babel, AST i inne narzędzia działały lepiej!

We Have A Song 🎶

Hallelujah-In Praise of Babel

Jakiegoś dnia Angus łaskawie przekazał nam piosenkę, która moim zdaniem była niesamowita, więc dlaczego nie uczynić jej naszą „oficjalną” piosenką? I Shawn zrobił genialny cover tutaj.

Możecie go znaleźć w naszym repo na SONG.md. Mamy nadzieję, że inne projekty pójdą tym śladem!

What’s Next?

  • Babel jest nieodłącznie związany z tym, co kompiluje: JavaScript. Tak długo jak istnieją nowe dodatki do zaproponowania/pracy nad nimi, jest praca do wykonania. Obejmuje to czas/wysiłek poświęcony na implementację i utrzymanie składni nawet zanim stanie się ona „stabilna”. Dbamy o cały proces: ścieżkę aktualizacji, naukę nowych funkcji, naukę standardów/projektu językowego, łatwość użycia i integrację z innymi projektami.
    • Odnośnie: prawie skończyliśmy wdrażać nową propozycję dekoratorów w Babel dzięki Nicolò. To była długa podróż (trwała ponad rok!) ponieważ nowa propozycja jest zupełnie inna i dużo bardziej potężna niż stara, ale już prawie jest 🎉. Możecie się spodziewać, że zostanie wydana w jednej z następnych mniejszych wersji, wraz z wpisem na blogu, który szczegółowo wyjaśni zmiany.
  • Boopathi pilnie utrzymuje babel-minify, więc będziemy robić 1.0 dla tego następnego!
  • Pracujemy nad wieloma nowymi funkcjami: porządkowanie wtyczek, lepsza walidacja/błędy, szybkość, ponowne przemyślenie opcji luźnych/spec, buforowanie, używanie Babel asynchronicznie, budowanie przeciwko sobie z CI, testy dymne, uruchamianie testu262. Sprawdź ten dokument z mapą drogową, aby poznać więcej możliwych pomysłów!

Nie mamy żadnych tajnych planów: staramy się jak najlepiej wykorzystać to, co mamy, aby służyć tej społeczności.

Open Source is a Mirror

Bardzo bym chciał, gdybyśmy mieli czas i zasoby, aby zrealizować wszystkie te pomysły i zrobić to dobrze. Ale jak pokazaliśmy z tym obecnym wydaniem, rzeczy zajmują dużo więcej czasu niż się spodziewaliśmy!

Dlaczego te wydania trwają tak długo? Czy to z powodu pełzania funkcji, zarówno od nas samych, jak i naszych użytkowników? Czy to dlatego, że nie rozumiemy jak ustalić priorytety wśród wszystkich możliwych rzeczy do dodania lub naprawienia? Decydując się na naprawę nisko wiszących owoców, a nie fundamentalnych problemów do końca? Czy może „rozpraszanie się” od pomagania innym na GitHubie, Slacku, Twitterze? Czy po prostu źle szacujemy nasz czas, rozumiemy złożoność tych problemów, nadmiernie angażujemy się jako wolontariusze?

A może po prostu stawiamy sobie zbyt wysokie oczekiwania, albo czujemy się tak naciskani przez innych, aby wykonywać i dopasowywać się do ich potrzeb ze szkodą dla nas samych? Mogę to opisać tylko jako zgrozę, gdy widzę wiadomość od kogoś online zastanawiającego się, dlaczego coś nie zostało wydane, podczas gdy inny pyta, dlaczego ten błąd nie został jeszcze naprawiony. Chciałbym po prostu to pospiesznie wydać i mieć to już za sobą, ale mam też pragnienie, aby potraktować to poważnie.

Próbowałem wyrazić niektóre z tych myśli i zmagań w moim wykładzie w zeszłym tygodniu na React Rally: Through the (Open Source) Looking Glass, który mam nadzieję, że możesz skorzystać z okazji, aby posłuchać. Pytanie, które sobie zadaję: Co mogę zrobić z nieuniknionym cyklem wypalenia opiekuna, ciągłym niepokojem i nierealistycznymi oczekiwaniami?

Jak w wielu dziedzinach życia, rzeczy, które robimy, odzwierciedlają nasz charakter i pokazują nam, jacy naprawdę jesteśmy. Działania, które podejmujemy mogą same w sobie zmienić nas, na lepsze lub gorsze. Jeśli mamy traktować naszą pracę poważnie, powinniśmy nawzajem rozliczać się z tych nawyków, które wydają się być tak zakorzenione w naszej kulturze: natychmiastowej gratyfikacji, sukcesu w kategoriach metrycznych, uprawnienia vs. wdzięczności i dumy z przepracowania.

Ale pomimo tego wszystkiego, praca nad tym wydaniem była tego warta.

Dzięki

To naprawdę ekscytujące wydanie, nie tylko patrząc wstecz na to, co udało nam się osiągnąć i umożliwić, ale o wiele bardziej wiedząc, ile czasu i serca włożono w jego stworzenie w ciągu ostatniego roku. Trudno uwierzyć w możliwości i doświadczenia, które wydarzyły się po drodze: interakcja i pomoc firmom z całego świata, znalezienie przyjaciół w prawie każdym mieście, które odwiedziłem, i szczere mówienie o niewiarygodnej podróży, którą ta grupa podjęła razem.

Personalnie, nigdy tak naprawdę nie włożyłem tyle mojej energii umysłowej w coś tej wielkości i chciałbym podziękować tak wielu ludziom za podnoszenie nas po drodze. Szczególne wyrazy uznania dla Logana Smytha, który poświęcił niezliczoną ilość czasu, aby zmienić tak wiele z tego, jak działa rdzeń i zawsze poświęca czas, aby być tak pomocnym w naszym Slacku, jednocześnie pracując jako freelancer oraz dla Briana Ng, który podjął się w tak wielki sposób, aby nadal utrzymywać Babel, jak również recenzować wszystkie moje posty na blogu i rozmowy. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo i Justin Ridgewell przyczynili się do tego, że to wydanie było możliwe i przyjemnie się nad nim pracowało.

Podziękowania dla wszystkich członków społeczności na Slacku, Twitterze i we wszystkich projektach na GitHubie, którzy również muszą zrozumieć co robimy dla ich własnych użytkowników. Chciałbym bardzo podziękować moim przyjaciołom z Behance/Adobe za sponsorowanie mnie przez prawie rok, abym mógł pracować nad Babel na pół etatu przed podjęciem decyzji o przejściu na pełny etat (jak również za pomoc w testowaniu Babel 7 na produkcji przez cały czas, kiedy tam byłem). Wielkie podziękowania dla wszystkich naszych sponsorów dla naszego Otwartego Kolektywu, szczególnie dla Trivago i Handshake. I dzięki naszym przyjaciołom i rodzinie za całą ich miłość i wsparcie.

W tym momencie wszyscy jesteśmy dość zmęczeni, ale to naprawdę był zaszczyt i przywilej służyć w ten sposób, więc mamy nadzieję, że doceniacie to wydanie!

.