Я заметил это в кодовой базе моей компании, и у нее 30 миллионов загрузок в неделю, поэтому мне интересно узнать о ее важности.



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


regenerator-runtime — это поддержка среды выполнения для скомпилированных/транспилированных async функций. (У него вполне могут быть и другие применения, но это преобладает.)
Когда вы используете такой компилятор, как Babel, который компилирует современный JavaScript в более ранний JavaScript (процесс, иногда называемый транспилированием), одна из вещей, которую вы можете сделать, — это скомпилировать async функции во что-то, что будет работать на движках JavaScript, которые не поддерживают async функции (такие как как все более неактуальный IE11). Babel выполняет преобразование синтаксиса, но полученный код зависит от поддержки среды выполнения от regenerator-runtime.
@ezio — Babel не контролирует, какие script файлы вы включили в свою страницу/приложение, это не его работа; его работа заключается в преобразовании кода из A в B. Но упаковщик (например, Webpack или Rollup и т. д.), настроенный для работы с Babel, автоматически включит поддержку во время выполнения, потому что это его работа.
@T.J.Crowder извините за мое невежество, новичок в экосистеме js, но что здесь означает поддержка среды выполнения?
@ezio - Не нужно извиняться, здесь много движущихся частей. :-) Включение скрипта в среду выполнения. Babel переписывает код функции async в код, используя regenerator-runtime (в любом файле кода, где появляется функция async), но сама regenerator-runtime должна быть включена только один раз, а не для каждого файла. Таким образом, вы включаете его (если вам это нужно) в тег script на результирующей странице.
@ T.J.Crowder, в чем смысл включения этого руководства? Почему это не автоматизировано (установщиком)?
@PEZO - я думаю, что сборщики в целом делают это. Но Babel этого не делает, потому что это требует более широкого обзора вашей кодовой базы.
тогда почему он не включен в babel, раз он так важен?