Description
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
This issue is related to https://github.com/orgs/supabase/discussions/35556, but our investigation shows that it’s a deeper problem within the Supabase Edge Runtime itself — specifically how it resolves dependencies when a custom npm registry is mounted under a subpath.
We’re using a private registry where the npm API is served under a subpath, e.g. http://registry.local/some-path/.
While the package installs and resolves correctly in the Deno environment (including editor LSP support), the Edge Runtime fails to locate the module at runtime and throws a boot error.
It appears that the user worker attempts to resolve the module using a malformed path that incorrectly includes parts of the registry URL as folders.
To Reproduce
We’ve created a minimal public reproduction using Verdaccio as a local npm registry:
https://github.com/toffee12312321/private-registry-issue-supabase
There are two scenarios:
- ✅ Working: Registry API mounted at
/ - ❌ Failing: Registry API mounted at
/some-path/
The failing case results in a BOOT_ERROR and log output indicating the module path resolution is incorrect (e.g. node_modules/localhost/some-path/...).
Important discovery:
Initially, our minimal repro package did not include any dependencies or devDependencies — and in that case, it worked fine.
The problem only arises once the imported package includes dependencies. This suggests that the bug is triggered during dependency resolution or import rewriting, not package loading itself.
Expected behavior
The Edge Runtime should correctly resolve and load npm packages even when the registry is hosted under a path prefix (e.g. /some-path/).
This is a valid and common setup in enterprise and self-hosted environments.
System information
- OS: macOS
- Version of Supabase CLI:
v2.22.12 - Version of Edge Runtime:
supabase/edge-runtime:v1.67.4