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

Investigate ES6 modules as our internal components #5828

Open
kripken opened this Issue Nov 22, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@kripken
Owner

kripken commented Nov 22, 2017

(Forked off from #5794 (comment) )

As a long-term goal, it would be nice if emscripten output

  • Fit in with node.js packaging in a natural way.
  • Fit in with ES6 build system tools.
  • Were overall as modular as possible.

Those might be achievable by splitting all or most of the JS we currently emit into ES6 modules. So the GL code might be such a module, etc. Less obvious how the runtime would, but could be possible.

This is not something we can do right now (in particular, not all browsers support ES6 modules, and wasm integration there is farther out), but in the linked issue above we discuss various refactorings, and it could be useful to keep the ES6 modular goal in mind, so that we are working towards that.

We'll need to do a bunch of investigation along the way, including

  • Code and compile time implications of such changes. In theory compile-time tools can merge ES6 modules and remove the overhead (of imports etc.), but we should verify that (e.g., it might remove imports but leave more JS objects or IIFEs around as "namespaces"), and we'll need to see how fast those things are.
  • How such modularization would work with our various build flag options (separate module for GL vs GL emulation? or at compile time like now? etc.).
  • How it would fit with our EM_ASM and js-library options.
  • Look at Rust's new approach to how JS and wasm integrate. Still early there, but we should see what they do and how it goes.
@kripken

This comment has been minimized.

Owner

kripken commented Nov 22, 2017

One possible way towards this may be

  • Allow JS libraries to be ES6 modules.
  • Move more things into JS libraries.
@lukewagner

This comment has been minimized.

Contributor

lukewagner commented Nov 27, 2017

That sounds like the right first incremental steps. Additional incremental steps could be:

  • Create some notion of "package" that is a collection of .h, .cpp, and .js files that can be explicitly depended on by other packages.
    • The .js files would be ES modules, importable by the .cpp files.
    • Static linking of multiple packages would simply collect all the .js files from all the packages and optionally merge them into a single .js module with a tool like webpack or rollup.
  • Allow packages to be compiled in a "clean" environment in which the only code they can #include and link against are packages they've explicitly included as dependencies.
  • Break up all standard Emscripten runtime/libraries/glue-code into fine-granularity packages
    • Provide a compatibility mode/flag/command that implicitly depends on all the standard packages, thereby preserving today's behavior
  • Build up a workflow for creating packages, publishing packages to a package manager (e.g., npm), and installing external packages

Following this to its logical conclusion (which may require some of the breaking changes described in #5794 to avoid otherwise-unpackage-able JS glue code) would I think lead to the end state described in my #5984 comment.

@saschanaz

This comment has been minimized.

Collaborator

saschanaz commented Nov 29, 2017

I think we may use ES2015 modules (and even any ES2015+ syntax) before browser support with Babel+Webpack dependency. Both depends on Node.js we already have so probably okay to have them together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment