-
Notifications
You must be signed in to change notification settings - Fork 12
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
JS SDK Beta #1
JS SDK Beta #1
Conversation
I am a bit confused about Deno, do we need to bundle it at all? I mean you can just reference it by URL right? But since it's not one file, is it smart enough to also pull other files that are imported by I am asking this because there doesn't seem to be a great bundling mechanism for it. None of the bundlers support it by default and the official |
Also, do we need to have two |
Do we plan to support |
Ideally yes -- all APIs that can be implemented in any environment should be. |
/cc @wikiwong -- do you know? |
Actually, since I changed the browser package from esm to iife, we probably don't need to publish to npm at all. A cdn publish will probably be enough. In this case we only need to publish a package for node. Should it be esm or cjs? Currently it's csj |
I'm not sure about this. Most people doing frontend development use a bundler of some kind and expect a module on npm. Probably want an ESM module for this. I could be wrong though. Let's just make sure you can still use it in a bundled js app that targets a browser.
Node uses CJS. I think it does support ESM in most modern LTS versions now but might want to check to be sure. I'd aim for broader compatibility over anything else. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a few comments & questions but overall it's looking great!
One additional suggestion I have in terms of directory structure is to create browser
, node
, and deno
directories under src
, and have their respective index.ts
(mod.ts
in the case of deno) within those directories.
|
||
function wasiRuntime(module: WebAssembly.Instance): GuestRuntime | null { | ||
const reactorInit = module.exports._initialize; | ||
const commandInit = module.exports.__wasm_call_ctors; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't think it was ever necessary to call __wasm_call_ctors
directly. For command modules, shouldn't the _start
function do this for us?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am mirroring the behavior of the Rust SDK: https://github.com/extism/extism/blob/26f70e3a30d6d872572c0f9c8e180b8f2798f71a/runtime/src/plugin.rs#L470
I haven't seen any stacks that export __wasm_call_ctors
unless you ask the compiler explicitly, and in this case the user should probably export an _initialize
function that calls __wasm_call_ctors
instead. Maybe @zshipko can provide a better context
Sorry I missed this comment. You should be able to specify a |
@wikiwong thank you very much for your feedback, I have addressed all of your points, please take another look and let me know what you think. What's remaining is:
|
Thanks for addressing @mhmd-azeez ! My suggestions for your two remaining items are:
deferring to @zshipko @bhelx @nilslice for the final say on package name & version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! Sorry I didn't think of this in my first round of feedback - were you able to test the browser bundle as well as reactor type modules?
"deno.lint": true, | ||
"deno.unstable": true, | ||
"deno.enablePaths": [ | ||
"./src/deno/mod.ts", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This path may need to change with the latest update to directory structure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, can you elaborate on this? I think the path is correct
Agreed, I think using |
How about |
I believe you are correct regarding NPM. I am ok with |
examples/deno.js
Outdated
}) | ||
.withWasi(); | ||
|
||
const plugin = await ExtismPlugin.newPlugin(wasm, options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is ExtismPlugin.newPlugin
a little "stuttery" repeating Plugin
? Would ExtismPlugin.new
be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kind of on the fence about it. We should think about the interface a little more. I'm not sure if it's different in deno, but people tend to export functions directly in javascript:
import { newPlugin } from 'somepackage'
Let's not let it block this PR though. Will be minor changes we make I think until 1.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: I think we should have @chrisdickinson take a look at the interface later. He probably has a good sense of what js developers will expect to see interface wise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @chrisdickinson, did you have a chance to review this PR?
the quick summary is this looks awesome -- tons of work here, and really well done! I still am not fully sure about the plan for embedding / providing the default |
Yeah, I went with your suggestion of embedding the |
thank you everyone for your great feedback, I believe what's remaining is publishing the package to npm. @nilslice what's the processes here? |
I'll DM you! |
Copied the boilerplate from extism/extism/browswer and replaced the Allocator to use the kernel wasm