分发带有依赖关系的可重用JavaScript模块的最佳方式是什么?

有很多格式化JavaScript模块的方法:AMD, CommonJS, UMD, ES6，全局脚本。我曾见过一些项目以他们想要的任何方式构建源代码，并运行构建过程来生成一个包含上述所有格式代码的dist目录。这样做的好处是，代码的用户可以选择最适用于其环境的格式。

只要模块不依赖于其他模块，这个方法就可以正常工作。在模块必须导入其他模块的情况下，存在隐含的复杂性。例如，RequireJS使用如下的配置文件:

requirejs.config({
    paths: {
        'jquery': 'js/lib/jquery',
        'ember': 'js/lib/ember',
        'handlebars': 'js/lib/handlebars',
        'underscore': 'js/lib/underscore'
    }
});

其他加载器也有相应的机制来映射导入路径。

如果jQuery是一个依赖，模块应该从路径' jQuery '导入它吗?如果系统将jQuery存储在路径"libs/jQuery"中怎么办?在这种情况下，集成jQuery的系统的作者是否有责任在导入路径的配置中提供别名?

这个问题强烈地暗示了一个真正可重用的模块必须提供所有模块格式格式的代码，并且清楚地记录它所依赖的库(及其版本)，并记录这些库被假定存在的导入路径。

例如，我可以编写一个花哨的jQuery插件，并在AMD、CommonJS、ES6和全局变体中发布。我会说明这个插件依赖于通过路径"jquery_on_a_path_that_confuses_you"导入的jQuery 2.0版本。这个插件的潜在用户必须将这个插件复制到他的项目中，然后配置他的模块加载器或构建工具，以在路径'jquery_on_a_path_that_confuses_you'下导出jQuery。

就我所知:

• 对于导入路径的使用没有标准。
• 没有标准的方式来表达一段代码的依赖、版本和导入路径要求。
• 没有标准的补救措施来处理导入路径冲突或加载多个版本的库。