help with js tooling

[beeequeue]

hi! are you open to some help regarding the js tooling for this project?

i've been trying to understand and use MoQ for a bit now and have seen a bunch of small improvements that could be made, which i would be up for helping with!

i will summarize them here, but can expand on them if they interest you

• replace custom build scripts with tsdown
  • simplify the build process and gain easy access to various optimizations like inlining certain libraries
• set up Changesets for changelog generation and publishing
  • alternatively Sampo which is a multi-language alternative, so it could be used for all the packages (js, rust, py)!
• improve the data validation
  • validation libraries quite big to install (zod 4MB, valibot 2MB) but usually bundle quite well, making them optimal targets for inlining
    • something tsdown makes super easy
  • zod is still quite slow and big after the v4 update, so i would still also replace it
    • typia does AoT compilation
      • also supports generating protobuf encoders/decoders, which could be useful?
    • valibot is way smaller both when installed and inlined
• i saw some things that could be extracted to separate packages
  • @moq/varint - from lite/src/varint.ts, its change velocity should be quite a bit lower than the rest of the package
  • quite a bit of the changes in Replace postMessage with SharedArrayBuffer for lock-free audio transfer #1295 could be extracted to a library related to working with WebCodecs etc.

[coderabbitai]

🔗 Related PRs

#806 - Add debug features to moq-native [merged]
#881 - Export Varint module from @moq/lite [merged]
#1126 - Remove unused dev-dependencies and bump @moq/qmux [merged]
#1291 - Miscellaneous fixes [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[kixelated]

1. We're using vite to build the library AND the demos. Since it uses tsdown under the hood (I think), I'm not sure what benefit you would get.

2. It would be nice to have something like release-plz but for JS. I thought about using Changesets or similar but didn't want to require conventional commit messages (or whatever). But that's less of a concern now that Claude writes my commit messages lul.

3. You could quantify the size/speed of zod if you want. I would need concrete numbers to switch though.

4. A varint package makes sense, or just exporting it from moq/lite. But again you should probably use some tool to analyze the current bundle size to find stuff we could split out.

[beeequeue]

vite does not use tsdown (it is Vite Plus that does that) and their library mode is both a bit limited and overkill at the same time.

the reason i mentioned the custom build scripts is because it's doing some brittle work (rewriting paths) that is usually handled by the bundler and/or publisher (pnpm/yarn do this while packing the tarball)

i can glady work on a branch that would show that it would look like! :)

---

Changesets (and Sampo) don't use commits for versioning and changelog generation, but "changeset files" that contain information about a change:

---
"@changesets/release-utils": major
---

Changed `runPublish()` signature.

Now requires passing separate `command` and `args` parameters:

```diff
runPublish({
-  script: `node -e 'console.log("test")'`
+  command: "node",
+  args: ["-e", `console.log("test")`]
  cwd: import.meta.dirname,
})
.```

which turns into:

generated changelog

1.0.0-next.2

Major Changes

• #1875 12f20ea Thanks @beeequeue! - Changed runPublish() signature.

  Now requires passing separate command and args parameters:

  runPublish({
  -  script: `node -e 'console.log("test")'`
  +  command: "node",
  +  args: ["-e", `console.log("test")`]
    cwd: import.meta.dirname,
  })

---

to be clear, inlining whatever validation library used would be the biggest improvement whichever is used.

most validation libraries are very big to install since they support lots of data, but most of it is not used at the same time.

you can see this by bundling the current catalog validation code (select only Catalog here), where the bundled (inlined) code is only 22kB while installing zod is 4.34MB

---

as for splitting packages i was mostly thinking about splitting it more by usage and change velocity rather than package sizes.

for example:

• varint
  • could be useful for other people to parse varints
  • will probably change less often than @moq/lite or hang
• shared ring buffer decoder
  • useful for writing code with @moq/lite rather than @moq/watch

[kixelated]

@moq/watch using vite-bundle-visualizer:

Ignore the pink in the middle, that's an optional polyfill loaded on demand. The blue on the right side is the core, everything else is optional.

Reducing the size of Zod would be relevant, but IDK it's not huge. I'm open to alternatives just I haven't messed around with anything. The CMAF library could also be smaller.

[beeequeue]

you're only looking at the bundled results, i'm talking about the installation size where not inlining/bundling zod is increasing the installation size from 200kB to 4MB.