-
Notifications
You must be signed in to change notification settings - Fork 33
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
Question - Should componentize-js tree shake unused imports? #104
Comments
This sounds like a great idea! |
As a follow-up to the comment, imagine the target world specifies all imports an SDK package might want to use. When a user decides to use a particular subset of the target world imports, we could potentially match the imports in the guest code using the following code to the ones in the target world. Anything in the target world not used by the guest could be stubbed out as I am imagining another function in addition to Let me know if this makes sense. I could try to create a PoC after #109. |
Ah nice, yeah that sounds ideal I agree! |
The first thing I ran into was, It is not straightforward to track the implicit imports that get brought in. For example importing |
I think we only need to do this for the direct imports in the splicer itself, where we synthesize all the core imports, where we would want to skip unused imports. This can be done by providing the filtered list of imports to https://github.com/bytecodealliance/ComponentizeJS/blob/main/crates/spidermonkey-embedding-splicer/src/splice.rs#L38, perhaps with a new argument "used_imports" to the main splice bindings function. The component model already has the "gc" code to prune unused transitive imports, so the rest should follow simply from there. |
completed with #117 |
Should the componentizing process perform tree shaking to exclude the wasm imports not imported by the JS guest code?
An example use case is when a npm package is written for an SDK, the wit files included with it will have all the possible imports. The guest code might choose not to use all the available imports, it would be good to only generate the bindings for the imports that are actually used. It will help reduce the binary size and also could help with running the component on hosts that might not support all the imports defined in the SDK.
The text was updated successfully, but these errors were encountered: