Add publish workflow and minimal npm package for WASM

[MatiasManevi]

Summary

Adds a CI workflow to build and publish the generated WebAssembly runtime to npm.

• New workflow to build and publish the WASM package on tag pushes. Behavior:
  • builds WASM
  • Syncs package version from the pushed tag
  • Publish dist folder content
• Bare minimum npm manifest & README: Prevents dev/test/demo files from being published.
• Added a new section to wasm/README.md to introduce documentation about special cases to take into consideration when using the package
• Added package.npm.json with cleaner content for npm. CI job takes care its content reaches npm registry rather than wasm/package.json.

Deployment notes

• Requires a repository secret NPM_ACCESS_TOKEN with publish rights. (Already set by @okmatija)
• The publish workflow triggers on tag pushes (e.g., refs/tags/) — version is taken from the tag and applied with npm --no-git-tag-version.

Important

I used mujoco_wasm as package name here but we might want to use a "scoped" one for mujoco org: @mujoco/wasm. We need to make a decision before merging.

Follow-ups / Future work

• Add Vite dev-server middleware educational content to set COOP/COEP headers for local dev (loading .wasm file during runtime takes decent amount of non straightforward configuration).
  • Or we could maybe use sSINGLE_FILE flag when compiling; which makes importing the module much easier.
• Optionally publish both pthreads-enabled and pthreads-free builds if we want maximum consumer compatibility.

[MatiasManevi]

@JayFoxRox here is the new PR :)

[okmatija]

we might want to use a "scoped" one for mujoco org: @mujoco/wasm. We need to make a decision before merging.

Can we call the package just mujoco, so the artefacts are mujoco.js, mujoco.d.ts, mujoco.wasm?

we could maybe use sSINGLE_FILE flag when compiling; which makes importing the module much easier.

We can consider having a separate package for this, maybe mujoco_single_file, but I don't think it should be enabled by default.

[MatiasManevi]

we might want to use a "scoped" one for mujoco org: @mujoco/wasm. We need to make a decision before merging.

Can we call the package just mujoco, so the artefacts are mujoco.js, mujoco.d.ts, mujoco.wasm?

We can have the asset names what ever we want, what I am talking about here is something else: how do we want to name the package in npm registry?. Right now is mujoco_wasm.

So yes, we can call it just mujoco and then we can make the asset file names match the package name for sure.

---

we could maybe use sSINGLE_FILE flag when compiling; which makes importing the module much easier.

We can consider having a separate package for this, maybe mujoco_single_file, but I don't think it should be enabled by default.

I will add this to the TODOs for a next iteration.

[okmatija]

we might want to use a "scoped" one for mujoco org: @mujoco/wasm. We need to make a decision before merging.

Can we call the package just mujoco, so the artefacts are mujoco.js, mujoco.d.ts, mujoco.wasm?

We can have the asset names what ever we want, what I am talking about here is something else: how do we want to name the package in npm registry?. Right now is mujoco_wasm.

So yes, we can call it just `mujoco` and then we can make the asset file names match the package name for sure.

we could maybe use sSINGLE_FILE flag when compiling; which makes importing the module much easier.

We can consider having a separate package for this, maybe mujoco_single_file, but I don't think it should be enabled by default.

I will add this to the TODOs for a next iteration.

We should also name the package "mujoco"