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

JS SDK Beta #1

Merged
merged 45 commits into from
Sep 26, 2023
Merged

JS SDK Beta #1

merged 45 commits into from
Sep 26, 2023

Conversation

mhmd-azeez
Copy link
Collaborator

@mhmd-azeez mhmd-azeez commented Aug 21, 2023

Copied the boilerplate from extism/extism/browswer and replaced the Allocator to use the kernel wasm

  • Works on NodeJS
  • Works in Browser
  • Works in Deno
  • Works in Bun
  • Create examples
  • Runtime initialization
  • File System
  • Cleanup
  • Automated tests
  • Docs & comments
  • Figure out the packaging
npm run build

node --experimental-wasi-unstable-preview1 ./examples/node.js wasm/config.wasm

deno run -A ./examples/deno.js ./wasm/config.wasm

bun run ./examples/node.js wasm/config.wasm

npm run tests
npm run deno-tests

@mhmd-azeez mhmd-azeez self-assigned this Aug 21, 2023
@mhmd-azeez mhmd-azeez marked this pull request as ready for review August 23, 2023 13:38
@mhmd-azeez
Copy link
Collaborator Author

mhmd-azeez commented Aug 23, 2023

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 index.deno.ts?

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 deno bundle command is deprecated

@mhmd-azeez
Copy link
Collaborator Author

Also, do we need to have two project.jsons (one for Node and one for Browser) for publishing to npm?

@mhmd-azeez
Copy link
Collaborator Author

Do we plan to support extism_http_request in Node and Deno?

@nilslice
Copy link
Member

Do we plan to support extism_http_request in Node and Deno?

Ideally yes -- all APIs that can be implemented in any environment should be.

@nilslice
Copy link
Member

Also, do we need to have two project.jsons (one for Node and one for Browser) for publishing to npm?

/cc @wikiwong -- do you know?

examples/index.html Outdated Show resolved Hide resolved
@mhmd-azeez
Copy link
Collaborator Author

mhmd-azeez commented Aug 23, 2023

Also, do we need to have two project.jsons (one for Node and one for Browser) for publishing to npm?

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

@bhelx
Copy link
Contributor

bhelx commented Aug 23, 2023

In this case we only need to publish a package for node. A cdn publish will probably be enough.

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.

Should it be esm or cjs? Currently it's csj

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.

Copy link
Contributor

@wikiwong wikiwong left a 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.

src/mod.ts Outdated Show resolved Hide resolved
src/plugin.ts Outdated Show resolved Hide resolved

function wasiRuntime(module: WebAssembly.Instance): GuestRuntime | null {
const reactorInit = module.exports._initialize;
const commandInit = module.exports.__wasm_call_ctors;
Copy link
Contributor

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?

Copy link
Collaborator Author

@mhmd-azeez mhmd-azeez Sep 10, 2023

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

src/index.browser.ts Outdated Show resolved Hide resolved
src/mod.ts Outdated Show resolved Hide resolved
src/index.node.ts Outdated Show resolved Hide resolved
@wikiwong
Copy link
Contributor

wikiwong commented Sep 8, 2023

Also, do we need to have two project.jsons (one for Node and one for Browser) for publishing to npm?

/cc @wikiwong -- do you know?

Sorry I missed this comment. You should be able to specify a browser field in package.json that tells bundlers that are packaging for a browser to use the specified entry point. With that, we should be able to publish a single package to NPM for browser & node. Here is some more info:

@mhmd-azeez
Copy link
Collaborator Author

@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:

  1. deciding a name for the npm/deno package
  2. deciding on a version

@wikiwong
Copy link
Contributor

wikiwong commented Sep 11, 2023

@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:

  1. deciding a name for the npm/deno package
  2. deciding on a version

Thanks for addressing @mhmd-azeez ! My suggestions for your two remaining items are:

  1. Continue to use @extism/extism
  2. Upgrade the version to 0.6.0 if there are breaking changes (only because we haven't hit 1.0.0 yet).. or 0.5.1 if there are not breaking changes

deferring to @zshipko @bhelx @nilslice for the final say on package name & version

Copy link
Contributor

@wikiwong wikiwong left a 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",
Copy link
Contributor

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

Copy link
Collaborator Author

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

build.js Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
@zshipko
Copy link
Contributor

zshipko commented Sep 11, 2023

Agreed, I think using @extism/extism and version 0.6 makes the most sense

@bhelx
Copy link
Contributor

bhelx commented Sep 11, 2023

How about 1.0.0-rc1? Let's give space to push bug fixes and separate these 2 libraries. I believe npm doesn't pull down rc versions unless you specifically ask for it.

@wikiwong
Copy link
Contributor

How about 1.0.0-rc1? Let's give space to push bug fixes and separate these 2 librariesseems like the ABI in . I believe npm doesn't pull down rc versions unless you specifically ask for it.

I believe you are correct regarding NPM. I am ok with 1.0.0-rc1. My only call out is that it's possible the ABI may change significantly from 1.0.0-rc1 -> 1.0.0 . It might be expected that there are only minor changes to the ABI with the same major version.. I don't think it would be that big of a deal though

examples/deno.js Outdated Show resolved Hide resolved
examples/deno.js Outdated
})
.withWasi();

const plugin = await ExtismPlugin.newPlugin(wasm, options);
Copy link
Member

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it!

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Collaborator Author

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?

examples/index.html Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
@nilslice
Copy link
Member

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 extism-kernel.wasm runtime imports though. Can you clarify?

@mhmd-azeez
Copy link
Collaborator Author

mhmd-azeez commented Sep 12, 2023

@nilslice

I still am not fully sure about the plan for embedding / providing the default extism-kernel.wasm runtime imports though. Can you clarify?

Yeah, I went with your suggestion of embedding the extism-kernel.wasm as a base64 string. I did it manually though, so no automated process for it yet. It's here: https://github.com/extism/js-sdk/blob/js-sdk-beta/src/plugin.ts#L650

@mhmd-azeez
Copy link
Collaborator Author

thank you everyone for your great feedback, I believe what's remaining is publishing the package to npm. @nilslice what's the processes here?

@nilslice
Copy link
Member

I'll DM you!

@bhelx bhelx merged commit bd283d0 into main Sep 26, 2023
3 checks passed
@mhmd-azeez mhmd-azeez deleted the js-sdk-beta branch March 14, 2024 16:21
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.

6 participants