Generator-based initialization function

[guybedford]

Based on discussion in https://github.com/bytecodealliance/jco/issues/375.

[whitequark]

Do you have an example of a generated file?

[guybedford]

Here's an example of the flavorful instantiation test output - https://gist.github.com/guybedford/06abf2ec8a17238e86413ce6af51487e.

[whitequark]

Here's an example of the flavorful instantiation test output - https://gist.github.com/guybedford/06abf2ec8a17238e86413ce6af51487e.

Sorry, I don't understand--this doesn't seem like it lets me pick instantiation style after the fact.

[guybedford]

@whitequark it implements an initialization function that is sync and only returns a promise if one of the instantiate hooks returns a promise, so solves your use case. As I say I have no horse in this race, I just thought it might help you.

[whitequark]

Oh I see--thanks, I got very confused due to the presence of asm.js code in the output and some of the stuff at the end. I think this will work for me--I can test that and report back.

[guybedford]

Great, please do, this needs a few tweaks to land still, so that feedback will help a lot to know if it's worth doing so!

[whitequark]

How do I actually test this? I.e. what do I put in my dependencies dictionary in package.json?

[whitequark]

I tried

"@bytecodealliance/jco": "git://github.com/bytecodealliance/jco#generator"

But I get this error that I don't know how to deal with:

> @yowasp/runtime-test@0.0.0 transpile
> jco new ../copy.wasm --wasi-command --output copy.wasm && jco transpile copy.wasm --instantiation sync --no-typescript --no-namespaced-exports --map 'wasi:io/*=runtime#io' --map 'wasi:cli/*=runtime#cli' --map 'wasi:clocks/*=runtime#*' --map 'wasi:filesystem/*=runtime#fs' --out-dir gen/

node:internal/errors:496
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/home/whitequark/Projects/yowasp/runtime-js/test/yowasp_runtime_test/node_modules/@bytecodealliance/jco/obj/wasm-tools.js' imported from /home/whitequark/Projects/yowasp/runtime-js/test/yowasp_runtime_test/node_modules/@bytecodealliance/jco/src/cmd/opt.js
    at new NodeError (node:internal/errors:405:5)
    at finalizeResolution (node:internal/modules/esm/resolve:327:11)
    at moduleResolve (node:internal/modules/esm/resolve:980:10)
    at defaultResolve (node:internal/modules/esm/resolve:1193:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:403:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:372:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:249:38)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:76:39)
    at link (node:internal/modules/esm/module_job:75:36) {
  url: 'file:///home/whitequark/Projects/yowasp/runtime-js/test/yowasp_runtime_test/node_modules/@bytecodealliance/jco/obj/wasm-tools.js',
  code: 'ERR_MODULE_NOT_FOUND'
}

[guybedford]

Direct cloning is only supported if you use Jco as a Rust dependency per Rust ecosystem conventions, but that would be executable via the Rust transpile API only then per https://docs.rs/js-component-bindgen/1.1.1/js_component_bindgen/fn.transpile.html.

For the JS dependency, you'd need to explicitly run npm install && npm run build to get it to work properly, and it may be better to just directly clone and then set "dependencies": { "@bytecodealliance/jco": "file:../jco-clone" } in the package.json or something along those lines.

[whitequark]

@guybedford That doesn't look like it works:

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/home/whitequark/Projects/yowasp/runtime-js/test/yowasp_runtime_test/node_modules/@bytecodealliance/jco/obj/wasm-tools.js' imported from /home/whitequark/Projects/yowasp/runtime-js/test/yowasp_runtime_test/node_modules/@bytecodealliance/jco/src/cmd/opt.js

I've done as you suggested, did a checkout of jco, ran npm install && npm run build and pointed the final project to it using a file:../../jco URL.

[whitequark]

Do you think you could just test YoWASP/runtime-js with this branch? There is clearly some sort of significant issue with how jco development is done and I can't really spend the effort right now to figure it out on top of the things I actually want to do...

[whitequark]

It looks like the install of jco that's inside of ./node_modules/@bytecodealliance/jco is missing obj/, but what's worse is that it's also missing all of the stuff needed to generate it:

yowasp/runtime-js/test/yowasp_runtime_test/node_modules/@bytecodealliance/jco (develop)$ npm run build

> @bytecodealliance/jco@1.1.1 build
> cargo xtask build debug

error: no such command: `xtask`

        Did you mean `flash`?

        View all installed commands with `cargo --list`
        Find a package to install `xtask` with `cargo search cargo-xtask`

(The npm run build command succeeds in a normal checkout of jco.)

[whitequark]

I figured out a way to get it to work (run npm pack and then specify the dependency as file:.../jco/bytecodealliance-jco-1.1.1.tgz). I verified that all of the functionality works exactly as expected, in Chrome (await-based on main thread) and in node (both await and synchronously). Thank you for doing this work!

[whitequark]

I'm happy with my implementation of YoWASP/runtime-js on top of JCO right now--let me know when you've made a release and I'll flip the switch on all YoWASP projects to use it.

[guybedford]

@whitequark thanks for the feedback here. I'm wondering if perhaps we can make this part of the next major and then unify on a new simpler hybrid instantiation interface that supports both async and sync. I've also created a tracking issue in https://github.com/bytecodealliance/jco/issues/441 for ideas around better instantiation APIs. Feedback is very welcome.

[whitequark]

I'm wondering if perhaps we can make this part of the next major and then unify on a new simpler hybrid instantiation interface that supports both async and sync.

That would work for me; I lock JCO at a specific version so the API breakage wouldn't cause a fallout. Thanks!

I've also created a tracking issue in #441 for ideas around better instantiation APIs. Feedback is very welcome.

I'll have to think about ways to provide custom WASI instantiations.

[whitequark]

I'm wondering if perhaps we can make this part of the next major

Do you know when this could happen? I'd really like to use this in most or all of the YoWASP applications (it's a blocker for some important use cases) and unfortunately due to the cargo being a build dependency for jco I would probably have to publish a fork of jco under one of my namespaces in order to use it in the builds of downstream packages (as a git URL would not work).

[guybedford]

Sure, let me try and include it in the next release cycle later this month, and if it turns out tricky for some reason I'll share an update here again.

[whitequark]

Thanks so much!