分发具有依赖项的可重用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/