Npm package support

[ahaoboy]

Would you consider releasing npm packages?
Similar to https://www.npmjs.com/package/wabt

[alexcrichton]

Thanks for the report! I think it would be reasonable to have this, but I suspect that most folks working on wasm-tools probably don't have a lot of experience doing this. What I might recommend architecture-wise is perhaps a dog-food of jco where jco is used to create the JS package to publish. That being said I don't really know how best to do that myself. Would be nice to have though!

[ahaoboy]

Thanks for the reply, first time I heard about the jco project, but after taking a look, I found that it doesn't meet my needs. The brower api of jco is different from the node api. I need a parse api that can be consistent on node and web, like this:
https://github.com/ahaoboy/wasm-tools-wasm-demo/blob/main/test/basic.test.ts

import { parse } from '@xwat/wasm-tools';
import { expect, test } from 'vitest';
import { code } from '../src/code';

test('parse', () => {
  const buffer = parse(code);
  const wasmModule = new WebAssembly.Module(buffer);
  const instance = new WebAssembly.Instance(wasmModule);
  const { add } = instance.exports as any;
  expect(add(1, 2)).toBe(3);
});

[alexcrichton]

Oh sure yeah, it's not necessarily required to use jco, but I think that using jco would work well in conjunction with the wasm32-unknown-unknown target since jco's output should be compatible with both the web and node. I believe it's mostly the WASI implementation that requires node right now which isn't needed for bindings to these crates.

In any case if you've already got something working I think that's a great start! Would you be interested in sending a PR with your work?

[ahaoboy]

In any case if you've already got something working I think that's a great start! Would you be interested in sending a PR with your work?

I need a tool that converts wat to wasm with full platform support, and am looking for alternative libraries since it's more rust oriented.

jco's current web api exports only two functions

export async function transpile () {
  await $init;
  return generate.apply(this, arguments);
}

export async function generateTypes () {
  await $init;
  return _generateTypes.apply(this, arguments);
}

I haven't figured out the best practices yet, such as the distinction between synchronous and asynchronous api's, and how to handle wasm-pack output.

import initSync  from 'jco/sync'

const buf = initSync().parse(wat)

import initAsync  from 'jco/sync'

const buf = (await initSync()).parse(wat)

I don't need the wasi functionality at the moment, so jco is a bit too heavy for me, thanks for recommending jco, a lot of stuff in there is very inspiring to me!

[alexcrichton]

Oh I apologize I think I may have caused some confusion. I forgot that jco actually largely does what this issue reports, providing JS bindings to the library functionality in this repository. I was actually talking about a different part of jco, which is where there's some confusion. Let me try to clarify.

• The jco project already has library APIs for parsing/printing wasm which I think is what you want. These are built on wasm-tools and should work today. It sounds though like you're having trouble using them on the web? If that's the case I might recommend opening an issue on jco's issue tracker as Guy is likely able to help out.
• I was actually referring to using jco's transpile feature itself to produce a package here in this repository. This wouldn't mean using jco on the web, but it would instead mean publishing jco's output. I recommended this only because I forgot jco was already publishing this repository on npm, so I would not recommend taking this route any more.

So if you'd like I think it'd be best to open an issue on jco's issue tracker for better running on the web?

[guybedford]

I've posted bytecodealliance/jco#435 here. It would be nice to provide a better wrapping I agree, although at this point it would likely be a major change so we should make this in the next major.

[ahaoboy]

So if you'd like I think it'd be best to open an issue on jco's issue tracker for better running on the web?

It seems to be done bytecodealliance/jco#435 . Thanks, guys