Каковы компромиссы при написании обычных модулей узлов в ES6 с рабочим процессом babel?

#node.js #npm #ecmascript-6 #babeljs

#node.js #npm #ecmascript-6 #babeljs

Вопрос:

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

Я хотел бы начать разработку этих «обычных» модулей, также используя babel transformers, но я могу предвидеть недостатки этого, в том числе:

  • Это может препятствовать рабочему процессу отладки (в частности, при работе с IDE)
  • Производительность модуля может пострадать

Каково текущее состояние в этом вопросе — как вы считаете, имеет смысл использовать babel в обычных модулях, учитывая вышеупомянутые и другие компромиссы? Каковы плюсы / минусы для вашего предпочтительного рабочего процесса?

Бонусный вопрос: Назовите несколько авторитетных модулей и / или авторов модулей, которые уже используют эту технику? Я видел, как Facebook делает это для своей экосистемы react, но я думаю, это имеет смысл, поскольку это в основном модули для браузера.

Комментарии:

1. Это во многом зависит от функций, которые вы собираетесь использовать.

2. В основном синтаксический сахар, такой как распространение объектов и т. Д., А также более понятное управление потоком с использованием async / await.

3. На самом деле это не повлияет на производительность, хотя (особенно для async / await) преобразование может быть интенсивным, поэтому вам нужно попробовать себя, подходят ли для этого ваши инструменты отладки.

Ответ №1:

Он преобразуется обратно в ванильный JS (эту часть выполняет babel). Что вы получаете, так это то, что вы можете использовать классы, которые я нашел полезными.

Надеюсь, со временем браузеры будут поддерживать ES6, и нам не понадобится babel.

Единственным недостатком является то, что при отладке вам приходится создавать исходную карту, но это временно, см. Выше.

Чтобы ответить на ваш второй вопрос: я использую React на одном из веб-сайтов, и большинство модулей, которые мне нужны (из npm), используют ES6.

Ответ №2:

Я считаю, что упомянутые вами компромиссы или недостатки не относятся к разработке кода nodejs с использованием babel в качестве транспилятора ES7. Лично я считаю использование функций ES7 с node чрезвычайно продуктивным.

Для отладки имеется поддержка карты исходного кода. Я использую karma для тестирования, и он поставляется с отличной поддержкой карты исходного кода (я использую IntelliJ, но я считаю, что подойдет большинство IDE). Вы можете проверить этот репозиторий REST-API на github. Это хороший стек для построения серверной части данных nodejs. Он использует karma для тестирования — даже поставляется с поддержкой покрытия кода. Он также интегрируется с pm2 для масштабирования и доступности.

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