There are many ways to format JavaScript modules: AMD, CommonJS, UMD, ES6, global script. I saw projects that structure the source code the way they want, and start the build process to create a dist directory that contains code in all of the above formats. This has the advantage that the user of the code can simply choose the format that is most applicable to his environment.
This method works fine as long as the module is not dependent on other modules. When modules need to import other modules, complications are implied. For example, RequireJS uses a configuration file that looks like this:
requirejs.config({ paths: { 'jquery': 'js/lib/jquery', 'ember': 'js/lib/ember', 'handlebars': 'js/lib/handlebars', 'underscore': 'js/lib/underscore' } });
Other bootloaders have equivalent mechanisms for mapping import paths.
If jQuery is a dependency, should the module import it from the jquery path? What if the system into which it is included stores jQuery in the "libs / jquery" path? In this case, the responsibility of the author of the system, including jQuery, is to provide aliases in the configuration of the import path?
This survey strongly suggests that a truly reusable module should provide code that is formatted in all module formats, and clearly identify which libraries (and their versions) depend on it, and document which import paths these libraries are supposed to use.
For example, I could create a fancy jQuery plugin that I distribute to AMD, CommonJS, ES6 and global variants. I would write that this plugin depends on jQuery version 2.0, imported along the path "jquery_on_a_path_that_confuses_you". A future user of this plugin should copy the plugin into his project, and then configure his module loader or build tool to export jQuery along the path "jquery_on_a_path_that_confuses_you".
As far as I can tell:
- There is no standard to use for import paths.
- There is no standard way to express dependency, version, and import requirements for a piece of code for a user.
- There is no standard way to deal with import conflicts or download multiple versions of a library.
Is there any plan to resolve this strange arrangement? It seems a little crazy to me to have modular systems that don't know what to name their modules. I'm wrong?