Enable browser / cross-platform support

[NullVoxPopuli]

Resolves: https://github.com/embroider-build/content-tag/issues/11 Unblocks: https://github.com/NullVoxPopuli/limber/pull/1162

Dist Branch: https://github.com/NullVoxPopuli/content-tag/tree/browser-support-dist

Demo of this working: https://4f4afaa6.limber-glimdown.pages.dev/ PR: https://github.com/NullVoxPopuli/limber/pull/1162 (this screenshot reveals I have a concurrency issue because the wasm is loaded twice (this is a me problem, not a content-tag problem) :sweat_smile: )

pnpm:

"content-tag": "github:NullVoxPopuli/content-tag#browser-support-dist"

I used the term standalone similar to how @babel/standalone uses it -- in that the existing build of content-tag works in ESM, but is still meant for node usage. the standalone build is built using the browser option, which happens to then be compatible everywhere.

---

I'm new to Rust, so here are the learning materials I found / used

• https://rustwasm.github.io/docs/book/reference/code-size.html
• https://rustwasm.github.io/wasm-pack/book/commands/build.html
• https://rustwasm.github.io/wasm-pack/book/tutorials/npm-browser-packages/template-deep-dive/wee_alloc.html
• https://github.com/rustwasm/wee_alloc

automated browser tests?

• testem + qunit
  • way too much manual work to set up with ESM-based tests.
• playwright
  • can't import anything to test / render / assert against (in ember, this is what ember-qunit is for)
  • playwright is a browser driver w/ assertions
  • also playwright downloads copies of browsers instead of using what's installed an the system.
• vitest's browser mode
  • no documentation
  • "webdriverIO and playwright support", which means the same limitations as playwright native, probably (at least until they document more of how it's supposed to be used)
• mocha (https://mochajs.org/#running-mocha-in-the-browser)
  • doesn't explain how to report from browser to node, which is what we need for CI

---

We do have a npm run web that we can manually run to verify :-\

If anyone knows of a decent web-testing setup with ESM / TS ... that'd be great.

[NullVoxPopuli]

Most recently, I tried this using the new Git/dist branch (added to the PR description), and the webpack config:

module: {
  rules: [
    {
      test: /\.wasm$/,
      type: "asset",
    },
  ]
},

(which seemed the least disruptive to wasm-pack's output, and still respected the native platform features of async wasm loading (a lot of folks seem to prefer asset/inline for wasm... which is a lot))

But I have an error about import names:

I think because webpack is renaming all the exports for some reason. So I may hold off on this until I get limber/glimdown using Vite -- I don't really want to deal with webpack configs for too much longer.

[ef4]

I don't think we should really need a different import path and public API for the browser.

With conditional exports you could still have your standalone.js file but it would be invisible to consumers. It would be under the conditional export condition "browser".

And that file can use top-level await to await init(), so callers just see the same API as in node ESM.

[NullVoxPopuli]

I don't think we should really need a different import path and public API for the browser.

I can have a go at this, but (at least temporarily) it would make the project not consumable in ember at runtime :sweat_smile: See: https://github.com/embroider-build/embroider/issues/1678

Standby! new PR incoming!

[NullVoxPopuli]

Closing, because we went with a non-monorepo approach