该存储库旨在正式化 * 通用模块 * 的 * 定义 *。它没有提供一个“普遍的定义”。这个标准是在当时编写的，因为每个人都以不同的方式定义他们的通用模块-有一些通用的方法，对不同的环境有不同的支持，但没有真正建立起来。
正如您已经引用的那样，通用模块可以在多种环境中工作。在通用模块之前，库将为不同的环境分发单独的文件，例如。library.amd.js、library.common.js和library.global.js。这对维护人员来说是一个很大的麻烦，因为它需要使用构建工具（JavaScript通常不需要）和额外的文档。因此，我们的目标是定义一个通用模块，一个单一的文件，这是作者编写和分发以及用户（下载）加载所需的全部内容。请注意，这是在包管理器和存储库通用之前（或者：当它们开始变得更流行时，你必须把你的库变成一个模块来支持它们）。
然而，仍然存在差异。为web浏览器编写的模块不需要考虑支持commonjs格式，因为它们在nodejs中不起作用。没有依赖关系的模块不需要支持require的UMD模式。不使用循环依赖的模块不需要支持可变exports对象的模式。您可以在记录UMD repository中模式的注解中找到这些差异的解释及其权衡。一个图书馆的作者可以去那里，通读它们，然后选择正确的一个。
当然，这一切都是历史。今天，构建工具无处不在。您可以将代码编写为现代ES模块，并让您的编译器解决其余的问题。对于库作者，你可以将你的包作为一个esm文件包分发。
然而，对于前端库，您仍然提供了一个方便的文件，用户可以下载（从CDN）并直接嵌入到他们的网页中。这仍然通常采用UMD模式，只是不再由库作者编写/复制到源代码中，而是由编译器/编译器自动添加。
类似地，对于应该在node.js中工作的后端/通用库，您仍然通过npm分发commonjs模块构建，以支持所有仍然使用旧版本node.js的用户（并且不希望/需要自己使用转译器）。这对于新的库来说现在已经不太常见了，但是现有的库会努力保持向后兼容，而不会导致应用程序崩溃。