Каков риск того, что глобальные полифилы во внешнем скрипте нарушат функциональность сайта?

Question

Документация для @ babel / polyfill содержит следующее примечание:

Если вы ищете что-то, что не изменит глобальные переменные, которые будут использоваться в инструменте / библиотекеИзвлеките плагин transform-runtime .

В документации transform-runtime указано следующее:

Хотя это [@ babel / polyfill using] может быть подходящим для приложения или инструмента командной строки, оно становится проблемой, если ваш код представляет собой библиотеку, которую вы собираетесь публиковать для использования другими пользователями, или если вы не можете точно контролировать средув котором будет выполняться ваш код.

Вообще говоря, многие статьи, объясняющие использование полифиллов, говорят, что использование может хотеть использовать другое решение , если вызаботиться о загрязнении глобального пространства имен .

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

Я нашел интересную дискуссию по этому поводу по проблеме github .Это в основном говорит о модулях в экосистеме NPM, тогда как в основном меня интересуют внешние скрипты, которые облегчают такие вещи, как виджеты или встраивания.

Любой личный опыт или ссылки на обсуждения и статьи по теме приветствуются!

ОБНОВЛЕНИЕ: Одна из основных причин этого вопроса состоит в том, что были некоторые проблемы с transform-runtime.В новой версии core-js и babel эти проблемы, похоже, решены.Несмотря на это, я все еще заинтересован в ответах на оригинальный вопрос выше.

Answer 1

Ну, полифилы редко бывают идеальными, и, как вы говорите, они почти все работают условно.

Если мне нужно что-то из polyfillX , то polyfillY не нужно реализовывать, скажем, Promise.then() должен запускаться в том же цикле событий, что и они, а не в следующий, как обычное событие, и что lib1 загружен polyfillY первый, который только лениво исправляет его, используя setTimeout (0) вместо использования MutationObserver, когда доступно, что может быть хорошо для lib1 , которая не нуждалась в этой функции, но тогда мой polyfillX не включится, и нужной функции I не будет.

Так что я ожидаю, что мои Обещания будут работать так, как они должны быть обмануты тем фактом, что они этого не сделают, все из-за того, что lib1 решил для меня, какой полифилл включить.

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