Closed lextiz closed 7 years ago
Wouldn't this be a new proposal? I don't think this kind of thing would be restricted to only dynamic imports. Seems way more useful for static imports since you can implement this yourself easily with dynamic imports as you show in your examples.
https://stackoverflow.com/questions/29168433/es6-variable-import-name-in-node-js Is this feature is applicable to static imports? Would they stay statically analyzable? Do I miss something?
Right, this is indeed a new proposal, and isn't an issue with this proposal, so I'll close this. Thanks for your interest, though.
We're interested in exploring different specifier -> URL mapping, especially for bare module specifiers, but that's an intrinsically host-specific operation; it's outside the scope of the ECMAScript spec.
For HTML, you may be interested in following https://github.com/whatwg/html/issues/2640. (Although unfortunately that thread has been hijacked so that most of the recent comments are very long exposes on a separate proposal from one web developer, which do not respect the constraints of the OP.) Someone else may be able to give you pointers for Node.js.
Proposal: add support for mapping between module name and path (URL)
When the URL of the module is not known at runtime, but the module name is known (web applications with plugins) the map configuration of some module loaders is very handy (e.g. https://github.com/systemjs/systemjs/blob/master/docs/getting-started.md#map-config, http://requirejs.org/docs/api.html#config-paths). The ability to resolve specific module name to different URLs is important for large and pluggable web applications.
Assumption
As far as I understand, after dynamic import is available in browsers I could write something like this:
Motivation
Easy handling of common code base (server and front-end) for pluggable applications:
In case same module needs to be loaded from one place in browser (lets say CDN) and from other place in server environment (let's say node_modules, resolved from module name), the naive approach would look like:
common-code.js
Instead of: browser-only.js
common-code.js:
Consider another example: common-code.js
This example represents portable, but very ugly code that could be implemented on top of dynamic import.