Convention for libraries to provide "workers" compatible bundle.

An issue that I regularly run up against when using Cloudflare Workers is that a library that I want to use provides both “node” and “browser” compatible bundles but neither of them work in the Cloudflare Workers environment because the bundles rely on node apis or DOM apis that are not available in Workers.

I think it would be great to establish some kind of convention that library authors can use to provide a third bundle that specifically lists itself as compatible with a “workers” style environment. While there would certainly be an advantage to marking a package specifically as “Cloudflare Workers” compatible, I think it would be cool if we could extend this to any DOM-less javascript environment like “service workers” or traditional “workers” in the browser. I’m not sure that makes sense but I figured would list it here as a possible area of exploration.

A great example of this issue can be found with the @emotion family of packages on NPM. Their package.json files look something like:

{
  "name": "@emotion/react",
  "version": "11.7.0",
  "main": "dist/emotion-react.cjs.js",
  "module": "dist/emotion-react.esm.js",
  "browser": {
    "./dist/emotion-react.cjs.js": "./dist/emotion-react.browser.cjs.js",
    "./dist/emotion-react.esm.js": "./dist/emotion-react.browser.esm.js"
  },
}

They are obviously trying to be good citizens by providing both node and browser compatible bundles (in both cjs and 'mjs` formats) but neither of those are compatible with workers because the node version uses node apis like “stream” that do not work in workers and the browser bundle uses some DOM apis. Here is a minimal reproduction repo of this issue with wrangler2 and emotion: https://github.com/nicksrandall/emotion-workers-example/tree/main

NOTE: This issue is a result of this twitter conversation: https://twitter.com/NickSRandall/status/1468991859267497988

[xortive]

webworker is different enough from cloudflare workers that we shouldn’t overload it – we have several differences from the service-worker API, and module workers aren’t service workers at all!

Is there anything that webworkers can do that is not supported on Cloudflare

A big one is threads, so tooling that assumes the “webworker” target allows their use tends to break. The vast majority of things don’t do this, but IIRC emscripten surprised me by generating something that tried to use them when you enabled its webworker target.

I’d be in favor of cloudflare-worker

[threepointone]

None of the docs reflect wrangler2 just yet. Maybe webworker should be enough. We’re close enough to it that it shouldn’t matter (except when it actually does, haha).