imports

[zdanl]

Hello. I'm trying to compile a multi-file structured NodeJS project with several (npm) imports such as ExpressJS and Mongoose.

z@zs-MacBook-Pro wallet % javy compile server.js
thread '<unnamed>' panicked at crates/core/src/main.rs:27:10:
called `Result::unwrap()` on an `Err` value: Uncaught ReferenceError: could not load module 'mongoose'

It doesn't particularly like it.

Good job with JS to WASM, although!

[jeffcharles]

Javy at the present time does not support resolving imports from files in your file system. The short story for why is, during compilation, we process the JS source code inside a WebAssembly instance and that instance does not have any access to your filesystem. You can use a bundler like esbuild or vite to bundle your code and dependencies into a single JavaScript file which Javy can then process.

Something else to keep in mind is Javy does not support NodeJS or CommonJS APIs. So something like Express or Mongoose will likely either fail to compile or fail to run. An additional wrinkle is because Javy produces WASI preview 1 Wasm modules, many I/O operations including ones involving sockets for HTTP or database connections are not supported because there are not standard WASI APIs available for those operations in WASI preview 1.

[zdanl]

That was comprehensive, thanks. May I ask -

1. There is a Typescript to LLVM (which obviously has a WASM target) compiler on Github, also, there is at least one lab claiming they have managed compilation of Javascript. Is this, in general, interesting to the project? I have seen other promising prospects on Github leveraging Static Analysis and Symbolic Execution.

2. I know the sandboxing mechanism is a feature, not a bug, but as for me, it's about performance. I've seen too many sandbox escapes in Chrome and recently out-of-bounds write in v8 to really believe in it.

Thanks for the Vite hint. It's a shame NodeJS APIs aren't working.

[jeffcharles]

There is a Typescript to LLVM (which obviously has a WASM target) compiler on Github, also, there is at least one lab claiming they have managed compilation to Javascript. Is this, in general, interesting to the project?

It's out of scope for Javy. As a codebase, it's pretty tightly coupled to QuickJS as an engine. I'm not sure how much of Javy's codebase would be helpful to reuse between engines. I suspect for different engines or for no engine at all, it would make more sense to author that code outside of Javy.

I know the sandboxing mechanism is a feature, not a bug, but as for me, it's about performance. I've seen too many sandbox escapes in Chrome and recently out-of-bounds write in v8 to really believe in it.

Sorry I'm not exactly following on what the question is 🙂

[zdanl]

One more thing -

There is JSLinux by Fabrice Bellard. It has no NodeJS calls, requires no libraries, and is pure Javascript.
With respect to your work, it would be outstanding advertising for Javy and a great benchmark if this worked.

Do you think?

[jeffcharles]

There is JSLinux by Fabrice Bellard. It has no NodeJS calls, requires no libraries, and is pure Javascript.

Looking at the JS part of the code, it looks like it requires APIs to instantiate a Wasm module, XML HTTP Request API support, and document object model (DOM) APIs. Supporting these APIs would require the use of non-WASI imported Wasm functions.

[zdanl]

Thanks for your valuable feedback.

[andreaTP]

You can use a bundler like esbuild or vite to bundle your code and dependencies into a single JavaScript file which Javy can then process.

Just gone through the process and got a few to work, FWIW: https://github.com/andreaTP/javy-bundling-examples