What is the best way to distribute reusable JavaScript modules with dependencies? -
There are several ways to format the JavaScript module: AMD, CommonJS, UMD, ES6, Global Script I saw those projects All the sources that structure their source code and run a build process to create a dist directory with code in all the above formats. The advantage of this is that whatever format the user of the code can choose, is most applicable to his environment.
This method works fine as long as the module does not have any dependencies on other modules. In cases where the modules should import other modules, there are implicit complications. For example, RequireJS uses a config file that looks like this:
requirejs.config ({path: {'jquery': 'js / lib / jquery', 'ember': 'Js / lib / amber', 'handlers': 'js / lib / handlar', 'underscores': 'js / lib / underscore'}});
Other loaders have similar mechanisms for mapping the import paths.
If jQuery is a dependency, should it import the module from the 'jquery' path? What if the system on which it is being stored on store 'Libs / Jquery'? In this case, is it the responsibility of the author of the system, in which jQuery can be included to provide the nickname in the configuration of the import path?
This question strongly suggests that in reality the reusable modules should be formatted in all modules, clearly defined formats and documents, which libraries (and its versions) What is the basis and what are the documents on which the existence of those libraries is considered.
For example, I can write a fancy jQuery plugin, which I distribute, AMD, CommonJS, ES6 and global variations I document that this plugin is imported through 'jquery_on_a_path_that_confuses_you' JQuery version depends on version 2.0. The user using this plugin will have to copy the plugin into its project and then configure your module loader or create tools to export jQuery to 'jquery_on_a_path_that_confuses_you'.
As far as I can tell:
- There is no standard for what to use for import paths.
- There is no standard way to express the dependencies, versions, and import path requirements for the user of one piece code.
- There is no standard solution to struggle with import paths or to load multiple versions of the library.
Is there any plan to deal with this weird system? For me this is a module system that does not know the name of its module, am I wrong?
You can check that there is a relatively new package manager and universal module loader
< P>,,
,
,
Comments
Post a Comment