Should libwabt.js and libwabt.wasm be published on npm?

[WebReflection]

Hello folks,
I've eventually re-packaged https://github.com/WebReflection/utils/tree/main/src/libwabt#readme what you publish as demo source code for the following reasons:

• it's not clear at all on npm who owns, maintains, or updates such lib ... AssemblyScript might be one, the other is 6yo package ... all I know is that your last update was 5 months ago so I went for the latest I could find, yet it'd be great if you could deploy it on npm too
• the runtime file resolver is problematic for when the code is fully embedded (as Worker or whatnot) because blob sources are unpredictable so that just swapping the WASM module name isn't enough ... my re-packaging of the exact same utility allows bundlers to bring that in as a regular ECMAScript module so I can use/run that lovely library in every possible scenario, with or without bundlers helps
• your actions already have all the orchestration needed to create via Emscripten the right library with its right WASM counterpart ... I understand one could clone, build, install all the things but ... hey ... I like simple

Accordingly, I wonder if there's any plan to land such library for Web context, 'cause I think to both explore, debug, test and runtime play around wat2wasm concept is something wonderful, an example of what I am providing out of a single JS file:

import watTag from 'https://esm.run/@webreflection/utils/wat-tag';

const wat = watTag({
  import: {
    my_namespace: {
      imported_func: arg => console.log(arg),
    },
  },
});

{
  using result = await wat`
    (module
      (func $i (import "my_namespace" "imported_func") (param i32))
      (func (export "exported_func")
        i32.const 42
        call $i))
  `;

  result.instance.exports.exported_func();
}

Thanks in advance to anyone willing to either clarify or follow up: I'll still re-package the thing in a way that's convient for my use cases (the compressed base64 version of the WASM as bundle friendly module) but having a source of truth from this repo/project that is easily reachable and aligned with the latest would be great, thank you!

[dy]

If feature-completeness/performance or size is a matter, you can check watr as alternative for WAT compilation.

[WebReflection]

@dy very interesting, specially the JZ outcome but:

• it's not official, it's a single developer effort: while I appreciate such effort I tend to follow standards in the long run to be sure whatever I do is standard backed/based
• it doesn't answer my question around libwabt.js and libwabt.wasm officially published on npm from this group
• it's not Emscripten based so I am not sure it covers on Web same things Emscripten would out of the box

regardless, thanks for the pointer, still I am very interested in this library, not others.

[dy]

Right.

Just small correction on watr: it is plain ESM with no deps, and doesn't have .wasm to locate, so workers and bundlers load it like any other module. So no emscripten is exactly why resolver problem from your post goes away.
WAT is defined by the core spec, and watr runs the official spec testsuite in CI.

Your tag example runs as is:

import watr from 'watr'
const { exported_func } = watr`(func (export "exported_func")
   (call ${arg => console.log(arg)} (i32.const 42)))`
exported_func() // 42

[WebReflection]

I see ... then mine is a duplicate in intents, I wasn't aware about watr and it never showed up as WAT to WASM converter on search engines, thanks for clarifying, my quest here remains though!