WebAssembly / WebAssembly/wabt

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

Open
#2,827 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
8.1k
Forks
827
Avg merge
4d 6h
Merged PRs (30d)
18

Description

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!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Emscripten packaging steps in Makefile around lines 149–152 and the runtime resolver in docs/demo/wat2wasm/demo.js. Compare those outputs with the referenced WebReflection utility and determine the packaging, resolver, and maintenance requirements for publishing libwabt.js and libwabt.wasm on npm; done means the publication approach and artifact expectations are agreed and documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, wasm
Domain
build-system, release, web-dev
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.