[Feature] Multiple source file/string support for generated Playground compiler

[phated]

Currently, the playground takes a single source string (passed to compile()) and produces JS output. This requires tools that support multiple files (like https://github.com/phated/reasonable and codesandbox/codesandbox-client#850) to guess at the dependency list/order before wrapping each source file in module syntax and concatenating them together, which is then passed to the compile() method. Currently, both tools are using a custom compiled version of BuckleScript by @jaredly and then doing their own module resolution.

If the playground had support for registering multiple source strings (maybe by a module name?) before calling compile(), I think all of that previous dance could be avoided.

Hypothetical API:

window.ocaml.registerModule("Foo", "...");
window.ocaml.registerModule("Bar", "...");
window.ocaml.registerModule("Baz", "..."); // Uses Foo and Bar modules
window.ocaml.compileModules();

Thoughts?

[jaredly]

My fork supports this
https://github.com/jaredly/bucklescript/blob/playground-latest/jscomp/core/jsoo_main_refmt.ml#L243
Compiled at https://github.com/jaredly/redoc/blob/master/static/bs-3.0.0.js

[phated]

@jaredly you still need to determine module order external to the BuckleScript compiler, correct?

For Reasonable, I have to do a lot of cross-process communication to achieve module ordering and the correct compilation order. I was hoping for a delayed compilation phase.

[jaredly]

the native bucklescript compiler doesn't even do automatic ordering. bsb does that.
Why do you need cross-process communication?

[phated]

@jaredly It's just the way v8worker2 (ryan dahl's project which is used in Reasonable) is architected.

the native bucklescript compiler doesn't do automatic ordering. bsb does that.

I didn't realize that. I don't suppose it could be moved around?

[jaredly]

The API that you describe could 100% be written in userland, how bout we do that first?

[phated]

@jaredly is that different than what CodeSandbox is doing in the linked PR?

[jaredly]

somewhat different in that it doesn't use the compile_module api

[phated]

@jaredly So I'm experimenting with the compile_module API as you've suggested but I believe you lose the ability to add interfaces to the source code (I could be wrong here). compile_module doesn't require a file to be wrapped in the module Foo = {} syntax, so if you then wrap the file contents in module to attach an interface, you end up with a nested module namespace (e.g. Foo.Foo.name) - Thoughts?

[phated]

Scratch that, I think I found the syntax needed to solve the above.

Does this work? In Foo.re

module type Foo = {
  /* interface stuff */
};

/* implementation stuff */

[bobzhang]

I wrote a commonjs loader which can load files pretty fast: https://github.com/BuckleScript/bucklescript/blob/master/jscomp/bsb/templates/react-lite/loader.js

[phated]

@bobzhang that's not quite what I was asking for. I wanted something that would estimate dependencies before the ocaml code was compiled - the linked project seems to be a JS loader.

[phated]

Following @jaredly's suggestions (though not using compile_module because the behavior seemed weird and segfaulty), I've implemented this in JS at https://github.com/phated/reasonable/blob/deps/bs/run.js

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.