外部脚本中的全局 polyfill 破坏网站功能的风险是什么？

Question

@babel/polyfill 的文档有以下注释：

如果您正在寻找不会修改要在工具/库中使用的全局变量的东西，请查看 transform-runtime 插件。

在transform-runtime 文档中，它说如下：

虽然这种 [@babel/polyfill 用法] 对于应用程序或命令行工具来说可能没问题，但如果您的代码是一个您打算发布给其他人使用的库，或者您不能完全发布，这就会成为问题控制代码运行的环境。

更一般地说，很多解释 polyfill 使用的文章都说，可能希望使用不同的解决方案如果你关心污染全局命名空间。

据我了解，大多数 polyfill 都是有条件地加载的。如果一个实现已经存在，polyfill 不会覆盖它。我的问题是：在什么情况下，外部脚本中的 polyfill 会导致现有网站崩溃？到目前为止，我能够找到的唯一原因是外部脚本可能会比网站本身的代码更早地加载 polyfill。这可能会导致问题，但是当这些 polyfill 基于 Web 标准时，它们的行为应该是相同的。仍然存在严重冲突的可能性有多大？

我在github issue 上发现了一个有趣的讨论。不过，这里主要讨论的是 NPM 生态系统中的模块，而我最感兴趣的是促进小部件或嵌入之类的外部脚本。

感谢任何个人经验或有关该主题的讨论和文章的链接！

更新：这个问题的主要原因之一是转换运行时存在一些问题。随着 core-js 和 babel 的新版本，这些问题似乎已经得到解决。无论如何，我仍然对上述原始问题的答案感兴趣。

Answer 1

嗯，polyfills 很少完美，正如你所说，它们几乎都是有条件的。

假设 library-1 为一个名为 Interface 的功能注入了自己的 polyfill (polyfill-A)。
这个polyfill-A可以很好的实现Interface完整API的几个方法，比如官方API可能是这样的

interface Interface {
  constructor(optional (Interface or DOMString) foo);
  undefined doSomething();
  undefined doSomethingElse();
};

但是在构造函数中传递Interface 实例可能只是稍后才在规范中添加，或者doSomethingElse 可能已被该polyfill 省略，或者根本没有正确测试，所有这些小遗漏可能都很好library-1 因为他们不使用任何这些。
现在，当 library-2 自己的 polyfill 将检查是否已经有一个 Instance 构造函数可用时，它会看到是的，它已经定义了，因此不会重新实现它。
但是，library-2 可能需要在构造函数中传递一个接口，或者它可能需要调用其doSomethingElse() 方法。当它尝试这样做时，代码会崩溃，因为即使 library-2 的作者确实包含了一个可以正确实现这两个功能的 polyfill，library-1 的 polyfill 实现是可运行且可访问的。

<script>
  // library-1.js
  (function polyfillInterface() {
    if (typeof Interface !== "function") {
      class Interface {
        constructor(foo) {
          this.foo = foo.toUpperCase();
        }
        doSomething() {
          return this.foo + "-bar";
        }
      }
      globalThis.Interface = Interface;
    }
  })();
  {
    // for library-1, everything works well
    const instance = new Interface("bla");
    console.log(instance.doSomething());
  }
</script>

<script>
  // library-2.js
  (function polyfillInterface() {
    if (typeof Interface !== "function") {
      class Interface {
        constructor(foo) {
          if (foo instanceof Interface) {
            this.foo = foo.foo;
          }
          else if (typeof foo === "string") {
            this.foo = foo.toUpperCase();            
          }
          else {
            throw new TypeError("neither an Interface nor a DOMSrting");
          }
        }
        doSomething() {
          return this.foo + "-bar";
        }
        doSomethingElse() {
          return this.foo.toLowerCase() + "-bar";
        }
      }
      globalThis.Interface = Interface;
    }
  })();
  {
    // for library-2, everything is broken
    const instance_1 = new Interface("bla");
    try {
      console.log(instance_1.doSomethingElse());
    }
    catch(err) {
      // instance_1.doSomethingElse is not a function
      console.error(err);
    }
    // TypeError: foo.toUpperCase is not a function
    const instance_2 = new Interface(instance_1);
  }
</script>

这可能是很难确定的事情，例如Promise.then() 应该在同一个事件循环中触发，而不是在它们解决的事件循环中（在微任务队列中），而不是像正常任务那样在下一个事件循环中触发，并且很多Promise 库可能一直在使用 setTimeout(fn, 0) 来实现异步性，而不是在可用时使用 MutationObserver。

这就是为什么在编写库时，最好链接到 polyfill，但不要自己包含它们。