Мы приближаемся к выпуску 7.0 Babel. Вот все крутые вещи, которые мы делали.

1656679246 my priblizhaemsya k vypusku 70 babel vot vse krutye veshhi

Генри Чжу

1*vLtFVPTHJGDfw3XOl4C1Sw
Фотография «My Life Through A Lens» на Unsplash

> Через 6 месяцев фактический релиз https://twitter.com/left_pad/status/1034204330352500736!

Привет?! Я Генри, один из сопровождающих Babel.

> РЕДАКТИРОВАТЬ: я оставил Behance и создал Patreon, чтобы попытаться продолжить работу с открытым кодом на полный рабочий день, пожалуйста, подумайте о пожертвованиях (спросите свою компанию).

Краткое вступление в Babel

Некоторые люди любят думать о Babel как инструменте, который позволяет писать код ES6. Вернее, компилятор JavaScript преобразует код ES6 в ES5. Это было очень кстати, когда его название было 6to5, но я думаю, что Babel стал гораздо больше, чем это.

Теперь давайте немного восстановимся. Причина, почему это вообще необходимо, заключается в том, что в отличие от большинства языков на сервере (даже Node.js) версия JavaScript, которую вы можете запускать, зависит от конкретной версии вашего браузера. Поэтому неважно, используете ли вы новейшие браузеры, если ваши пользователи (которых вы хотите сохранить) все еще используют IE. Если вы хотите написать class A {} например, вам не повезло — некоторое количество ваших пользователей получит a SyntaxError и белой странице.

Вот почему был создан Babel. Это позволяет написать нужную версию JavaScript, зная, что она будет работать правильно во всех (старших) браузерах, которые вы поддерживаете.

Но это не только «ES6» (некоторые любят называть ES2015). Babel, безусловно, расширил свою начальную цель только компилировать код ES6, и теперь компилирует любую версию ES20xx, которую вы хотите (последнюю версию JavaScript), в ES5.

Продолжающийся процесс

Одной из интересных вещей в проекте является то, что пока добавляется новый синтаксис JavaScript, Babel нужно будет реализовать преобразование для его преобразования.

Но вы можете подумать, почему мы должны отправлять скомпилированную версию (большего размера кода) в браузеры, поддерживающие этот синтаксис? Как мы вообще узнаем какой синтаксис поддерживает каждый браузер?

Ну, мы сделали babel-preset-env чтобы помочь с этой проблемой, создав инструмент, позволяющий указать, какие браузеры вы поддерживаете. Он автоматически трансформирует только то, что эти браузеры не поддерживают нативно.

Кроме того, Babel (по его использованию в сообществе) имеет место во влиянии на будущее самого языка JavaScript! Учитывая, что это инструмент для трансформации кода JS, его можно использовать для реализации любых предложений, поданных в TC39 (Технический комитет Ecma 39, группа, продвигающая JavaScript как стандарт).

Существует целый процесс, который проходит предложение, от стадии 0 до стадии 4, когда она попадает в язык. Babel как инструмент находится в правильном месте, чтобы испытать новые идеи и побуждать разработчиков использовать его в своих программах, чтобы они могли предоставить отзыв комитета.

Это действительно важно по нескольким причинам: комитет хочет быть уверенным, что вносимые ими изменения отвечают потребностям сообщества (последовательные, интуитивно понятные, эффективные). Реализация неопределенной идеи в браузере является медленной (C++ в браузере против JavaScript в Babel), дорогой и требует от пользователей использования флажка в браузере вместо изменения файла конфигурации Babel.

Поскольку Babel настолько вездесущ, есть хорошая вероятность того, что произойдет его реальное использование. Это сделает предложение гораздо лучше, чем если бы его просто реализовали без проверки со стороны сообщества разработчиков.

И это не только полезно на производстве. Наш онлайн-REPL полезен для людей, изучающих сам JavaScript, и позволяющий им тестировать вещи.

Я считаю, что Babel имеет отличную позицию в качестве образовательного инструмента для программистов, чтобы они могли продолжать изучать, как работает JavaScript. Участвуя в самом проекте, они изучат многие другие концепции, такие как AST, компиляторы, спецификация языка и т.д.

Я очень в восторге от будущего проекта и не могу дождаться, куда команда может уйти. Пожалуйста, присоединяйтесь и помогите нам!

Моя история

Вот некоторые из причин, почему я испытываю восхищение работать над этим проектом каждый день, особенно как сопровождающий. Большинство нынешних сопровождающих, включая меня, не создавали проект, а присоединились через год — до сих пор головокружительно думать, с чего я начинал.

Что касается меня, то я признал потребность и интересный проект. Я медленно и последовательно участвовал в этом, и теперь я смог заставить своего работодателя Behance спонсировать половину моего времени на Babel.

Иногда «обслуживание» означает только исправление ошибок, ответы на вопросы в Slack или Twitter или написание журнала изменений (это действительно зависит от каждого из нас). Но в последнее время я снизил свое внимание на исправлении ошибок и создании функций. Я потратил некоторое время на размышления над вопросами более высокого уровня, например: какое будущее этого проекта? Как мы развиваем наше сообщество с точки зрения количества сопровождающих по сравнению с количеством пользователей? Как мы можем поддерживать проект с точки зрения финансирования? Какое место мы занимаем в экосистеме JavaScript в целом (образование, TC39, инструменты)? И можем ли мы играть какую-либо роль в помощи новым людям присоединиться к открытому коду (RGSoC и GSoC)?

Из-за этих вопросов меня больше всего волнует этот выпуск – это не обязательно детали в наборе функций (которых много: начальные реализации новых предложений, таких как Pipeline Operator (a |> b), новый стиль TypeScript с помощью команды TS и файлов .babelrc). js).

Скорее я в восторге от того, что представляют все эти функции: целый год упорной работы, чтобы не сломать все, сбалансирование ожиданий пользователей (почему сборка такая медленная/выход кода так велик, чем код не соответствует спецификациям). достаточно, почему это не работает без конфигурации, почему нет опции для x), и поддерживает солидную команду в основном волонтеров.

И я знаю, что наша отрасль сосредоточена на «основных выпусках», раскрученных функциях и звездах, но это лишь один исчезающий день. Я хотел бы предложить нам продолжать думать о том, что нужно, чтобы быть последовательным в продвижении экосистемы вперед здоровым способом.

Это может означать просто размышления об умственном и эмоциональном бремени сопровождающего судна. Это может означать подумать о том, как обеспечить наставничество, управление ожиданиями, советы по балансу между работой и личной жизнью и другие ресурсы для людей, желающих присоединиться, вместо того, чтобы просто поощрять разработчиков ожидать немедленной бесплатной помощи.

Погружение в журнал изменений

Что ж, надеюсь, вам понравится длинный журнал перемен? Если вы заинтересованы в том, чтобы помочь нам, сообщите нам, и мы будем рады поговорить дальше.

0*zvhm_vD3VWFaWA1c

Мы запустили новую страницу видео, поскольку люди хотели узнать больше о том, как работает Babel, и внести свой вклад. Эта страница содержит видео выступлений на конференции о Babel и связанные концепции членов команды и людей из сообщества.

0*8q5nV1APkAFKydrZ

Мы также создали новую страницу! В будущем мы будем обновлять эту страницу, добавляя больше информации о том, над чем работают люди и почему они вовлечены. Для такого большого проекта много способов привлечься и помочь.

Вот некоторые основные моменты и краткие факты:

  • 28 сентября 2017 года Бабелю исполнилось 3 года!
  • Даниэль шевельнулся babel/babylon и babel/babel-preset-env к основному монорепо Babel, babel/babel. Это включает всю историю Git, метки и проблемы.
  • Мы получили 1 тыс. долларов в месяц от Facebook Open Source!
  • Это самое большое ежемесячное пожертвование, которое мы получали с самого начала (следующее самое большое пожертвование составляет 100 долларов США в месяц).
  • Между тем, мы используем наши средства, чтобы встретиться лично и отправить людей на встречи TC39. Эти встречи проходят каждые 2 месяца по всему миру.
  • Если компания хочет что-нибудь спонсировать, мы можем создать отдельные проблемы для отслеживания. Раньше это было тяжело, потому что нам приходилось платить из своего кармана или искать конференцию, чтобы выступить на той же неделе, чтобы покрыть расходы.

Как вы можете помочь

Если ваша компания хочет отдай назад поддерживая фундаментальную часть развития JavaScript и его будущее, подумайте о пожертвованиях нашему Open Collective. Вы также можете пожертвовать время разработчика, чтобы помочь поддерживать проект.

№1: Помогайте поддерживать проект (время разработчика на работе)

Лучше всего для Babel это найти людей, которые готовы помочь с проектом, учитывая огромный объем работы и ответственности, которые он требует. Опять же, я никогда не чувствовал себя готовым быть сопровождающим, но однажды наткнулся на это. Но я только один человек, а наша команда состоит только из нескольких человек.

№2: Помогите финансировать развитие

Мы точно хотим иметь возможность финансировать людей в команде, чтобы они могли работать полный рабочий день. Логан, в частности, оставил свою работу некоторое время назад и использует наши текущие средства для работы над Babel неполный рабочий день.

#3 Внести свой вклад иным образом?

К примеру, Ангус сделал для нас официальную песню!

Обновление

Мы также работаем над инструментом обновления, который поможет переписать файлы package.json/.babelrc и т.д. В идеале это означает, что он изменит все необходимые изменения номера версии, переименования пакетов и изменения конфигурации.

Пожалуйста, свяжитесь с тем, чтобы помочь и сообщить о проблемах при попытке обновления. Это прекрасная возможность присоединиться и помочь обновить экосистему!

Итог предыдущего поста

  • Нет поддержки Node 0.10/0.12/5.
  • Обновлены предложения TC39
  • Цифровой разделитель: 1_000
  • Дополнительный оператор цепочки: a?.b
  • import.meta (разборный)
  • Дополнительная привязка Catch: try { a } catch {}
  • BigInt (анализный анализ): 2n
  • Разделить расширение экспорта на export-default-from и export-ns-form
  • .babelrc.js поддержка (конфигурация с использованием JavaScript вместо JSON)
  • Добавлен новый стиль Typescript и разделены стили React/Flow
  • Добавлена ​​поддержка фрагментов JSX и различные обновления Flow
  • Снял внутрь babel-runtime зависимость для меньшего размера

Недавно обновленные предложения TC39

  • Оператор трубопровода: a |> b
  • Бросить выражения: () => throw 'hi'
  • Оператор Nullish Coalescing: a ?? b

Устаревшие стандартные настройки в год (например, babel-preset-es20xx)

TL; DR: использование babel-preset-env.

Что может быть лучше, чем вам придется решать, какой пресет Babel использовать? Сделаем это автоматически!

Несмотря на то, что объем работы, затрачиваемый на поддержку списков данных, огромен — опять же, почему нам нужна помощь, это решает многие проблемы. Это гарантирует, что пользователи в курсе спецификации. Это означает меньше путаницы с конфигурацией/пакетом. Это означает более простой путь обновления. А это значит меньше проблем по поводу того, что есть что.

babel-preset-env на самом деле хорошая старый стиль, заменяющий любой другой стиль синтаксиса, который вам понадобится (es2015, es2016, es2017, es20xx, последний и т.д.).

0*wgAjmRI1MVcI_Veg

Он компилирует последний ежегодный выпуск JavaScript (независимо от этапа 4), заменяющий все старые стили. Но он также имеет возможность компилировать в соответствии с целями, которые вы указываете: он может обрабатывать режим разработки, например последняя версия браузера, или несколько сборников, таких как версия для IE. Он даже имеет другую версию для вечнозеленых браузеров.

Не удалить предварительные настройки Stage (babel-preset-stage-x)

Мы всегда можем поддерживать его в актуальном состоянии, и, возможно, нам просто нужно определить лучшую систему, чем текущие настройки.

Предварительные настройки этапов — это только список плагинов, которые мы вручную обновляем после каждой встречи TC39. Чтобы сделать это управляемым, нам нужно разрешить основные ошибки версий для этих «нестабильных» пакетов. Это отчасти потому, что сообщество все равно создаст эти пакеты заново. Поэтому мы могли бы сделать это из официального пакета, а затем иметь возможность предоставлять лучшие сообщения.

Переименовывает: ограниченные пакеты (@babel/x)

Вот опрос, который я проводил почти год назад:

Тогда не так много проектов использовали пакеты с ограниченной областью, поэтому большинство людей даже не знали об их существовании. Возможно, тогда вам пришлось заплатить за аккаунт npm org, тогда как сейчас он бесплатный (также поддерживает пакеты без ограничений).

Проблемы с поиском ограниченных пакетов решены и подсчет загрузок работает. Единственным оставшимся камнем преткновения является то, что некоторые посторонние реестры все еще не поддерживают пакеты с ограниченной областью. Но я думаю, что мы находимся на том этапе, когда ждать этого кажется довольно глупо.

Вот почему мы предпочитаем пакеты с ограниченными возможностями:

  • Именовать сложно: нам не придется проверять, решил ли кто-то другой использовать наше соглашение об именовании для своего собственного плагина
  • У нас есть подобные проблемы с приседаниями пакетов
  • Иногда люди создают babel-preset-20xx или какой-то другой пакет, потому что это смешно. Мы должны сделать выпуск и отправить электронное письмо, чтобы попросить его вернуть.
  • У людей есть законный пакет, но он, как оказывается, совпадает с названием, которое мы хотели бы назвать.
  • Люди видят, что новое предложение объединяется (например, необязательная цепочка или оператор конвейера), и решают разделить и опубликовать его версию под тем же названием. Затем, когда мы публикуем, это сообщает нам, что пакет уже опубликован? Поэтому мне нужно найти их электронную почту и отправить им и службе поддержки npm, чтобы вернуть пакет и повторно опубликовать его.
  • Что такое «официальный» пакет и что такое пакет пользователя/сообщества с таким же названием? Мы получаем отчеты о проблемах людей, которые используют неправильно названные или неофициальные пакеты, поскольку они предполагали, что это часть Babel. Одним из примеров этого был отчет о том, что babel-env переписывал их .babelrc файл. Им понадобилось время, чтобы понять, что это не так babel-preset-env.

Итак, кажется вполне понятным, что мы должны использовать пакеты с ограниченной областью видимости, и если что, мы должны были сделать это гораздо раньше?!

Примеры ограниченного изменения названия:

  • babel-cli -> @babel/cli
  • babel-core -> @babel/core
  • babel-preset-env -> @babel/preset-env

Переименовывает: -proposal-

Любые предложения будут названы -proposal- теперь указать, что они еще не официально в JavaScript.

Поэтому @babel/plugin-transform-class-properties становится @babel/plugin-proposal-class-propertiesи мы вернули бы ему название, если он попадет на Этап 4.

Переименовывает: удаление рока из названия плагина

Предыдущие плагины имели год в названии, но сейчас это не нужно.

Поэтому @babel/plugin-transform-es2015-classes становится @babel/plugin-transform-classes.

Поскольку годы использовались только для es3/es2015, мы ничего не изменили с es2016 или es2017. Однако мы не поддерживаем эти стили в пользу preset-env, а для редакции литерала шаблона мы просто добавили его в литерал шаблона transform для упрощения.

Одноранговые зависимости и интеграции

Мы вводим одноранговые зависимости от @babel/core для всех плагинов (@babel/plugin-class-properties), пресеты (@babel/preset-env), а также пакеты верхнего уровня (@babel/cli, babel-loader).

peerDependencies – это зависимости, которые, как ожидается, будет использовать ваш код, в отличие от зависимостей, которые используются только как детали реализации. — Стейн де Витт через StackOverflow.

babel-loader уже имел a peerDependency на babel-coreпоэтому это просто меняет его на @babel/core. Это изменение предотвращает попытку установки этих пакетов на неправильную версию Babel.

Для инструментов, которые уже имеют a peerDependency на babel-core и не готовы к большому удару (поскольку изменение одноранговой зависимости является критическим изменением), мы опубликовали новую версию babel-core чтобы преодолеть изменения с помощью новой версии babel-core@7.0.0-bridge.0. Для получения дополнительной информации просмотрите этот вопрос.

Так же пакеты, как gulp-babel, rollup-plugin-babelи так далее у всех раньше было babel-core как зависимость. Теперь у них просто будет a peerDependency на @babel/core. Благодаря этому эти пакеты не должны передавать основные версии, когда @babel/core API не изменился.

#5224: самостоятельная публикация экспериментальных пакетов

Я вспоминаю об этом в Вавилонской державе в Versioning См. раздел. Вот проблема Github.

Возможно, вы помните, что после Babel 6 Babel стал набором пакетов npm с собственной экосистемой пользовательских пресетов и плагинов.

Однако с тех пор мы всегда использовали «фиксированную/синхронизированную» систему управления версиями (таким образом, ни один пакет не имеет версии 7.0 или выше). Когда мы делаем новый выпуск, например v6.23.0 , только пакеты, которые имеют обновленный код в источнике, публикуются с новой версией. Остальные пакеты остаются как есть. Это в основном работает на практике, поскольку мы используем ^ в наших пакетах.

К сожалению, система этого типа требует выпуска основной версии для всех пакетов, как только в ней требуется один пакет. Это либо означает, что мы вносим много мелких критических изменений (ненужных), либо объединяем многие критические изменения в один выпуск. В то же время мы хотим различать экспериментальные пакеты (Stage 0 и т.п.) и все остальное (es2015).

Поэтому мы намерены внести основные изменения в любые экспериментальные плагины предложений, когда спецификация изменится, а не ждать обновления всего Babel. Таким образом, все, что < Этап 4, будет открыто для разрушительных изменений в форме основной версии. То же касается самых предварительных настроек Stage (если мы не отбрасываем их полностью).

Это согласуется с нашим решением потребовать использования плагинов предложения TC39 -proposal- название. Если спецификация изменится, мы обновим основную версию плагина и предварительной настройки, к которой он принадлежит (в отличие от того, чтобы просто создать версию исправления, которая может сломаться для людей). Затем нам нужно будет отменить поддержку старых версий и настроить инфраструктуру, которая будет автоматически обновлять людей, чтобы они были в курсе того, какой станет спецификация (и чтобы они не застряли на чем-то. Мы не были так повезло с декораторами.).

The env вариант в .babelrc не устаревает!

В отличие от предыдущего сообщения мы только исправили поведение слияний, чтобы быть более согласованным.

Конфигурация в env имеет более высокий приоритет, чем корневые элементы конфигурации. И вместо удивительного подхода простого использования обоих, плагины и стили теперь объединяются на основе их идентичности, поэтому вы можете сделать это:

{
  presets: [
    ['env', { modules: false}],
  ],
  env: {
    test: {
      presets: [
         'env'
      ],
    }
  },
}

с BABEL_ENV=test . Это заменит корневую конфигурацию env конфигурацией из test, не имеющей параметров.

Поддержка class A extends Array (старейшая оговорка)

Babel автоматически обернет любые родные встроенные компоненты, например Array, Errorи HTMLElement так что это работает только при компиляции классов.

скорость

preset-env: "useBuiltins": "usage"

babel-preset-env представил идею компиляции синтаксиса для разных целей. Он также представлен через useBuiltIns возможность добавлять только полизаполнения, не поддерживаемые целями.

Итак, с этой опцией что-то вроде:

import "babel-polyfill";

может превратиться в

import "core-js/modules/es7.string.pad-start";
import "core-js/modules/es7.string.pad-end";
// ...

если целевая среда поддерживает полизаполнение, отличные от padStart или padEnd.

Но чтобы сделать это еще лучше, мы должны импортировать только полизаполнения, которые используются в самой кодовой базе. Зачем импортировать padStart если он даже не используется в коде?

"useBuiltins": "usage" это наша первая попытка рассмотреть эту идею. Он выполняет импорт в верхней части каждого файла, но добавляет импорт только если обнаруживает, что он используется в коде. Этот подход означает, что мы можем импортировать минимальное количество полизаполнений, необходимых для программы (и только если целевая среда не поддерживает это).

Так что если вы используете Promise в вашем коде он импортирует его в верхней части файла (если ваша цель этого не поддерживает). Пакетчики будут дедуплировать файл, если он одинаков, поэтому этот подход не приведет к импортированию нескольких полизаполнений.

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

import "core-js/modules/es7.array.includes";
[].includes
a.includes

С помощью вывода типа мы можем знать, такой ли метод экземпляра .includes для массива или нет. Наличие ложного положительного результата – это нормально, пока эта логика не станет лучше, поскольку это все равно лучше, чем импортировать весь полифил, как раньше.

Различные обновления

  • babel-template более быстрый и более простой в использовании
  • regenerator был выпущен под лицензией MIT – это зависимость, которая используется для компиляции generators/async
  • «ленивый» вариант для modules-commonjs плагин через #6952
  • Теперь можно использовать envName: "something" в .babelrc или передайте через cli babel --envName=something вместо того, чтобы использовать process.env.BABEL_ENV или process.env.NODE_ENV
  • ["transform-for-of", { "assumeArray": true }] чтобы все циклы for-of выводились как обычные массивы
  • Исключить transform-typeof-symbol в свободном режиме для preset-env #6831
  • Получил PR для лучших сообщений об ошибках с синтаксическими ошибками

Задание перед выпуском

  • ручка .babelrc поиск (это нужно сделать до первого выпуска RC)
  • Поддержка переопределения: другая конфигурация на основе шаблона glob
  • Кэширование и логика недействительности в babel-core.
  • Лучшая история вокруг внешних помощников.
  • Либо введите, либо создайте план управления версиями и обработки полизаполнений независимо от помощников, чтобы мы не были явно привязаны к core-js 2 или 3. Люди могут иметь вещи, которые зависят от того или иного, и они не захотят загружать оба много времени.
  • Либо рабочая реализация декоратора, либо функциональная устаревшая реализация с четким путём к текущему поведению спецификаций в течение жизни 7.x.

Спасибо

Приветствие нашей команде волонтеров:

Логан очень настойчиво пытался решить многие наши основные проблемы относительно конфигураций и т.д. Он тот, кто проделывает всю эту тяжелую работу.

Брайан берет на себя обслуживание большого количества предварительно настроенных env, а что я делал раньше?

Дэниел всегда вмешивался, когда нам нужна была помощь, будь то поддержка babel-loader или помощь в переносе репо babylon/babel-preset-env. То же с Николо, Свеном, Артемом и Диого, которые в прошлом году пришли на помощь.

Я очень жду выхода (я тоже устал – почти год прошел?). Но я тоже не хочу ничего спешить просто потому. В течение этого выпуска было много взлетов и падений, но я, конечно, многому научился, и я уверен, что остальная команда тоже.

И если я хоть чему-то научился в этом году, мне следует прислушаться к этому совету, а не просто писать об этом.

Также спасибо Марико за легкий толчок, чтобы фактически завершить эту публикацию (2 месяца работы)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *