Big increase in edge function script size in v1.69.1 vs 1.68.3

[adbl]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Without any changes in our code, our edge functions script size (as reported by supabase functions deploy) have increased by around 50% with the recent supabase cli versions with upgraded edge-runtime (v1.68.3 -> v1.69.1) supabase/cli#4064
This started happening in supabase cli version 2.38.1

Our ./supabase/functions/<function> are part of workspace defined in ./deno.json`, not sure if that is relevant.

Our functions:

	deno info	2.38.0	2.38.1
bot	128.02 MB	14.49 MB	21.91 MB
index-knowledge	59.44 MB	7.07 MB	10.45 MB
local-test	66.02 MB	7.983 MB	11.18 MB
message-worker	126.16 MB	13.26 MB	20.23
schedules	147.78 MB	15.05 MB	23.54 MB

To Reproduce

1. Create a supabase edge function
2. Add some dependencies, here's an example deno.json from our project where this can be observed.

   {
    "imports": {
      "@openai/openai": "jsr:@openai/openai@^4.88.0",
      "@types/express": "npm:@types/express@^5.0.0",
      "botbuilder": "npm:botbuilder@4.23.2",
      "botbuilder-core": "npm:botbuilder-core@4.23.2",
      "botframework-schema": "npm:botframework-schema@4.23.2",
      "drizzle-orm": "npm:drizzle-orm@^0.44.4",
      "drizzle-orm/": "npm:/drizzle-orm@^0.44.4/",
      "express": "npm:express@^5.1.0",
      "pg": "npm:pg@^8.15.6",
      "rrule": "npm:rrule@^2.8.1",
      "zod": "npm:zod@^3.24.2"
    },
    "compilerOptions": {
      "types": ["npm:@types/pg", "npm:@types/express"]
    }
   }
   
   

3. run npx supabase@2.38.0 functions deploy <function-name>, check the output for Deploying Function: ... (script size: <size-1>)
4. run npx supabase@2.38.1 functions deploy <function-name>, check the output for Deploying Function: ... (script size: <size-2>)
5. Observe how size-2 is noticeably bigger than size-2.

Expected behavior

Size should be roughly the same.

System information

Irrelevant.

[nyannyacha]

Could you explain the reproduction step in more detail?
When I created a bundle based on the following snippet, which imports all packages defined in the imports section of the provided deno.json, I didn't see a significant difference. (In fact, the bundle size for 1.69.1, i.e., Deno 2.1, was smaller.)

index.ts

import a from "@openai/openai";
import b from "botbuilder";
import c from "botbuilder-core";
import d from "botframework-schema";
import e from "drizzle-orm";
import e1 from "drizzle-orm/pg-core";
import f from "express";
import g from "pg";
import h from "rrule";
import i from "zod";

console.log(
    a,
    b,
    c,
    d,
    e,
    f,
    g,
    h,
    i,
    e1,
);

deno.json

{
  "imports": {
    "@openai/openai": "jsr:@openai/openai@^4.88.0",
    "@types/express": "npm:@types/express@^5.0.0",
    "botbuilder": "npm:botbuilder@4.23.2",
    "botbuilder-core": "npm:botbuilder-core@4.23.2",
    "botframework-schema": "npm:botframework-schema@4.23.2",
    "drizzle-orm": "npm:drizzle-orm@^0.44.4",
    "drizzle-orm/": "npm:/drizzle-orm@^0.44.4/",
    "express": "npm:express@^5.1.0",
    "pg": "npm:pg@^8.15.6",
    "rrule": "npm:rrule@^2.8.1",
    "zod": "npm:zod@^3.24.2"
  },
  "compilerOptions": {
    "types": ["npm:@types/pg", "npm:@types/express"]
  }
}

[adbl]

Thanks for quick response!

That’s interesting. Maybe it’s caused by something in our setup. I will try to provide a minimal repro.

I didn't dig deep into it, but how can I actually look at the final "bundle" produced within the edge-runtime container? My observations come from the supabase cli when it uploads.

[nyannyacha]

Hello @adbl

I didn't dig deep into it, but how can I actually look at the final "bundle" produced within the edge-runtime container? My observations come from the supabase cli when it uploads.

If you want to set up the environment to run/debug edge-runtime yourself, I recommend reading this section.
You can try running the bundle command directly after compiling edge-runtime inside the devcontainer.

Compile is done automatically when you type ./scripts/run.sh in the terminal.

After that, type ./target/debug/edge-runtime bundle --entrypoint <your_script_path>/index.ts. This will create bin.eszip. This is your function's bundle. (Note that the size of this bundle itself may be larger than you think. This is because the size of the bundle you see through the supabase cli is probably the compressed size.)

[adbl]

Investigation...

---

Initial attempt at trying to use edge-runtime bundle --entrypoint supabase/functions/<function>/index.ts --import-map supabase/functions/<function>/deno.json within the dev container (@v1.69.1) in our repo results in:

Error: Failed reading lockfile at '/workspaces/<our-repository>/deno.lock' (the workspace deno.json)

Caused by:
    Unsupported lockfile version '5'. Try upgrading Deno or recreating the lockfile

Maybe a clue. Why doesn't the supabase cli fail the same way when bundling? ...

---

[adbl]

@nyannyacha I'm observing the same as you, the bin.eszip bundle is slightly smaller (e.g. when bundling with edge-runtime 1.69.1, e.g.

-rw-r--r--   1 andreas  staff   139M Aug 27 14:15 bin-schedules-1.68.3.eszip
-rw-r--r--   1 andreas  staff   138M Aug 27 16:25 bin-schedules-1.69.1.eszip

However, the supabase cli shows the compressed script size as 23 MB vs 15 MB. So has something changed with the compression that happens after bundling? Is that in edge-runtime or supabase/cli ?

[nyannyacha]

@adbl I don't yet have a clear idea about what exactly is causing the compressed size increase, but at least we can narrow down the problem domain to confirm it's not an issue introduced by the edge runtime.

The cause may likely exist in the CLI code or the hosted function bundler on the Supabase side.
We will investigate this issue internally and provide further details once we have more information.

Thanks for testing it locally yourself!

[adbl]

Awesome, we have pinned the previous version in our CI so we are not blocked but of course would like to get this resolved and be able to use deno 2.

[adbl]

@nyannyacha let me know if I should send the troublesome bundle.

[nyannyacha]

@adbl Those bundles may prove useful for the investigation.
I would appreciate it if you could send them to nyannyacha@supabase.io.

[nyannyacha]

@adbl I'm delighted to share some good news.

I've identified the cause of the compression size regression.
It appears to be a regression in the bundling function of edge-runtime, which was rewritten for Deno 2.1.

Specifically, it turns out that the layout of content within the bundle has been randomly shuffled since version 1.69.x (i.e., Deno 2), preventing the Brotli encoder we use from achieving an optimal compression ratio.

I'm currently testing the fix locally based on the snippet I posted above, and it shows about a 34% improvement compared to before the fix. I can't be certain this ratio will hold when your function is bundled, but the regression appears to be gone.

	original	compressed
before fix	114.5MB	14.9MB
after fix	114.5MB	9.8MB

I'll submit a PR soon, and once merged, you can test it.
Thank you!