JS http module causing `subo build` to fail (macOS only?) about e2core

[flaki]

The issue here is rooted in the honest mistake of Ramón accidentally overwriting the wrong file in the JS runnable template generated by subo. Instead of putting the runnable code in lib.js, the code overwrites the "magic" boilerplate in index.js that we use to instrument the imports and load the TextEncoder polyfill missing from the javy engine.

With the above, this is not a "bug" in subo build, per se, but I'd argue there are various things we could (and should) improve here, and I would propose that we rename this issue to track the improvement of subo build error messages, and file a new issue for reducing the magic boilerplate and documenting the Reactr JS API boundary to demistify the interaction between index.js-lib.js.

If I read the above error message correctly there are two issues here (and a third potential one from experience working with JS runnables that should also be addressed).

1. the javy build fails due to a parse-time JS reference error (our HTTP API relies on the TextEncoder but we fail to import the polyfill), this triggers a build failure in javy which is a Rust binary and we are seeing the backtrace of the Rust panic
2. we use wizer to preinitialize/snapshot the generate wasm runnable for faster startup times, it seems like we are not picking up on the build failure and still trying to run wizer on the non-existent wasm output

A third issue that is not triggered here is a preceding step, even before we run javy we use webpack to bundle all the code into a single JS file that we compile afterwards. This step can also fail with mysterious error messages.

Note that these are all compile-time issues and runtime errors are very cryptic and hard to debug themselves, but that DX issue should be handled and improved on separately.

[hola-soy-milk]

Thank you so much for investigating this!!