[BUG] @voltagent/core fails in Supabase Edge Functions because Deno eagerly resolves @libsql/client native binary

[onebillionthorg]

Describe the bug

Summary

@voltagent/core cannot be used directly in Supabase Edge Functions via npm: imports because Deno eagerly resolves transitive dependencies, including @libsql/client, which then loads a native *.node binary requiring FFI.

This makes VoltAgent unusable in Supabase Edge Functions even when the app does not configure LibSQL memory at all.

Environment

• Platform: Supabase Edge Functions
• Runtime: Deno-based edge runtime
• Import style: direct npm: imports
• VoltAgent package: @voltagent/core
• Tested on: April 22, 2026

Minimal repro

import { Agent } from "npm:@voltagent/core";

Deno.serve(() => {
  const agent = new Agent({
    name: "test",
    instructions: "Say hello",
    model: "openai/gpt-4o-mini",
  });

  return new Response("ok");
});

Steps To Reproduce

1. Create a new Supabase Edge Function.

2. Add a minimal VoltAgent import:

   import { Agent } from "npm:@voltagent/core@<VERSION>";
   
   Deno.serve(() => {
     const agent = new Agent({
       name: "test",
       instructions: "Say hello",
       model: "openai/gpt-4o-mini",
     });
   
     return new Response("ok");
   });

3. Serve or deploy the function with Supabase Edge Functions.

4. Observe that Deno eagerly resolves transitive dependencies from @voltagent/core, including @libsql/client.

5. Resolution reaches a native *.node binary from the LibSQL stack, which requires FFI/native module loading and fails in the Supabase Edge runtime.

Expected behavior

Importing and using @voltagent/core in Supabase Edge Functions should work when LibSQL is not configured or used.

Unused native storage adapters should not block edge/serverless usage of the core package. If LibSQL is optional, it should only be loaded when explicitly imported/configured.

Packages

Tested package:

• npm:@voltagent/core@<EXACT_VERSION_TESTED>

Not explicitly used in the repro:

• @voltagent/libsql
• @libsql/client

Runtime context:

• Supabase Edge Functions
• Deno-based edge runtime

Additional Context

No response

[truffle-dev]

Hit the same hypothesis from the repro and came up empty. @voltagent/core@2.7.1 doesn't pull @libsql/client in my environment, and I want to share the receipts before a fix direction gets picked.

Repro

main.ts:

import { Agent } from "npm:@voltagent/core@2.7.1";
console.log("imported ok");
const agent = new Agent({
  name: "test",
  instructions: "Say hello",
  model: "openai/gpt-4o-mini" as unknown as never,
});
console.log("constructed ok, name=", agent.name);

deno.json:

{ "nodeModulesDir": "auto" }

$ deno --version
deno 2.7.13 (stable, release, x86_64-unknown-linux-gnu)

$ deno run --allow-all --no-prompt main.ts
[...644 Download lines...]
imported ok
constructed ok, name= test

Exit 0. No native binary loaded.

Dep tree empirical check

Against the fully resolved node_modules/ after that run:

$ find node_modules -name package.json | xargs grep -l "@libsql/client"
# (empty)

$ find node_modules -type d -name "libsql*"
# (empty)

$ find node_modules -name "*.node"
# (empty)

Also checked the metadata directly:

$ npm view @voltagent/core@2.7.1 dependencies | grep -i libsql
# (empty)

44 declared deps, none match libsql / sqlite / native. @libsql/client lives in @voltagent/libsql@2.1.2, which is a sibling package and not a transitive of core.

For what it's worth, core did ship @libsql/client as a dep through 0.1.70, removed before 1.0.0 (2025-09-12). Version 1.x+ does not carry it.

What would help

The report's "Tested on: April 22, 2026" and the <EXACT_VERSION_TESTED> placeholder made me wonder if the reproducing project actually pins a different version of core, or pulls in another @voltagent/* package alongside. Two things that would pin it down:

• The exact pinned version (npm:@voltagent/core@<x.y.z>) that fails on Supabase Edge.
• The full Deno error output: stack trace, the .node path Deno complains about, and which package inside node_modules/ owns it.

If Supabase Edge is reaching @libsql/client in the deployed bundle, the path has to show up in that error. Happy to push a fix if the chain turns out to be real, but I don't want to move on a bug I can't reproduce.