Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement externalized WASM build #98

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

mochaaP
Copy link
Contributor

@mochaaP mochaaP commented Apr 30, 2024

An alternative to #97.
See #96 for more info.

@mochaaP mochaaP changed the title tests: fix loading wasm when targeting external deps Implement externalized WASM build Apr 30, 2024
@guybedford
Copy link
Collaborator

I'm still curious how the fs.readFile is supposed to work at runtime in a distribution? Shouldn't all of this be happening at a binary level somehow?

@khardix
Copy link
Contributor

khardix commented May 6, 2024

@mochaaP I tried to grok the code and perhaps come with an explanation myself, but to no avail. Adding some docs (README? Comment block in code?) would probably help any future maintainer to understand what we are trying to archive here and why it's done in this specific way.

@guybedford Aside – thanks for the patience with this change, I really appreciate it!

@mochaaP
Copy link
Contributor Author

mochaaP commented May 7, 2024

Added comments to explain the load process. If something is still unclear, please point it out :)

@guybedford
Copy link
Collaborator

@mochaaP thanks for adding comments, my question though specifically is how you are hooking the readFile call in the Node implementation to support inlining the binary in the runtime?

@mochaaP
Copy link
Contributor Author

mochaaP commented Sep 19, 2024

To clear some confusion: fs.readFile is not hooked -- instead there are two flavors: CJS and ESM.

The CJS flavor inlines the WASM binary as a base64 string. This is what libnode bundles, and it won't be published to npm (or not exported by package.json).

The ESM flavor assumes this module is properly installed as a package, and reads the WASM binary from a relative path.

(Sorry for the late reply. I was working on other projects previously.)

@guybedford
Copy link
Collaborator

The ESM flavor assumes this module is properly installed as a package, and reads the WASM binary from a relative path.

This is the part I still do not understand properly - you mean it is loaded relative to the Node.js binary itself? Why would we want to ship a Node.js binary that loads another separate Wasm file at runtime?

@mochaaP
Copy link
Contributor Author

mochaaP commented Sep 19, 2024

Normal Node.js distribution will only inline the CJS flavor, since it's not installed as a module. (i.e. have full filesystem structure, package.json, etc.) Builtins also can only load as CJS iirc, since the initialization process isn't asynchronous.

If one opts in to use the ESM flavor, it means the module has a place on the filesystem, thus we are able to resolve a WASM file relative to lexer.mjs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants