refactor: tighten up cloudflare detection

[petebacondarwin]

The previous approach to detecting whether to use Cloudflare's sockets was to check for missing polyfills.
But as we improve the polyfills that Wrangler can provide these checks are no longer valid.

Now we just try to use the Cloudflare API first and fallback to Node.js if those are not available.

[cloudflare-pages]

Deploying node-postgres with    Cloudflare Pages

Latest commit:	a0ebc07
Status:	✅  Deploy successful!
Preview URL:	https://dd91c742.node-postgres.pages.dev
Branch Preview URL:	https://fix-cloudflare-detection.node-postgres.pages.dev

View logs

[brianc]

nit: if you want extreme pedantry (I mean...who doesn't, right? 😉 ) putting the conditional (process.release && process.release.name === 'node') into a predicate function isNode() or something would DRY this up a bit. I'm also slightly concerned how this impacts bun/deno? Is there any way to invert the check and see if you're inside cloudflare instead? Then if you're not in cloudflare but you're in a fully node compatible environment (be that node, deno, bun) we're using the node side of things. Obviously this is subject to change as the node/deno/bun/cf/browser/wasm environments continue to converge...just my thoughts here.

[sehrope]

Is there any way to invert the check and see if you're inside cloudflare instead?

Yes, that's what I meant by checking if you're in CF (as opposed to checking if you're not in node).

I'm not sure if they expose anything like that. If not, they definitely should add a process.env.CLOUDFLARE_WEB_WORKER env similar to how GitHub does for actions.

Then if you're not in cloudflare but you're in a fully node compatible environment (be that node, deno, bun) we're using the node side of things.

Reminds me of the io.js days!

[petebacondarwin]

😢

[petebacondarwin]

Of course trying to import from cloudflare:sockets has exactly this behaviour. It is checking whether we are in a Worker or not.

[petebacondarwin]

The import of pg-cloudflare outside of a worker is an empty package.

[petebacondarwin]

In BunJS: process.release.name === "node" but in Deno: process === undefined

[petebacondarwin]

I also considered a "Cloudflare specific global" such as HtmlRewriter which doesn't exist in node or deno... but it does exist in bun!

I am asking internally to see if there is a more reliable way to determine the runtime.

[charmander]

I haven’t taken a good look at pg-cloudflare yet, but I think it’s always nicer to detect the APIs that are actually needed than to detect a particular runtime, when possible.

[petebacondarwin]

I haven’t taken a good look at pg-cloudflare yet, but I think it’s always nicer to detect the APIs that are actually needed than to detect a particular runtime, when possible.

That was my original approach way back, where I "knew" that Cloudflare did not support net.Socket. But since we are upgrading our polyfills (and have no control over other people bundling in their own polyfills) we can no longer rely upon that.

The approach of trying to import from cloudfare:sockets is also a similar approach but I accept that having an exception each time for most use cases just to support a minor use case is a bit unfair.

[charmander]

Trying to detect a specific platform based on API presence isn’t an example of that; trying to import cloudflare:sockets is, yeah. Cache the result?