В релизе babel@7.0.0-beta52 появился новый обязательный флаг конфига для плагина @babel/plugin-proposal-pipeline-operator, что ломает обратную совместимость для предыдущих версий плагина. Из этой статьи вы узнаете, что такое оператор pipeline и зачем ему нужна конфигурация. UPD: в babel@7.2.0 появились smart пайплайны: https://babeljs.io/blog/2018/12/03/7.2.0#smart-pipeline-operator-parsing-8289-https-githubcom-babel-babel-pull-8289 Gilbert Garza, изначально предложивший оператор pipeline, ставил целью получить простой синтаксис для «упорядоченных цепочек вызовов функций в удобочитаемом функциональном стиле». Оператор pipeline берёт своё начало в таких языках, как F#, Hack, Elm, Elixir и других, а при добавлении его в JavaScript возникают два спорных момента: Первый вопрос был поднят Кевин Смит в этом тикете, где он предложил использовать стиль пайплайнов из языка Hack. В Hack плейсхолдеры обязательны для любой правой части пайплайна, например: Мы взяли за основу то, что плейсхолдер может быть использован в любом выражении и содержит значение с прошлого шага пайплайна. Такой подход даёт нам гибкость и широкие возможности для составления выражений. Обратная сторона медали — усложнение языка из-за добавления нового токена. Пока что мы выбрали хеш (#), и, хотя дискуссия по-прежнему открыта, любой токен потенциально будет иметь пересечения с другими использованиями. Например хеш также используется приватными полями класса, как и любые другие варианты токена используются так или иначе. Первый вариант оператора pipeline содержал такой синтаксис для await: что может быть развёрнуто в: К сожалению, пользователи вполне могут ожидать и такого разворачивания: Пока буксовала сама идея добавления async в пайплайн, члены комитета высказались против оператора pipeline, который не поддерживает async / await. Да, есть варианты, как без явного синтаксиса работать с функциями, возвращающими Promise, но все эти варианты слишком громоздкие или требуют вспомогательных функций. В результате дискуссий сформировались два предложения (вдобавок к минимальному варианту): использовать F#-пайплайны и Smart-пайплайны. Давайте посмотрим на эти предложения. Это предложение касается только базовой функциональности. В минимальном варианте убрана поддержка асинхронности и нет плейсхолдеров. Такой вариант соответствует поведению babel-плагина предыдущих версий, до появления конфигурации, и соответствует текущей спецификации по оператору pipeline в репозитории. Он используется больше как черновик-пробник, чтобы выявить преимущества и недостатки других предложений, и вряд ли будет принят без кардинальных изменений, которые есть в альтернативных предложениях. Плейсхолдеры для F#-пайплайнов вообще не нужны. В базовом варианте стрелочные функции закрывают потребность в плейсхолдерах, требуя меньше писанины, да и основываются на привычном для всех синтаксисе ES2015. На текущий момент (по спецификации F#-пайплайнов) стрелочные функции должны быть обёрнуты в скобки: Полным ходом ведутся изыскания, чтобы определить, осуществимо ли использовать стрелочные функции без скобок, которые здесь выглядят синтаксически излишними. Что касается асинхронности, в F#- пайплайнах await работает как унарная функция: Что разворачивается в: и поэтому await может быть использован посреди длинной цепочки асинхронных вызовов: Такая специальная обработка await потенциально может открыть возможность похожим образом использовать другие унарные операторы (например, typeof), но исходная спецификация F#-пайплайнов не содержит их. Smar-пайплайны доводят идею плейсхолдеров до логического завершения, разрешая в пайплайнах как частичное применение, так и произвольные выражения. Предыдущая длинная цепочка может быть записана так: Правила использования плейсхолдеров в Smart-пайплайнах довольно просты. Если одиночный идентификатор передан в шаг пайплайна, то никакой дополнительный токен (плейсхолдера) не требуется, это называется «минималистским стилем» ("bare style"): В отличие от Hack, унарные функции не требуют токена плейсхолдера. Для других выражений плейсхолдер (называемый "lexical topic token" — «лексема тематического стиля») обязателен, а пайплайн считается работающим в рамках «тематического стиля» — "topic style". Отсутствие токена плейсхолдера в таком случае вызывает раннюю ошибку SyntaxError: Если имеются какие-либо операторы, скобки (в том числе для вызова метода), кавычки, или вообще что угодно, кроме идентификатора и точки, то токен плейсхолдера обязателен. Это поможет избежать выстрела себе в ногу и устранить неопределённость. Smart-пайплайны решают проблему поддержки асинхронности в более общем виде, что разрешает использовать в пайплайнах все возможные выражения, не только await, но и typeof, yield и любые другие операторы. Как только все три предложения были конкретизированы, мы пришли к выводу, что такие обсуждения не приведут к разрешению глубоких противоречий между предложениями. Мы решили, что лучший способ — собрать отзывы разработчиков, использующих предложения в реальном коде. С учётом роли Babel в сообществе разработчиков, мы решили добавить все три варианта в плагин оператора pipeline. Поскольку парсинг для всех трёх предложений незначительно, но отличается, их поддержка должна быть сначала добавлена в @babel/parser (который babylon), причём парсер должен знать, какое предложение нужно сейчас поддерживать. Таким образом плагин оператора pipeline требует опции "proposal", как для конфигурирования babylon для парсинга, так и для последующей трансформации. Мы работали над этим в оперативном режиме, потому что нам надо сделать все изменения, ломающие обратную совместимость, до того, как babel@7 перестанет быть бетой. Мы бы хотели в итоге сделать один из вариантов пайплайнов дефолтным для плагина, чтобы избавиться от необходимости в конфигурационной опции. Учитывая эти ограничения, мы решили добавить опцию в конфигурацию плагина и сделать её обязательной, принуждая пользователей решать, какое из предложений они хотят использовать в своём проекте. Как только конкретное предложение будет выбрано как каноническое поведение оператора, мы пометим опцию "proposal" как устаревшую, а канонический вариант станет работать по-умолчанию. Поддержка отменённых предложений будет работать до следующей мажорной версии. Если хотите участвовать в обсуждении предложения, то все обсуждения публичны и вы можете найти их в репозитории предложения оператора pipeline. К вашим услугам также презентация со встречи TC39. В конце концов, вы можете обратиться к James DiGioia, J. S. Choi или к Daniel Ehrenberg в твиттере. Но что гораздо важнее, как только работа над pipeline будет завершена, попробуйте его в своих проектах! Мы также работаем над добавлением новых возможностей в repl, так что вы сможете проверить свой код и в интерактивном режиме. Нам нужна обратная связь, и использование в реальном коде очень поможет её собрать. Отправляйте твиты на @babeljs. JavaScript Developer