-
Notifications
You must be signed in to change notification settings - Fork 16
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
Publish compiler as npm package #77
Comments
Seems fairly feasible to package it up. While I think it would be unwise to use this dependency due to its outdated dependencies, it can serve as a great reference either way: binary-install example. Someone also went through the trouble of rewriting it without axios: simple-binary-install. Apparently binaryen npm package already contains wasm-merge and wasm-opt bins, and I can confirm extism-js works just fine with them. So this is just a matter of adding it as a peerDep. Edit: Once again I've been duped by npm's hoisting behavior. Seems there's a bit more to it, on top of adding it as peerDep, as binaries of transient deps aren't hoisted. So wasm-merge won't automatically become available for the plugin developer to directly call, unless they add it as a dep themselves. I believe it would be available to the extism-js binary that we'll bundle though, so it should be a non-issue. |
extism-js can get the same treatment, if extism/js-pdk#77 lands.
This would be really awesome to see, it would make the process of using the pdk super streamlined for node devs. Also, it unlocks |
It might make sense to publish the whole package to npm and have the compiler published as a
bin
since that's how most people will be managing their other dependencies. We can also add it to the templates. There may be some trickiness around getting wasm-merge in place. Leaving this open for discussion and ideas on how to implement.The text was updated successfully, but these errors were encountered: