Babel 7 veröffentlicht

BY admin
|

Nach fast 2 Jahren, 4k Commits, über 50 Vorabversionen und einer Menge Hilfe freuen wir uns, die Veröffentlichung von Babel 7 bekannt zu geben. Seit der Veröffentlichung von Babel 6 sind schon fast 3 Jahre vergangen! Es gibt viele bewegliche Teile, also haben Sie bitte in den ersten Wochen der Veröffentlichung Geduld mit uns. Babel 7 ist ein riesiges Release: Wir haben es schneller gemacht, ein Upgrade-Tool, JS-Configs, Config-„Overrides“, mehr Optionen für Größe/Minimierung, JSX-Fragmente, TypeScript, neue Vorschläge und vieles mehr!

Wenn Sie die Arbeit, die wir an Babel leisten, zu schätzen wissen, können Sie Babel auf Open Collective sponsern, mich auf Patreon unterstützen oder Sie oder Ihr Unternehmen als Teil der Arbeit an Babel beteiligen. Wir würden uns freuen, wenn Sie dieses wichtige Projekt in der JavaScript-Gemeinschaft kollektiv unterstützen würden!

It’s Happening! 🎉

Software wird nie perfekt sein, aber wir sind bereit, etwas auszuliefern, das bereits seit einiger Zeit in der Produktion eingesetzt wird! @babel/core ist bereits bei 5,1 Millionen Downloads/Monat, weil es in Tools wie Next.js 6, vue-cli 3.0, React Native 0.56 und sogar im Frontend von WordPress.com verwendet wird 🙂!

Die Rolle von Babel

Ich möchte diesen Beitrag damit beginnen, die Rolle von Babel im JavaScript-Ökosystem in den letzten Jahren noch einmal vorzustellen.

Das anfängliche Problem bestand darin, dass es im Gegensatz zu Server-Sprachen keine Möglichkeit gab, zu garantieren, dass jeder Benutzer die gleiche Unterstützung für JavaScript hat, da die Benutzer verschiedene Browser mit unterschiedlichem Unterstützungsgrad verwenden konnten (insbesondere ältere Versionen des Internet Explorer). Wenn Entwickler eine neue Syntax (z.B. class A {}) verwenden wollten, bekamen die Benutzer alter Browser wegen SyntaxError nur einen leeren Bildschirm.

Babel bot Entwicklern die Möglichkeit, die neueste JavaScript-Syntax zu verwenden, ohne sich Gedanken darüber machen zu müssen, wie sie diese für ihre Benutzer abwärtskompatibel machen können, indem sie sie übersetzen (class A {} nach var A = function A() {}).

Aufgrund seiner Fähigkeit, JavaScript-Code umzuwandeln, kann es auch dazu verwendet werden, neue Funktionen zu implementieren: So ist es zu einer Brücke geworden, die TC39 (dem Komitee, das die JavaScript-Sprache spezifiziert) dabei hilft, Feedback zu vorgeschlagenen JavaScript-Ideen zu erhalten und der Gemeinschaft ein Mitspracherecht bei der Zukunft der Sprache zu geben.

Babel ist für die heutige JavaScript-Entwicklung von grundlegender Bedeutung. Derzeit gibt es über 1,3 Millionen abhängige Repos auf GitHub, 17 Millionen Downloads auf npm pro Monat und Hunderte von Nutzern, darunter viele große Frameworks (React, Vue, Ember, Polymer) und Unternehmen (Facebook, Netflix, Airbnb). Es hat sich zu einer solchen Grundlage für die JavaScript-Entwicklung entwickelt, dass viele Leute nicht einmal wissen, dass es verwendet wird. Selbst wenn Sie es nicht selbst verwenden, ist es sehr wahrscheinlich, dass Ihre Abhängigkeiten Babel verwenden.

Maintainer sind Menschen

Babel hat nicht nur einen großen Einfluss auf die Zukunft der Sprache selbst, sondern auch auf ihre Gemeinschaft und ihr Ökosystem. Aber trotz all dieser Verantwortung ist Babel nur ein gemeinschaftsgetriebenes Projekt von ein paar Freiwilligen.

Erst im vergangenen Jahr konnten sich einige des Teams zum ersten Mal persönlich treffen:

Das ursprüngliche @babeljs-Team, endlich zusammen. Von links nach rechts: @left_pad, @jamiebuilds, @sebmck, yours truly, and @loganfsmyth pic.twitter.com/XfPj6OhZfA

– Amjad Masad (@amasad) May 3, 2018

Auch wenn dies ein Ankündigungspost ist, möchte ich die Gelegenheit nutzen, um alle an den Stand des Projekts zu erinnern.

Ich selbst bin ein paar Monate vor der Veröffentlichung von 6.0 beigetreten, die ihre eigene Menge an Kontroversen und Gegenreaktionen hatte. Ein Großteil des Empfangs dort führte zu einem Burnout der bestehenden Betreuer (einschließlich Sebastian, dem Schöpfer von Babel), und ein paar von uns, die übrig geblieben waren, übernahmen die Zügel.

Wie viele Betreuer sind wir zufällig in diese Rolle hineingestolpert. Viele von uns hatten keine formale Ausbildung darin, wie Compiler funktionieren oder wie man ein Open-Source-Projekt pflegt. Ironischerweise habe ich es sogar absichtlich vermieden, Informatik als Hauptfach zu studieren, weil ich keine Kurse über Compiler oder irgendetwas auf niedriger Ebene belegen wollte, weil es mir uninteressant und schwierig erschien. Dennoch fühlte ich mich zu Werkzeugen, Linters, Babel und JavaScript als Sprache hingezogen.

Ich möchte jeden ermutigen, sich die Open-Source-Projekte anzusehen, auf die man angewiesen ist, und sie zu unterstützen (sowohl mit Zeit als auch mit Geld, wenn möglich).

Viele Maintainer sind nicht von Natur aus Experten in den Dingen, an denen sie arbeiten; und es gibt viel zu erreichen, wenn man erst einmal mit der Arbeit beginnt. Sie werden mit Neugier und Bescheidenheit an die Sache herangehen, beides großartige Eigenschaften, die man als Betreuer haben sollte. Mein Wunsch ist die Hoffnung auf die Vision des Projekts und nicht darauf, dass wir alle nur „Aufgaben“ erledigen.

Babel ist kein Unternehmen oder ein Open-Source-Team bei einem großen Unternehmen wie Facebook. Es gibt nur eine Handvoll Freiwilliger, die an Babel arbeiten, und es ist erst ein paar Monate her, dass ich den Schritt gewagt habe, meinen Job zu verlassen und als einziger bisher Vollzeit an Open Source zu arbeiten. Aber Menschen können kommen und gehen, haben ein Leben außerhalb dieses „Hobbys“, gründen Familien, wenden sich anderen Dingen zu, wechseln den Arbeitsplatz oder sind auf der Suche nach einem neuen Job, usw. Tun wir gemeinsam, was wir können, um die Dinge aufrechtzuerhalten, die für unsere Arbeit so grundlegend sind, oder lassen wir zu, dass das Fundament langsam zerbröckelt? Wie können wir dafür sorgen, dass Open Source einladend und inklusiv bleibt, aber mit klaren Grenzen? Können wir aus den Erfahrungen anderer Maintainer lernen?

Obwohl Open Source eindeutig die Software übernommen hat, können wir sie wirklich als gesund betrachten, ohne die Menschen dahinter zu berücksichtigen?

#BabelSponsorsEverything

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

– Harry Wolff (@hswolff) August 17, 2018

Nachhaltigkeit von Open Source fühlt sich derzeit an wie das Verteilen eines Opferkorbs. Es ist nicht schwer, den Wert der Projekte für die Tausenden von Menschen und Unternehmen zu benennen, die Open Source nutzen, aber wir sehen nicht, dass dieser Wert den wenigen gezeigt wird, die bereit sind, die Arbeit zu investieren. Es gibt so viele Möglichkeiten, Open Source zu unterstützen, und doch funktionieren nicht alle Ansätze für jedes Projekt oder jeden Menschen.

Nun zu den Änderungen!!!

Major Breaking Changes

Wir dokumentieren diese in unserem Migration Guide. Viele dieser Änderungen können automatisch mit unserem neuen babel-upgrade Tool durchgeführt werden, oder können in Zukunft hinzugefügt werden.

  • Unterstützung für nicht gewartete Node-Versionen einstellen: 0.10, 0.12, 4, 5 (Details)
  • Move us to the @babel namespace by switching to using „scoped“ packages (Details). Dies hilft, offizielle Pakete zu unterscheiden, so wird babel-core zu @babel/core (und kein Squatting)
  • Entferne (und höre auf zu veröffentlichen) alle jährlichen Voreinstellungen (preset-es2015, etc) (Details). @babel/preset-env ersetzt diese, da es alle jährlichen Ergänzungen sowie die Möglichkeit, eine bestimmte Gruppe von Browsern anzusprechen, enthält
  • Auch die „Stage“-Vorgaben (@babel/preset-stage-0 usw.) werden zugunsten von individuellen Vorschlägen entfernt. Ebenso werden Vorschläge aus @babel/polyfill standardmäßig entfernt (Details). Bitte lesen Sie den gesamten Beitrag zu diesem Thema, um weitere Erklärungen zu erhalten.
  • Einige Pakete wurden umbenannt: Jedes TC39-Vorschlags-Plugin wird nun -proposal statt -transform heißen (Details). So wird @babel/plugin-transform-class-properties zu @babel/plugin-proposal-class-properties.
  • Ein peerDependency auf @babel/core für bestimmte benutzerseitige Pakete einführen (z.B. babel-loader, @babel/cli, etc) (Details)

babel-upgrade

babel-upgrade ist ein neues Tool, das wir gestartet haben, das versucht, automatisch Upgrade-Änderungen vorzunehmen: derzeit mit Abhängigkeiten in package.json und .babelrc config.

Wir empfehlen, es direkt auf einem Git-Repo mit npx babel-upgrade laufen zu lassen, oder du kannst es global mit npm i babel-upgrade -g installieren.

Wenn du die Dateien modifizieren möchtest, kannst du --write sowie --install übergeben.

npx babel-upgrade --write --install

Bitte ziehe in Betracht, einen Beitrag zu leisten, indem du Probleme oder PRs meldest, um allen beim Übergang zu Babel 7 zu helfen! Eine Hoffnung für die Zukunft ist, dass wir dasselbe Tool für alle zukünftigen Änderungen verwenden und einen Bot für PR-Projekte zur Aktualisierung erstellen.

JavaScript Config Files

Wir führen babel.config.js ein. Es ist keine Voraussetzung oder gar ein Ersatz für .babelrc, aber es kann in bestimmten Fällen nützlich sein.

*.js Konfigurationsdateien sind im JavaScript-Ökosystem ziemlich verbreitet. ESLint und Webpack erlauben beide .eslintrc.js bzw. webpack.config.js Konfigurationsdateien.

Unten ist der Fall, dass man nur mit einem Plugin in „Produktion“ kompiliert (man kann dies bereits mit der "env" Option in einer .babelrc Datei tun):

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

babel.config.js hat eine andere Konfigurationsauflösung als eine .babelrc. Es wird immer die Konfiguration aus dieser Datei aufgelöst, im Gegensatz zu ursprünglich, als Babel eine Suche von jeder Datei nach oben durchführte, bis es eine Konfiguration fand. Dies macht es möglich, die Vorteile des nächsten Features zu nutzen, das weiter unten gepostet wird, overrides.

Selektive Konfiguration mit Überschreibungen

Kürzlich habe ich einen Beitrag veröffentlicht, in dem ich mir Gedanken über die Veröffentlichung von ES2015+-Paketen und deren Konsumierung/Kompilierung gemacht habe.

Es gibt einen Abschnitt, der sich mit der Verwendung eines neuen Schlüssels in Babels Config namens overrides befasst, der es erlaubt, verschiedene Configs pro Glob anzugeben.

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

Damit kann eine Anwendung, die unterschiedliche Kompilierungskonfigurationen für ihre Tests, ihren Client- und ihren Servercode benötigt, die Erstellung einer neuen .babelrc-Datei pro Ordner überspringen.

Geschwindigkeit 🏎

Babel selbst ist nun schneller, so dass der Build weniger Zeit in Anspruch nehmen sollte! Wir haben viele Änderungen vorgenommen, um den Code zu optimieren und die Patches des v8-Teams zu akzeptieren. Wir freuen uns, neben vielen anderen großartigen JavaScript-Tools ein Teil des Web Tooling Benchmark zu sein.

Output Options

Babel unterstützt seit einiger Zeit Preset- und Plugin-Optionen. Sie können das Plugin in ein Array verpacken und ein Optionsobjekt an das Plugin übergeben:

{ "plugins": , ]}

Wir haben einige Änderungen an der loose Option einiger Plugins vorgenommen und einige neue Optionen für andere hinzugefügt! Beachten Sie, dass Sie sich mit diesen Optionen für ein nicht spezifikationskonformes Verhalten entscheiden und wissen sollten, was Sie tun; dies kann zu einem Problem werden, wenn Sie die Kompilierung abschalten, um die Syntax nativ zu verwenden. Diese Art von Optionen werden am besten in einer Bibliothek verwendet, wenn überhaupt.

  • Für Klassen wird class A {} nun nicht den classCallCheck Helfer enthalten.
class A {}
var A = function A() {- _classCallCheck(this, A);};
  • Es gibt eine neue Option, wenn jede Verwendung einer for-of Schleife nur ein Array ist: 
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);}
  • Wir schließen das transform-typeof-symbol-Plugin im loose-Modus für preset-env aus #6831

Wir haben festgestellt, dass viele Bibliotheken dies bereits tun, also haben wir beschlossen, dies standardmäßig zu tun.

Bitte beachten Sie, dass das Standardverhalten so spezifikationskonform wie möglich sein soll, so dass das Ausschalten von Babel oder die Verwendung von preset-env nahtlos ist, im Gegensatz zum Zulassen einer kleineren Ausgabe, nur um Bytes zu sparen (hier gibt es einen Kompromiss, den jedes Projekt eingehen kann). Wir planen, an besseren Dokumentationen und Werkzeugen zu arbeiten, um das einfacher zu machen.

„Pure“ Annotation Support

Nach #6209 werden transpilierte ES6-Klassen mit einem /*#__PURE__*/-Kommentar annotiert, der Minifiern wie Uglify und babel-minify einen Hinweis zur Eliminierung von totem Code gibt. Diese Annotationen werden auch zu anderen Hilfsfunktionen hinzugefügt.

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

Es könnte noch mehr Möglichkeiten für Minifier-Hinweise und Optimierungen geben, lassen Sie es uns wissen!

Syntax

TC39 Proposals Support

Ich möchte noch einmal darauf hinweisen, dass wir die Voreinstellungen für die Stufe entfernt haben und stattdessen die Benutzer auffordern, sich explizit für Vorschläge < der Stufe 4 zu entscheiden.

Die Sorge ist, dass wir die Leute automatisch für eine Syntax entscheiden, die nicht festgelegt ist oder in der Erwartung, dass sie sich nicht ändern wird. Dies ist jedoch nicht der Fall, insbesondere nicht bei Vorschlägen der Stufe 0 oder 1. Dieser Beitrag erklärt ein wenig die Art des Denkens hinter neueren Ideen.

Hier ist eine kleine Auflistung einiger der neuen Syntaxen, die Babel unterstützt (denken Sie daran, dass dieses Feature-Set ein bewegliches Ziel ist, das hinzugefügt/entfernt/gestoppt werden kann) und welche in v7 hinzugefügt wurden:

  • ES2018: Object Rest Spread (var a = { b, ...c })
  • ES2018 (neu): Unicode Property Regex
  • ES2018 (neu): JSON Superset
  • ES2015 (neu): new.target
  • Stufe 3 (neu): Private Instanzfelder der Klasse (class A { #b = 2 })
  • Stufe 3 (WIP): Statische Klassenfelder, private statische Methoden (class A { static #a() {} })
  • Stufe 3 (neu): Optionale Catch-Bindung try { throw 0 } catch { do() }
  • Stufe 3 (neu): BigInt (nur Syntax)
  • Stufe 3: Dynamischer Import (import("a"))
  • Stufe 2 (neu): import.meta (nur Syntax) (import.meta.url)
  • Stufe 2 (neu): Numerische Trennzeichen (1_000)
  • Stufe 2 (neu): function.sent
  • Stufe 2: export-namespace-from (export * as ns from 'mod'), getrennt von export-extensions
  • Stufe 2: Dekoratoren. Im Folgenden finden Sie ein Update zu unseren Fortschritten!
  • Stufe 1: export-default-from (export v from 'mod'), abgetrennt von export-extensions
  • Stufe 1 (neu): Optionale Verkettung (a?.b)
  • Stufe 1 (neu): Logische Zuweisungsoperatoren (a &&= b; a ||= b)
  • Stufe 1 (neu): Nullish Coalescing Operator (a ?? b)
  • Stufe 1 (neu): Pipeline-Operator (a |> b)
  • Stufe 1 (neu): Throw Expressions (() => throw new Error("a"))

Es ist schwer für jemanden, den Überblick über alle Vorschläge zu behalten, daher versuchen wir, dies unter babel/proposals zu tun.

TypeScript-Unterstützung (@babel/preset-typescript)

Wir haben mit dem TypeScript-Team daran gearbeitet, Babel dazu zu bringen, Typsyntax mit @babel/preset-typescript zu analysieren/umzuwandeln, ähnlich wie wir Flow mit @babel/preset-flow behandeln.

Weitere Details finden Sie in diesem Beitrag des TypeScript-Teams!

Vor (mit Typen):

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

Nach (ohne Typen):

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

Beide, Flow und Typescript, sind Tools, die es JavaScript-Benutzern ermöglichen, die Vorteile der graduellen Typisierung zu nutzen, und wir möchten beides in Babel ermöglichen. Wir planen, weiterhin eng mit den jeweiligen Teams bei FB und Microsoft (zusätzlich zur Community insgesamt) zusammenzuarbeiten, um die Kompatibilität aufrechtzuerhalten und neue Funktionen zu unterstützen.

Diese Integration ist relativ neu, daher ist es möglich, dass einige Syntaxen nicht vollständig unterstützt werden. Wir würden uns freuen, wenn Sie uns helfen würden, Probleme zu melden und vielleicht einen PR zu senden!

JSX Fragment Support (<>)

Wie im React Blog erwähnt, ist JSX Fragment Support seit beta.31 verfügbar.

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

Babel Helpers Changes

Der babel-upgrade PR ist in Arbeit

@babel/runtime wurde aufgeteilt in @babel/runtime und @babel/runtime-corejs2 (PR). Ersterer enthält nur die Hilfsfunktionen von Babel und letzterer enthält diese sowie alle Polyfill-Funktionen (z.B. Symbol, Promise).

Babel muss möglicherweise bestimmte Funktionen in den Code einbauen, die wiederverwendet werden können. Wir nennen diese Funktionen „Hilfsfunktionen“, genau wie Funktionen, die von Modulen gemeinsam genutzt werden.

Ein Beispiel dafür ist das Kompilieren eines class (ohne loose-Modus):

Die Spezifikation besagt, dass man eine Klasse mit new Person() aufrufen muss, aber wenn sie zu einer Funktion kompiliert ist, könnte man technisch gesehen auch einfach Person() verwenden, weshalb wir eine Laufzeitprüfung dafür einbauen.

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

Mit @babel/plugin-transform-runtime und @babel/runtime (als Abhängigkeit) kann Babel die einzelnen Funktionen extrahieren und nur die modularen Funktionen benötigen, um eine kleinere Ausgabe zu ermöglichen, etwa so:

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

Das Gleiche kann mit external-helpers und rollup-plugin-babel gemacht werden. Wir prüfen derzeit, ob wir dies in Zukunft automatisch tun können. Halten Sie demnächst Ausschau nach einem eigenständigen Beitrag über die Helfer von Babel.

Automatisches Polyfilling (experimentell)

Polyfills sind notwendig, um Funktionen wie Promise, Symbol in Umgebungen zu aktivieren, die keine Unterstützung dafür haben. Dies ist wichtig bei der Unterscheidung zwischen dem, was Babel als Compiler (transformiert die Syntax) und als Polyfill (implementiert eingebaute Funktionen/Objekte) tut.

Es ist einfach genug, etwas zu importieren, das alles abdeckt, wie @babel/polyfill:

import "@babel/polyfill";

Aber es enthält den gesamten Polyfill, und man muss vielleicht nicht alles importieren, wenn die Browser es bereits unterstützen. Dies ist das gleiche Problem, das @babel/preset-env mit der Syntax zu lösen versucht, also wenden wir es hier mit Polyfills an. Die Option useBuiltins: "entry" tut dies, indem sie den ursprünglichen Import in nur die Importe aufteilt, die notwendig sind.

Aber wir können es besser machen, indem wir nur die Polyfills importieren, die in der Codebasis verwendet werden. Die Option "useBuiltIns: "usage" ist unser erster Versuch, so etwas zu ermöglichen (docs).

Sie durchläuft jede Datei und fügt einen Import am Anfang jeder Datei ein, wenn dieser built-in im Code „verwendet“ wird. Zum Beispiel:

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

Die Inferenz ist nicht perfekt, so dass es falsch-positive Ergebnisse geben kann.

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

Weitere Ideen in diesem Bereich sind die Verwendung von polyfill.io, wenn Sie sich auf einen Dienst verlassen können (oder lesen Sie, wie Kent C. Dodds verwendet hat, um einen gehosteten Dienst bei PayPal zu erstellen).

Sonstiges

Babel-Makros 🎣

Einer der besten Teile von Babel ist die Plug-in-Fähigkeit des Tools. Im Laufe der Jahre hat sich Babel von einem reinen „6to5“-Compiler zu einer Code-Transformationsplattform entwickelt, die einige fantastische Optimierungen für Benutzer und Entwickler ermöglicht. Tausende von Babel-Plugins wurden für bestimmte Bibliotheken und Anwendungsfälle entwickelt, um die Leistung und die Fähigkeiten von Bibliotheks-APIs zu verbessern, die sonst nicht möglich wären (einige „Bibliotheken“ werden vollständig transpiliert, was zu keinerlei Laufzeit führt).

Unglücklicherweise erfordert das Hinzufügen dieser Plugins zu Ihrer Codebasis eine Änderung der Konfiguration (was einige Toolkits wie create-react-app nicht zulassen), und es erhöht die Komplexität Ihres Codes, da die Entwickler wissen müssen, welche Babel-Plugins auf eine Datei wirken, um zu wissen, was mit dem Code passiert, den sie schreiben. Diese Probleme wurden durch babel-plugin-macros von Kent C. Dodds gelöst!

Wenn babel-plugin-macros einmal installiert und zu Ihrer Konfiguration hinzugefügt wurde (es ist in create-react-app v2 enthalten), brauchen Sie sich nicht mehr um Ihre Konfiguration zu kümmern, um Makros zu verwenden. Darüber hinaus ist es sogar noch einfacher, eigene benutzerdefinierte Transformationen für Anwendungsfälle zu schreiben, die spezifisch für Ihre Anwendung oder einen Teil Ihres Codes sind.

Erfahren Sie mehr über babel-plugin-macros in unserem ursprünglichen Beitrag „Zero-config code transformation with babel-plugin-macros“.

Module Targeting

Babel hat immer versucht, die Auswirkungen von Transformationen auf die Größe und die Möglichkeiten, die sie JavaScript-Autoren bieten, auszugleichen. In Babel 7 ist es viel einfacher geworden, Babel so zu konfigurieren, dass es die wachsende Popularität des Modul/Nomodul-Musters unterstützt.

Insbesondere mehrere CLI-Tools für beliebte Web-Frameworks (1, 2) nutzen bereits die Unterstützung, was zu einer etwa 20-prozentigen Verringerung des ausgelieferten JavaScript für die Benutzer von Anwendungen führt, die von Babel umgesetzt werden.

Anrufer-Metadaten und bessere Standardeinstellungen

Wir haben eine caller-Option zu @babel/core hinzugefügt, damit unsere Werkzeuge Metadaten an Voreinstellungen/Plugins weitergeben können. Zum Beispiel: babel-loader kann so etwas hinzufügen, so dass preset-env die Modultransformation automatisch deaktivieren kann (dasselbe gilt für rollup:

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

Das ist spannend, da es eine Möglichkeit für das Tooling bietet, bessere Standardeinstellungen und weniger Konfiguration bereitzustellen! Für den Fall von webpack/rollup: Wir können automatisch ihre Modultransformation anstelle der von Babel verwenden (dasselbe mit import("a")). Halten Sie Ausschau nach weiteren Werkzeugen, die dies in Zukunft ausnutzen!

class C extends HTMLElement {}

Eines unserer ältesten Probleme bekommt eine eigene Überschrift (Details)

Babel hatte immer den Vorbehalt, dass es die Erweiterung von nativen Built-Ins (Array, Error, etc.) nicht unterstützen konnte, und jetzt kann es das! Wir haben eine Menge Probleme damit bekommen; 🎉 du solltest feiern wie Andrea!

Diese Änderung wurde am Klassen-Plugin vorgenommen, so dass es automatisch aktiviert sein sollte, wenn du preset-env verwendest.

Website-Änderungen 🌏

Wir haben unsere Website von Jekyll nach Docusaurus verlegt!

Wir sind immer noch dabei, Übersetzungen mit Crowdin einzurichten, und mit der Veröffentlichung von Babel 7 werden wir in einer besseren Position sein, um diesen Prozess zu beginnen.

REPL

Wir haben die REPL als React Component neu geschrieben und mit Ives an einer besseren Integration mit CodeSandbox gearbeitet. Dies ermöglicht es, jedes Plugin oder Preset von npm in der REPL zu installieren und alle Updates zu erhalten, die CodeSandbox erhält.

Wir nehmen wieder am Rails Girls Summer of Code teil! Diesmal haben Gyujin und Sujin hart daran gearbeitet, Boopathis babel-time-travel in die REPL zu integrieren, was man jetzt schon testen kann!

Es gibt so viele Möglichkeiten, sich einzubringen, damit Babel, ASTs und andere Tools besser funktionieren!

Wir haben einen Song 🎶

Hallelujah-In Praise of Babel

Eines Tages hat Angus uns gnädigerweise einen Song zukommen lassen, den ich großartig fand, warum also nicht unseren „offiziellen“ Song daraus machen? Und Shawn hat ein geniales Cover gemacht.

Den Song findet ihr in unserem Repo unter SONG.md. Wir hoffen, dass andere Projekte diesem Beispiel folgen werden!

Was kommt als nächstes?

  • Babel ist von Natur aus an das gebunden, was es kompiliert: JavaScript. Solange es neue Ergänzungen gibt, an denen man arbeiten kann, gibt es dort Arbeit zu tun. Dazu gehört auch die Zeit und der Aufwand, die Syntax zu implementieren und zu pflegen, noch bevor sie „stabil“ wird. Wir kümmern uns um den gesamten Prozess: den Aktualisierungspfad, die Einarbeitung in neue Funktionen, das Lehren von Standards/Sprachdesign, die Benutzerfreundlichkeit und die Integration mit anderen Projekten.
    • Zu diesem Thema: wir sind fast fertig mit der Implementierung des neuen Vorschlags für Dekoratoren in Babel, dank Nicolò. Es war ein langer Weg (es hat mehr als ein Jahr gedauert!), denn der neue Vorschlag ist völlig anders und viel mächtiger als der alte, aber er ist fast fertig 🎉. Ihr könnt davon ausgehen, dass es in einer der nächsten Minor-Versionen veröffentlicht wird, zusammen mit einem Blog-Post, der die Änderungen im Detail erklären wird.
  • Boopathi hat sich fleißig um babel-minify gekümmert, also werden wir als nächstes eine 1.0 dafür machen!
  • Es sind viele neue Funktionen in Arbeit: Plugin-Bestellung, bessere Validierung/Fehler, Geschwindigkeit, Überdenken von loose/spec-Optionen, Caching, asynchrone Verwendung von Babel, Bauen gegen sich selbst aus CI, Smoke-Tests, Ausführen von test262. Schauen Sie sich diese Roadmap für einige weitere mögliche Ideen an!

Wir haben keine geheimen Pläne: wir versuchen das Beste, was wir können, mit dem, was wir haben, um dieser Gemeinschaft zu dienen.

Open Source ist ein Spiegel

Ich würde mich freuen, wenn wir die Zeit und die Ressourcen hätten, um all diese Ideen zu verwirklichen und es gut zu machen. Aber wie wir mit dieser aktuellen Version gezeigt haben, dauern die Dinge viel länger als erwartet!

Warum dauern diese Versionen überhaupt so lange? Liegt es daran, dass wir und unsere Benutzer immer mehr Funktionen benötigen? Liegt es daran, dass wir nicht wissen, wie wir unter all den möglichen Dingen, die wir hinzufügen oder reparieren können, Prioritäten setzen sollen? Die Entscheidung, niedrig hängende Früchte zu beheben, anstatt grundlegende Probleme bis zum Ende aufzuschieben? Oder „Ablenkungen“ von der Hilfe für andere auf GitHub, Slack, Twitter? Schätzen wir unsere Zeit einfach schlecht ein, verstehen wir die Komplexität dieser Probleme nicht, engagieren wir uns als Freiwillige zu sehr?

Oder setzen wir einfach zu hohe Erwartungen an uns selbst, oder fühlen wir uns von anderen so unter Druck gesetzt, dass wir auf Kosten unserer selbst Leistung erbringen und uns an ihre Bedürfnisse anpassen müssen? Ich kann es nur als Grauen beschreiben, wenn ich eine Nachricht von jemandem online sehe, der sich fragt, warum etwas noch nicht veröffentlicht wurde, während ein anderer fragt, warum dieser Fehler noch nicht behoben ist. Ich möchte es einfach nur schnell herausbringen und damit fertig werden, aber ich habe auch den Wunsch, die Sache ernst zu nehmen.

Ich habe versucht, einige dieser Gedanken und Kämpfe in meinem Vortrag letzte Woche bei der React Rally auszudrücken: Through the (Open Source) Looking Glass, von dem ich hoffe, dass Sie die Gelegenheit nutzen können, ihn sich anzuhören. Die Frage, die ich mir stelle: Was kann ich gegen den unvermeidlichen Kreislauf von Burnout, ständiger Angst und unrealistischen Erwartungen tun?

Wie vieles im Leben spiegeln die Dinge, die wir tun, unseren Charakter wider und zeigen uns, wie wir wirklich sind. Die Handlungen, die wir unternehmen, können uns selbst verändern, zum Guten oder zum Schlechten. Wenn wir unsere Arbeit ernst nehmen, sollten wir uns gegenseitig für diese Gewohnheiten, die in unserer Kultur so fest verankert zu sein scheinen, zur Rechenschaft ziehen: sofortige Befriedigung, Erfolg in Form von Metriken, Anspruch statt Dankbarkeit und Stolz auf Überarbeitung.

Aber trotz alledem hat sich die Arbeit an dieser Veröffentlichung so sehr gelohnt.

Danke

Das ist wirklich eine aufregende Veröffentlichung, nicht nur, wenn man zurückblickt, was wir erreicht und ermöglicht haben, sondern viel mehr, wenn man weiß, wie viel Zeit und Herzblut im letzten Jahr in die Entwicklung gesteckt wurde. Es ist kaum zu glauben, welche Gelegenheiten und Erfahrungen sich auf diesem Weg ergeben haben: Ich habe mit Unternehmen aus der ganzen Welt interagiert und ihnen geholfen, ich habe in fast jeder Stadt, die ich besucht habe, Freunde gefunden, und ich spreche ehrlich über die unglaubliche Reise, die diese Gruppe gemeinsam unternommen hat.

Persönlich habe ich noch nie so viel meiner geistigen Energie in etwas dieser Größenordnung gesteckt, und ich möchte so vielen Menschen dafür danken, dass sie uns auf diesem Weg unterstützt haben. Mein besonderer Dank gilt Logan Smyth, der unzählige Stunden damit verbracht hat, so viel an der Funktionsweise des Kerns zu ändern, und der sich immer die Zeit nimmt, in unserem Slack so hilfreich zu sein, während er gleichzeitig freiberuflich arbeitet, sowie Brian Ng, der sich in großem Maße um die Pflege von Babel und die Überprüfung all meiner Blogbeiträge und Vorträge gekümmert hat. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo und Justin Ridgewell haben alle maßgeblich dazu beigetragen, dass diese Version möglich ist und die Arbeit daran Spaß macht.

Ein Lob an all die vielen Community-Mitglieder auf Slack, Twitter und in allen Projekten auf GitHub, die auch verstehen müssen, was wir für ihre eigenen Benutzer tun. Ich möchte meinen Freunden bei Behance/Adobe dafür danken, dass sie mich fast ein Jahr lang gesponsert haben, damit ich halbtags an Babel arbeiten konnte, bevor ich mich für eine Vollzeitstelle entschied (und dass sie mir während der gesamten Zeit geholfen haben, Babel 7 in der Produktion zu testen). Ein großes Dankeschön an alle unsere Sponsoren für unser Open Collective, insbesondere Trivago und Handshake. Und vielen Dank an unsere Freunde und Familie für all ihre Liebe und Unterstützung.

Wir sind alle ziemlich müde, aber es war wirklich eine Ehre und ein Privileg, auf diese Weise zu dienen, und wir hoffen, dass Sie die Veröffentlichung zu schätzen wissen!