Karel Hrkal (kajacx) (Jul 20 2023 at 13:40): Karel Hrkal (kajacx) (Jul 20 2023 at 13:40):Hello, I wanted to ask if I can use the files generated by jco in my project. I am making wasm-bridge, a Rust crate that would allow to run the same Rust code you use with wasmtime, but on the web.
To best support the component model, I need to be able to take component bytes in Component::new() and turn them into a component that can run on the web at runtime.
This can be done using jco, as demonstrated in this plugin repo. This is basicly jco transpiling itself so it can run on the web, but it works.
I would need to include the "binary" files generated in jco at /obj/js-component-bindgen-component* in wasm-bridge, so I wanted to ask if that is OK and which license (if any) should I use in the source code of wasm-bridge to indicate where are those files coming from.
Karel Hrkal (kajacx) (Jul 20 2023 at 14:33):See here for an example what it might look like.
Guy Bedford (Jul 20 2023 at 17:26):Again, I'll reiterate that the best way to use something is to contribute the changes upstream first instead of just making local modifications for your own needs, as that allows others to benefit more widely from the effort. A browser build of jco provided by jco itself would also mean less maintenance for yourself. Having a browser-suitable build process in the jco project would be my preference for these kinds of workflows. But the short answer to your question is also yes that it is fine to use as long as you include the license.
Karel Hrkal (kajacx) (Jul 20 2023 at 18:32):Ok, I'll give a specific example: These two imports do not work for me, I had to replace them with ../browser/something. That is not something I can merge upstream, because on nodejs, it should be ../nodejs/something.
I guess the "correct" solution would be to still use relative path, but a different relative path based on build environment. I have no idea how to do that though.
There were other issues, for example, I had to "manually" remove if (!_initialized) throwUninitialized(); checks from the transpiled program, because the _initialized variable was not even initialized. I guess that is a real error that I should create an issue for, and I probably will, but there are still other changes that I don't believe fit with how jco is supposed to be used.
For example, the "ideal" way to use jco on the web would be to add "jco" to your npm/yarn dependencies, and then just "import {generate} from jco" in your JS/TS file and you are good to go. However, that is not what I want. I want to load the jco code from Rust, and in a way where the user doesn't have to do anything. The crate will load it for them.
So it is a very different use case, and even if jco could run on the web normally today, I would still need to modify it. So pushing changes upstream that make jco run on the web will not help me. I guess it would be cool if jco could do that in its own way, but if you want to load wasm components on the web, you can do so from Rust, which is what wasm-bridge is doing.
Guy Bedford (Jul 20 2023 at 18:46):Those imports you point to are exactly to get around the problem of environment-specific pathing. If it's not working in your environment then you might not be using a modern JS resolver. Putting the code through a build tool that supports modern resolution rules to get a single file script that you can run in your environment would resolve that issue.
The _initialized check is the support for top-level await, since we have jco users who do not support environments with top-level await. The exported $init promise must first be awaited in this case.
I don't think your case of running assumptionless JS code is as brittle as you think, provided you have a good esbuild / rollup configuration. But collaboration is of course entirely your choice.
Karel Hrkal (kajacx) (Jul 21 2023 at 07:35):Ok, I think I am beginning to understand. I think what you want is that I add an new npm "task" to build jco in the way I need it build, right? I guess that would work, and it would not "mess up" the "main build path" which is why I didn't want to merge the changes I needed to make upstream.
But that is not really necessary, I realized that I can just include the Rust crate in my Rust code, instead of making a component out of it and them transpilinging that component with jco ... (facepalm).
Anyway, is there a chance that the js-component-bindgen-component would be published on crates.io? It would provide a Rust api to jco generate with minimal effort, which would be great.
Guy Bedford (Jul 21 2023 at 22:35):@Karel Hrkal (kajacx) I just published the js-component-bindgen crate to crates.io, thanks for the bump on that
Last updated: Nov 22 2024 at 16:03 UTC