supabase / edge-runtime

A server based on Deno runtime, capable of running JavaScript, TypeScript, and WASM services.
MIT License
640 stars 55 forks source link

Private npm packages cannot be imported in edge functions: `npm package '@org/package' does not exist.` #402

Open elyobo opened 3 weeks ago

elyobo commented 3 weeks ago

Bug report

Not clear if this is a bug report or feature request; deno has added this functionality but I don't understand the implications for the edge runtime and whether this support in deno means it should automatically be supported or not.

Describe the bug

Deno now supports private registries, but supabase's local supabase functions serve does not seem to.

I have a private package in my package.json, my editor is happy with the import, and I can run it directly with Deno using deno run --allow-net supabase/functions/auth/index.ts but when running via supabase functions serve and invoking via curl I receive output like the following

serving the request with /Users/elyobo/src/project/supabase/functions/auth
failed to load 'npm:@org/package': npm package '@org/package' does not exist.
An error has occured
InvalidWorkerCreation: worker boot error failed to load 'npm:@org/package': npm package '@org/package' does not exist.
    at async UserWorker.create (ext:sb_user_workers/user_workers.js:145:15)
    at async Object.handler (file:///root/index.ts:147:22)
    at async respond (ext:sb_core_main_js/js/http.js:163:14) {
  name: "InvalidWorkerCreation"
}

To Reproduce

Expected behavior

The private npm package should be imported.

Screenshots

N/A

System information

Additional context

deno added support recently in https://github.com/denoland/deno/issues/16105; when running the function code directly in deno I tested with these versions

✗ deno --version
deno 1.45.5 (release, aarch64-apple-darwin)
v8 12.7.224.13
typescript 5.5.2

I've also tried shifting the relevant .npmrc which configures the private registry and access token around from ~/ to supabase and supabase/functions but with no change in results.

elyobo commented 2 weeks ago

@nyannyacha this issue is unrelated to self hosting, as far as I know - I have only experienced it in local development, but we plan on hosting with Supabase, does the self-hosted tag imply that it won't be a problem in production (still a pain to develop if so, but better than nothing).

nyannyacha commented 2 weeks ago

Hello @elyobo Sorry if that was confusing 😅

The private registry you are requesting is a feature that was already introduced in Deno 1.44, as you may already know.

We recently versioned the Deno code base of the edge runtime to 1.45.x, and there is some work that needs to be done on the edge runtime side to get this feature.

Functions on the Supabase Hosted can be defined as passing a bundle command to the edge runtime running inside Docker via the cli to generate an eszip binary, which is then uploaded.

This is a feature that needs to be implemented within the edge runtime repository, not privately in the Supabase Hosted domain, because the private registry will be referenced during the eszip bundling process. That's why I've tagged it self-hosted.

Also, just because Deno, the upstream has version up, doesn't mean that edge runtime will support the latest features right away, we are version up the codebase over a period of time.

There are a few things I'm currently working on, so I'm not sure when I'll be able to bring this feature to you.

But I'll let you know if there are any updates.

Have a good day!

elyobo commented 2 weeks ago

Thanks @nyannyacha, that all makes sense! As noted in the original issue, I am aware that the Deno support was recent so wasn't sure to record this as a bug or a feature request 😅

Great to know it's in the works though! I've worked around the requirement for the moment by copying in the required code instead but will be happy to replace that kludge once private package support lands.