-
-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for native web JS modules? #1860
Comments
It's interesting that jspm 0.16 does actually rewrite the imports in Node modules so that they work as URLs - adjusting the directory requires and adding js extensions where necessary. We actually moved away from this in jspm 0.17 to support linking workflows and in order to have the conversion be configuration-only. jspm itself is not compatible with this kind of rewriting because the whole concept is that jspm_packages is immutable. If we hardcode in resolved dependencies where [email protected] depends on [email protected] then when [email protected] is released we need to alter the sources of [email protected] to the new references. This is why a loader resolution mechanism is used to allow these references to be independent of their exact resolution and handle resolution through configuration. There's definitely a lot of scope for more exploration of the rewriting techniques though. There may well be a number of interesting and useful approaches from CDNs to build workflows that could enable workflows of Node code with native ES modules. The perspective of jspm though is that the edge cases of loading all modules in the browser requires a dynamic resolution system / loader, and we're building based on those requirements. |
Interesting. I think with native module loading and HTTP/2+push, it'll become increasingly feasible to distribute applications without bundling. Beyond preserving ES module semantics, and being more cache-friendly, there are certain ordering dependencies in HTML that will only be properly implemented if the browser does all the loading. Custom module resolution and loading seems a long way off right now, unless consensus is reached unexpectedly soon, so I think it'd be really great to have some workflow that actually enables using the node ecosystem with native module loading. I suppose I'll play around with an npm frontend that does import/require rewriting. |
The more work we have in this area the more informed the module workflows of the future will be - I'm all for lots of projects exploring the area. Just let me know if you ever want to discuss the details of CommonJS circular references with respect to this :) |
With native support for JS modules coming to browsers soon, it would be great to be able to load existing node modules directly into browsers with no polyfills or user-land loaders. The problem is that node modules will not work as is, as the web loader will only support loading modules by URL, not name (see whatwg/html#443 ).
To use existing modules, they would need a transform on installation to resolve names and rewrite imports. jspm seems philosophically close to this approach, though rather than rewrite source it looks like it builds a SystemJS configuration. Would you consider an alternate mode where imports are rewritten in place of the of SystemJS configuration?
The text was updated successfully, but these errors were encountered: