@libsql/client v0.17.0 regression?: "XMLHttpRequest is not defined" on Cloudflare Pages

[ediezindell]

Describe the bug

After upgrading to @libsql/client v0.17.0, applications on Cloudflare Pages (Pages Functions / Edge Runtime) fail at runtime when executing database queries.

The error is:

ReferenceError: XMLHttpRequest is not defined

This is a regression from v0.15.x, where the client worked correctly in the same environment.

• Environment: Next.js 15 (using API Routes) deployed on Cloudflare Pages.
• Build time: Success (No errors/warnings).
• Runtime: Fails only when a database request is actually made.

Reproduction and Context

I was unable to create a minimal reproduction using Next.js 15 due to the complexity of the setup.

However, I found that the following esbuild command—which I believe mimics the Cloudflare Workers/Pages environment by using --platform=browser and --conditions=workerd—results in XMLHttpRequest being included in the bundle. Since the Edge Runtime lacks XMLHttpRequest, this seems to be the likely cause of the error I'm seeing, although I am not 100% certain this simulation also matches the Next.js/Wrangler build process.

1. Setup:

mkdir repro-libsql && cd repro-libsql
npm init -y
npm install @libsql/client@0.17.0

2. Create repro.ts:

import { createClient } from "@libsql/client";
export const onRequest = async () => {
  const client = createClient({ url: "https://example.com" });
  await client.execute("SELECT 1");
};

3. Bundle and Verify:

npx esbuild repro.ts --bundle --platform=browser --conditions=workerd --format=esm --outfile=bundle.js
grep "new XMLHttpRequest" bundle.js
# Output: ... var xhr = new XMLHttpRequest(); ...

The output confirms that new XMLHttpRequest is present in the bundle generated with these settings. In v0.15.x, this same process resulted in a bundle that used the native fetch API without any references to XMLHttpRequest.

Root Cause Analysis

The regression appears to be caused by the switch from @libsql/isomorphic-fetch to cross-fetch in @libsql/hrana-client@0.9.0.

While @libsql/client itself has a workerd export condition, its dependency cross-fetch does not. When a bundler targets a non-Node environment (like Cloudflare Pages), it resolves cross-fetch to its browser distribution. This distribution includes the whatwg-fetch polyfill, which lazily instantiates XMLHttpRequest.

Since the Edge Runtime (workerd) provides a global fetch but strictly prohibits XMLHttpRequest, the application crashes with a ReferenceError as soon as a database query is executed.

[convcha]

I’m seeing the same issue in RedwoodSDK (Cloudflare Workers) during local development.
It works fine with @libsql/client 0.15.15.

[ShadowSlayer03]

Thanks for this, found it very late after many days of debugging.
Created a blog website and hosted it within CF workers, none of the API calls were working. The error logs and monitoring proved to be helpless too since it only said: Failed query: PROPER SQL QUERY

Since it was my first time with CloudFlare deployment, tried to see if there was any problem with Drizzle configs, Turso configs, replaced env variables a bunch of times thinking the envs were not getting picked up properly, repackaged some code into functions so that it will be called and envs get initialized properly in workers. Even messed around with some runtime and buildtime variables.

What was even confusing was that things worked properly in local because it was in a node env where XMLHttpRequest was working.

Now I downgraded to version to 0.14.0 and everything works like a charm.
Please fix this issue or add a note citing the same so that many precious hours can be saved.