Skip to content
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

Closed
justinfagnani opened this issue May 27, 2016 · 3 comments
Closed

Support for native web JS modules? #1860

justinfagnani opened this issue May 27, 2016 · 3 comments

Comments

@justinfagnani
Copy link

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?

@guybedford
Copy link
Member

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.

@justinfagnani
Copy link
Author

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.

@guybedford
Copy link
Member

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants