bytecodealliance
Split componentize and transpile
A lot of work is currently going into the "componentize" logic of jco; however, this means it is taking on a ton of dependencies.
If users, such as arcjet, only want to transpile, they should not have to take on this supply chain risk.
We're in the process of discussing where ComponentizeJS best belongs, and currently it's an open question and has been considered on both sides for either moving ComponentizeJS into Jco or moving ComponentizeJS into StarlingMonkey.
This is a good datapoint to hear on the side of moving it into StarlingMonkey and I'll be sure to bring this argument up.
Hey @blaine-arcjet I'm thinking there are at least two ways forward here:
- Moving
componentize-jsto be a peer dependency - Creating a
jco-transpileproject that you can use to benefit fromtranspilefunctionality without pulling in componentize issues.
(1) is almost a non-starter because it would introduce breaking semver changes on most updates to componentize-js, but (2) seems like a viable solution.
What do you think about that? With making this change we can also look at attempting to remove @bytecodealliance/preview2-shim because that's not actually hard dependency for transpile (especially if you're using your own/a modified shim which we recently added support for) -- that should help reduce your bundle size even more.
cc @tschneidereit
@vados-cosmonic Your (2) is very similar to my recent thoughts. I was thinking about pulling the transpile logic into Gravity so we at Arcjet have a central tool that transpiles code to Go & JS (and perhaps any other language we need in the future).
Currently, it's unfortunate that the crates in jco can't be depended upon directly since they are not published to crates.io
Hey @blaine-arcjet thanks -- I will embark on (2) this week if I can. IMO it's the better of the solutions anyway, I'm really hoping jco can be come one-stop, but it needs to be modular and reuse from across the ecosystem where possible (and itself be as reusable as possible).
I'd like to do whatever I can to help ya'll be successful, the work you're doing with gravity is fantastic.
Currently, it's unfortunate that the crates in jco can't be depended upon directly since they are not published to crates.io
It's not documented extensively (another thing on the TODO list!) but we do publish the bindgen, I assumed it was clear but maybe I was wrong?
https://crates.io/crates/js-component-bindgen https://docs.rs/js-component-bindgen/1.11.0/js_component_bindgen/
Are they missing some functionality you wanted to depend on? Maybe some of the stuff that is done on the JS side?
Note that it's also possible in the future that jco becomes a Rust project -- right now it's a bunch of JS calling JS + Rust, but it could easily turn into Rust calling JS + Rust -- this is something @guybedford was open to and I certainly am too.
Hey it's been a while but an update here -- we've got a jco-transpile package cooking:
https://www.npmjs.com/package/@bytecodealliance/jco-transpile
It's not quite ready for primetime yet (see the 0.0.2 version), but this is mostly because I want to actually switch jco to use it exclusively before I mark it 0.1.0 (going with the rust tendency for versioning here :)
@vados-cosmonic this is awesome! It looks like it is just a package with no CLI. Is that correct? Do you plan to include the CLI component?
Exactly! In the meantime we're going to rewrite jco to use jco-transpile as a library, similar to how componentize-js is used -- there wont' be a CLI component (see the file tree) and I'm going to be working on getting the package size as small as possible.
The package size right now is huge because I think some other files got caught up in the packaging, but we will end with something smaller than Jco's current package size. There are two meaningful things that came up:
- Transpile actually does an opt pass, it might be possible to pull that out and let the outside hold the dependencies required for that.
- We'll likely need to add some instrumentation to make packages that use it as a library happy (progress indication, etc)
Would love some feedback on the API while I iterate on it/what ya'll are most needing to use -- I think I've covered the basic API that transpile exposed in the first place (with some clarifying naming changes as well).
jco-transpile v0.0.3 has a more reasonable size (package size problem fixed):
https://www.npmjs.com/package/@bytecodealliance/jco-transpile/v/0.0.3
https://github.com/bytecodealliance/jco/releases/tag/jco-transpile-v0.0.3
A couple releases of jco need to go out, but ~3 releases from now jco should be switched over to use jco-transpile internally.
Considering we now have this functionality, I'm going to close this out -- jco still needs to switch over to using transpile internally, but we'll track that separately.
Happy to re-open/file a new issue if jco-transpile isn't working