deno compile: workers cannot fetch remote modules at runtime

[sigmaSd]

Description

When using deno compile to create a standalone binary, workers that dynamically import remote modules (JSR, https, etc.) fail at runtime with "Module not found: blob:null/...".

The same code works fine with deno run.

Reproduction

// main.ts
const workerCode = \`
  import \"jsr:@std/fs@1.0.0\";
  self.postMessage({ type: 'ready' });
\`;

const blob = new Blob([workerCode], { type: "application/typescript" });
const url = URL.createObjectURL(blob);

const worker = new Worker(url, {
  type: "module",
  deno: { permissions: { net: true, read: true } },
});

worker.onmessage = (e) => {
  console.log("SUCCESS:", e.data);
  Deno.exit(0);
};

worker.onerror = (e) => {
  console.error("FAILED:", e.message);
  Deno.exit(1);
};

setTimeout(() => { Deno.exit(1); }, 5000);

# Works
deno run -A --unstable-worker-options main.ts

# Fails with "Module not found: blob:null/..."
deno compile -A --unstable-worker-options -o repro main.ts && ./repro

Expected

The compiled binary should be able to fetch remote modules at runtime, just like deno run does.

Actual

error: Uncaught (in worker "") Module not found: blob:null/d3f3c72f-d9ba-4714-91ab-e8c83e3b987c

Version

Deno 2.7.11

Additional notes

This is particularly problematic for plugin systems that load plugins from JSR/npm URLs at runtime. The workaround is to use deno run instead of compiled binaries.

[dsherret]

I don't think deno compile should have this support because it would mean further bloating the denort binary with caching logic and a whole bunch of other stuff. Instead I think deno compile should support custom loaders and then someone could hook up jsr:@deno/loader if they needed this.