javascript - 分发具有依赖项的可重用 JavaScript 模块的最佳方式是什么？

Question

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。

据我所知:

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

有没有计划来应对这种奇怪的安排？对我来说，拥有不知道如何命名其模块的模块系统似乎有点疯狂。我错了吗？

Answer 1

您可能需要查看 jspm.io + SystemJS这是一个相对较新的包管理器和通用模块加载器，越来越受欢迎。

请在下面找到一些我认为对主题有用的演示文稿和文章:

https://www.youtube.com/watch?v=MXzQP38mdnE ,

https://vimeo.com/65042246 ,

https://www.youtube.com/watch?v=szJjsduHBQQ ,

http://javascriptplayground.com/blog/2014/11/js-modules-jspm-systemjs/