Явный выбор экспериментальных предложений

1656570139 yavnyj vybor eksperimentalnyh predlozhenij

Генри Чжу

1*XmHUL5DeySv_dGmvbPqdDQ

Развивая версию 7, мы решили, что лучше прекратить публиковать прессы Stage в Babel (например,@babel/preset-stage-0).

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

Немного истории

Babel — это список плагинов для совместного использования.

Официальные пресеты Babel Stage отслеживали процесс TC39 Staging для новых предложений синтаксиса JavaScript.

Каждый предварительно установленный (напр. stage-3, stage-2и так далее) включили все плагины для этого конкретного этапа и находящиеся над ним. Например, stage-2 включены stage-3и так дальше.

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

На самом деле мы добавили прессы Stage вскоре после выпуска Babel v6 (ранее это был флаг конфигурации в v5). Ниже показан старый пример.

Проблемы

Эти пресеты были удобным способом использовать то, что мы все хотели: новое, блестящее, еще не определенное будущее JavaScript.

Оглядываясь назад, это сработало очень хорошо! (Возможно, слишком хорошо?)

Слишком хорошая работа?

Такие языки как CoffeeScript и инструменты, такие как Traceur, помогли создать идею компиляции JavaScript. Babel сделал еще проще как использование нового/будущего синтаксиса, так и интеграцию с имеющимися инструментами. Ожидания изменились от скептицизма и обеспокоенности до полного принятия экспериментального.

Наверное, мы бы ни были там, где мы, если бы не широкое распространение компиляторов, таких как Babel: это ускорило использование (и обучение) ES2015 для значительно большей аудитории. Рост React усилил его использование, поскольку его синтаксис JSX, свойства класса и отдых/распространение объектов привели к тому, что люди узнали немного больше об этих предложениях по синтаксису.

Вавилон стал одноразовой установкой для людей, о которой больше никогда не думать. Он стал базовой инфраструктурой, скрытой за другими инструментами, пока не появилась. SyntaxError, проблемы зависимостей или проблемы интеграции Просто используйте stage-0.

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

Взад и вперед

В течение многих лет мы поднимали много вопросов, чтобы обсудить, что делать с пресетами сцены в #4914, #4955, #7770. Я даже писал в более старом сообщении о Babel 7.0, в котором говорилось, что мы не были их удаление?

Однако мы обнаружили, что сохранность пресетов Stage приведет к проблемам даже для самого Babel:

  • Была распространенная проблема, когда спрашивали что-то вроде: «Какие предварительные настройки нужны для использования асинхронных функций?» Людям было бы непонятно знать, что именно stage-0 означало, и мало кто смотрит на это package.json или источник.
  • Удаление плагина предложения на этапе 3 (после его перехода к этапу 4) действительно является критическим изменением. Эта проблема усугубляется, когда вы пытаетесь использовать @babel/preset-env чтобы не составлять предложение, поддерживаемое нативной системой.

«ES7 Декораторы»

Частично проблема состоит именно в том, чтобы называть вещи, и, как мы часто слышим, назвать вещи тяжело.

Для самого ES6 было много заглавий: Harmony, ES Next, ES6, ES2015. Когда люди слышат о новых идеях, имеет смысл просто выбрать последний номер и добавить в него название.

Вполне понятно, что это происходит, не отдавая себе в этом отчета, но продолжение этого ставит другие ожидания относительно того, как развивается речь. Нет ничего виноватого – мы учимся как сообщество и напоминаем друг другу о том, как работает JavaScript.

Джей Фелпс написал хорошую статью на эту тему. Он объясняет, что было бы лучше называть их по Стадии, на которой они сейчас находятся: Декораторы этапа 2 или просто Предложение декораторов.

Размышление состоит в том, что слово ES7 Decorators предполагает, что Decorators, как ожидается, будут в ES7. Я упоминал об этом в своей последней публикации по компиляции node_modules, но пребывание на определенном этапе не гарантирует многое: предложение может остановиться, вернуться назад или быть полностью удалено.

Мы хотели подчеркнуть этот факт, когда решили изменить названия плагинов предложений @babel/plugin-transform- к @babel/plugin-proposal-.

BabelScript

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

TC39 призывает быть осторожными при использовании предложений на этапе 2 или ниже, поскольку это может привести к непреднамеренному давлению со стороны сообщества, чтобы сохранить реализацию как есть вместо того, чтобы улучшать ее из-за опасений сломать существующий код или фрагментацию экосистемы (например, использование другого символа люблю # вместо @ для декораторов).

Люди шутят, что разработчики, использующие Babel, используют BabelScript вместо JavaScript, имея в виду, что когда плагин Babel создан для определенной функции, это должно означать, что он «исправлен» или уже официально часть языка (не соответствующая действительности). . . Для некоторых людей первой мыслью, когда они видят новый синтаксис/идею (этап «-1») является наличие плагина Babel для этого.

Установка ожиданий

После того, как компиляторы, такие как Babel, сделали обычной практикой для людей писать ES2015, разработчикам было естественным желание испытать еще новые и экспериментальные «функции». В Вавилоне это работало в использовании stage флаг в предыдущих версиях или stage-x предварительные настройки.

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

Еще много лет назад было много хороших обсуждений, но ориентироваться в этом было не самое простое: мы не хотели бы штрафовать пользователей, понимавших компромиссы, ставя console.warns во время его использования, а отсутствие возможности вообще казалось неразумным в то время.

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

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

Другие соображения

Мы также могли бы попробовать:

  • Переименуйте предыдущие настройки, чтобы лучше указать уровень стабильности (не решает проблему версий)
  • Лучшие стратегии версий: независимо версий пресетов и обновляйте их немедленно, когда это необходимо, возможно, использовать 0.x
  • Предупреждение/Ошибка для старых устаревших версий пресетов

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

Почему сейчас?

Почему бы не удалить его раньше? Заготовки Stage были частью Babel в течение многих лет, и были беспокойства по поводу добавления большей «сложности» к использованию Babel. Многие инструменты, документации, статьи и знания были созданы вокруг пресетов Stage. Раньше мы считали, что лучше официально поддерживать пресеты, поскольку кто-то другой неизбежно создаст их (и создаст).

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

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

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

Миграция

Для автоматической миграции мы обновили babel-upgrade, чтобы сделать это за вас (вы можете запустить npx babel-upgrade).

TL;DR состоит в том, что мы удаляем пресеты сцены. На определенном уровне людям придется выбирать и знать, какие виды предложений используются, вместо того чтобы предполагать, что люди должны использовать, особенно учитывая нестабильный характер некоторых из этих предложений. Если вы используете другой пресет или цепочка инструментов (например, create-react-app), возможно, это изменение не коснется вас напрямую.

Мы отказались от предварительных настроек этапа 7.0.0-beta.52. Если вы не хотите изменить свою конфигурацию сейчас, мы рекомендуем вам шпилька версии к beta.54 пока вы не можете обновить. После beta.54 мы выдадим ошибку с уведомлением, как перенести. И убедитесь, что все ваши версии одинаковы при предыдущем выпуске.

Как альтернатива, вы можете создать собственный пресет, содержащий те же плагины, и обновить их, как вам вздумается. В будущем мы можем захотеть поработать над a babel-init которые могут помочь вам настроить плагины в интерактивном режиме или обновить babel-upgrade для перечисления и добавления текущих плагинов Stage. Возможно, Babel должен оставаться инструментом низкого уровня и полагаться на другие инструменты высшего уровня/фреймворк, например create-react-app чтобы справиться с этим выбором для людей.

Предотвращение блокировки предложения

Джеймс ДиДжойя недавно написал пост об изменениях в использовании оператора трубопровода (|>).

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

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

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

Бремя поддержки экосистемы

«Бюджет синтаксиса» языка касается не только сложности самого языка, но может распространяться на инструменты. Каждое новое дополнение синтаксиса несет новое бремя для сопровождающих других проектов JavaScript.

Как только новый синтаксис будет предложен, многие вещи требуют обновления: анализаторы (babylon), выделение синтаксиса (language-babel), линтер (babel-eslint), тестовые рамки (jest/ava), формататоры (prettier), покрытие кода (istanbul), минимификаторы (babel-minify), и более.

Было много вопросов, затронутых в отношении таких проектов, как acorn, eslint, jshint, typescriptи другие, чтобы поддержать предложения этапа 0, поскольку они были в Вавилоне. Не так много проектов, которые придерживались бы политики, которая требовала бы от них поддержки любого предложения, поскольку поддерживать ее было бы чрезвычайно трудно. Во многом удивительно, что мы даже пытаемся справиться с этим в самом Babel, учитывая постоянные обновления и отток.

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

Babel взял на себя необычное бремя поддержки этих экспериментальных функций. В то же время целесообразно, чтобы другие проекты проводили более консервативную политику. Если вы хотите, чтобы во всей экосистеме поддерживались новые языковые функции, внесите свой вклад в TC39 и проект, чтобы перенести эти предложения на этап 4.

Будущее

Цель этого проекта – действовать как часть процесса TC39: быть ресурсом как для внедрения более новых (этап 0–2) предложений, так и для получения отзывов от пользователей, а также для поддержки старых версий JavaScript. Мы надеемся, что эта публикация проливает больше света на то, как мы стараемся лучше всего согласовать этот проект в экосистеме JavaScript. В скором времени мы выпустим RC для v7!

Если вы цените эту публикацию и работу, которую мы делаем над Babel, вы можете поддержать меня на Patreon, попросить свою компанию спонсировать нас на Open Collective или еще лучше привлечь свою компанию в Babel как часть своей работы. Мы будем благодарны за коллективную собственность.

С благодарностью всем рецензентам! Не стесняйтесь оставлять отзыв в Twitter.

Первоначально опубликовано на https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets.

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

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