lit
lit copied to clipboard
lit
[labs/ssr] Lit SSR doesn't work in Cloudflare Workers
Which package(s) are affected?
Lit Core (lit / lit-html / lit-element / reactive-element), SSR (@lit-labs/ssr)
Description
Lit SSR doesn't work in Cloudflare Workers as they rely on the "workerd", "worker", "browser" export conditions for bundling with esbuild. In which case, the lit-html and @lit/reactive-element packages are bundled using the browser condition.
But because those two packages uses window in the browser condition (which is fair), it doesn't work in Cloudflare. We've found that using the node condition works since they don't seem to use actual Node-specific APIs.
Related https://github.com/withastro/astro/pull/6915. We're fixing Astro's Lit + Cloudflare compatibility.
Reproduction
https://github.com/bluwy/cloudflare-lit-ssr-repro
- npm install
- npm run dev
The repo readme has some extra information of how to debug and patch it.
Workaround
Adding the "worker" condition that's an exact copy of the "node" condition to the aforementioned two packages fixes it.
The repro has a patch script to work around it.
Is this a regression?
No or unsure. This never worked, or I haven't tried before.
Affected versions
@lit-labs/ssr - 3.1.2, lit - 2.7.4
Browser/OS/Node environment
(I don't think these are related, but)
OS: macos 13.3 node: 16.19.1 npm: 6.19.3
Darn it, I think this is a duplicate of https://github.com/lit/lit/issues/1983. Sorry about it I'll make a comment there instead.
There might be some overlap but I think it's valid to keep this a separate issue from #1983 which asks for Service Worker rendering (in the browser) versus handling non-browser worker/edge environments.
My biggest hesitation about adding something like this is we ourselves don't have any testing for whether our Node build actually works properly in these environments. We'd have to dig through our dependencies to make sure they don't require any Node specific things. We probably want to limit built-in APIs to these https://common-min-api.proposal.wintercg.org/.
We do have an import of buffer for a Node build here https://github.com/lit/lit/blob/440890ba058e1e3c747c45c22f6526b72cb91e11/packages/lit-html/src/experimental-hydrate.ts#L17-L18
but this actually might be unneeded as the hydrate function is always meant to be run in the client. That module is being removed from lit-html for v3 anyway.
Another question is whether worker is the right condition name to use. https://runtime-keys.proposal.wintercg.org/ lists workerd as the name for Cloudflare but has different ones for Netlify and Vercel. https://github.com/wintercg/runtime-keys/issues/5 proposes wintercg as a common name for runtimes that meet the wintercg minimum API.
cc: @justinfagnani @kevinpschaaf @sorvell
Thanks. Yeah while investigating this, I didn't really check if all the node outputs support workers, just that some manual testing showed that it somewhat works. We could run workerd locally to test it, or maybe some sort of linter to check the common minimum API.
Re worker condition, I found that to be more commonly used as all worker/edge environments (even service workers and web workers) share a good portion of supported APIs. If we want to support all of them at once, the worker condition would be fine (imo).
wintercg does sound even ideal but I haven't seen ecosystem support for that yet. workerd would also be fine but that means repetitive exports for all the different (but similar) worker edge environments.
We would be very interested in this. For now, we are having to switch everything over to preact as it has full web component support and SSR everywhere (Cloudflare, Deno, you name it) but would love to bring lit back into our stack when this work is done!
And happy to help or test as needed.
