Почему в производстве не следует использовать babel-w630?

babel- node docs несут строгое предупреждение:

Не предназначен для использования в производстве

Вы не должны использовать babel-node в процессе производства. Это излишне тяжело, с высоким использованием памяти из-за того, что кеш хранится в памяти. Вы также всегда будете испытывать штраф за запуск, поскольку все приложение должно быть скомпилировано на лету.

Давайте сломаем это:

  • Использование памяти - да? Все модули "кэшируются" в памяти в течение всего срока службы вашего приложения. Что они здесь получают?

  • Старт-аут - как это проблема производительности? Развертывание веб-приложения уже занимает несколько секунд (или минут, если вы тестируете в CI). Добавление половины времени к запуску ничего не значит. Фактически, если время запуска имеет значение где угодно, это имеет большее значение в развитии, чем производство. Если вы перезагружаете свой веб-сервер достаточно часто, чтобы время запуска было проблемой, у вас возникли гораздо большие проблемы.

Кроме того, нет такого предупреждения об использовании Babel потребовать hook (require('babel-register')) в производстве, хотя это, по-видимому, делает в значительной степени точно так же, как babel- node. Например, вы можете сделать node -r babel-register server.js и получить то же поведение, что и babel-node server.js. (Моя компания делает это именно в сотнях микросервисов, без проблем.)

Является ли Babel предупреждением только FUD, или я что-то упускаю? И если предупреждение действительно, почему он также не применим к Вавилону, требуется перехват?

Связанный: Можно ли использовать babel- node в производстве? - но этот вопрос просто спрашивает, рекомендуется ли использовать производство, а ответы просто цитируют официальный совет, т.е. "Нет". Напротив, я ставил под сомнение обоснование официального совета.

Ответы

Ответ 1

babel- node

Предупреждение о производстве было добавлено для разрешения этой проблемы:

Без модуля kexec вы можете попасть в действительно уродливую ситуацию, когда ребенок_процесс умирает, но его смерть или ошибка никогда не пузырится. Для получения дополнительной информации см. https://github.com/babel/babel/issues/2137.

Было бы здорово, если бы в docs на babel-w631 объяснили, что он не предназначен для производства и что без установки kexec у него плохое поведение.

(акцент мой)

Ссылка на исходный номер # 2137 мертва, но вы можете найти здесь здесь.

Таким образом, здесь есть две проблемы:

  • "очень большое использование памяти в больших приложениях"
  • "без установки kexec, что у него плохое поведение"

Эти проблемы приводят к предупреждению о производстве.

Бабель-регистр

Кроме того, нет такого предупреждения о том, что использование Babel требует hook (require ('babel-register')) в производстве

Не может быть предупреждения, но это не рекомендуется. См. эта проблема:

babel-register в первую очередь рекомендуется для простых случаев. Если у вас проблемы с ним, кажется, что изменение рабочего процесса на один, построенный вокруг наблюдателя файлов, будет идеальным. Обратите внимание, что мы также никогда не рекомендуем babel-register для производственных случаев.

Ответ 2

Я не знаю достаточно о babel и node внутренних, чтобы дать полный ответ; некоторые из них - это спекуляция, но кэширование babel-w631 будет делать не то же самое, что делает кеш node.

Кэш-память

babel- node - это еще один кэш поверх node требует кеша, и в лучшем случае он должен кэшировать полученный исходный код (до того, как он будет отправлен на node).

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

Штраф за запуск будет зависеть от содержимого вашего .babelrc, но вы вынуждаете babel выполнять работу с ногами, чтобы переводить весь исходный код каждый раз, когда он выполняется. Даже если вы реализуете постоянный кеш, babel- node все равно нужно выполнить выборку и проверку кеша для каждого файла вашего приложения.

В разработке более подходящие инструменты, такие как webpack в режиме просмотра, после холодного запуска могут повторно транслировать только измененные файлы, что будет намного быстрее, чем даже babel- node с идеально оптимизированным кэшем.