什么是通用模块定义（UMD）？

Question

我找到了（？）UMD 的 github 存储库，它附带了这个描述（强调我的）：

JavaScript 模块的

UMD（通用模块定义）模式在任何地方都能工作。

...

该存储库正式化了 JavaScript 模块的通用模块定义 (UMD) API 的设计和实现。这些模块能够在任何地方工作，无论是在客户端、服务器还是其他地方。

到目前为止，这很简单。至少我认为是的。 Node.JS 默认使用 CommonJS。浏览器默认使用全局变量。我认为这说明无论你的模块系统如何，UMD 都可以工作；您可以构建一次项目，而不是每个模块系统构建一次。

但是接下来的一切让我感到困惑：

UMD 模式通常尝试提供与当今最流行的脚本加载器（例如 RequireJS 等）的兼容性...

这不是和上一段矛盾吗？ UMD 您是在任何地方工作，还是只在最流行的环境中工作？

它继续列出至少九个“变体”可供选择。如果这意味着“通用”，为什么会有“任何”变化？我如何确定哪一种适合我的情况？ 自述文件写得好像我已经知道这些问题的答案，但我正在尝试了解 UMD 的用途以及何时使用它。

注意：

这个类似的问题

询问的是其他模块系统，但不是UMD。

---

存储库旨在形式化

通用模块

Answer 1

定义

，它不提供通用定义。当时编写该标准是因为每个人都以不同的方式定义了他们的通用模块 - 有一些通用的方法，对不同环境的支持不同，但没有真正建立。 正如您已经引用的那样，通用模块可以在多种环境中工作。在通用模块出现之前，库会为不同的环境分发单独的文件，例如library.amd.js、

library.common.js

和

library.global.js

。这对于维护人员来说是一个很大的麻烦，因为它需要使用构建工具（JavaScript 通常不需要）和额外的文档。因此，目标是定义一个通用模块，一个单一文件，这是作者编写和分发以及用户（下载）下载所需的全部内容。请注意，这是在包管理器和存储库常见之前（或者：当它们开始变得更流行时，您必须将库更改为模块来支持它们）。然而，仍然存在差异。为 Web 浏览器编写的模块不需要考虑支持 commonjs 格式，因为它们无论如何都无法在 Nodejs 中工作。没有依赖项的模块不需要支持 require 的 UMD 模式。不使用循环依赖的模块不需要支持可变

exports

对象的模式。您可以在

UMD 存储库

中记录模式的注释中找到这些差异及其权衡的解释。图书馆作者可以去那里，通读它们，然后选择正确的一个。