supabase functions serve and private packages

[elyobo]

Is your feature request related to a problem? Please describe.

Support for .npmrc authentication for private packages was added in supabase/edge-runtime#427 but in order for private packages to work a .npmrc needs to be placed in the directory for each and every function.

Describe the solution you'd like

For local development, it would be great to respect the general .npmrc rules (find the cloest up the directory structure).
For deployment to production, a .npmrc in supabase/functions that's used for all would probably make sense (and this would fit with the suggestion above).

Describe alternatives you've considered

Adding .npmrc to the .gitignore and copying them to each directory as required is viable, but the requirement should be spelled out in docs I guess (although I don't know where I would have expected to find them).

Additional context
N/A

[JohnBra]

@elyobo I looked into this and made it work locally with the current cli version as follows:

1. create a new edge function (i just created the hello-world example)
2. delete .npmrc from the newly created function directory
3. create .npmrc up the directory tree, but not higher than supabase/functions
4. add a private package ref like so:

#.npmrc
@johnbra:registry="https://npm.pkg.github.com"
//npm.pkg.github.com/:_authToken=<TOKEN>
registry=https://registry.npmjs.org/

5. reference your package in your function like so:

import { appendExclamationMark } from "npm:@johnbra/[email protected]";
// ...

Currently, the local directory supabase/functions is bound to the container, i.e. everything above isn't. This means the supabase root directory including config.toml etc. aren't visible to the edge-runtime. As long as you place your .npmrc in the supabase/functions directory or in children of it, it should work.

I'm not sure if I'm missing something, but I think this should solve your problem since the supabase/functions dir should be the root for all functions (please correct me if I'm wrong) and @nyannyacha's implementation of find_up should look for the closest .npmrc up the tree.

I haven't tested if this works with the deploy command.

[elyobo]

Thanks @JohnBra, if that's the case that's pretty manageable, I'll give it a go.

[JohnBra]

Glad to help @elyobo!
I just tested deployment and that seems to work as well. Hope that helps.

[JohnBra]

@elyobo did that work for you?

[elyobo]

The import maps docs have had a few changes in recent times that seem relevant and they're strongly recommending ".npmrc per function".

I see the same behaviour as you (and I can see that this was documented that way earlier, but it's now recommended against although still documented as an option) with a .npmrc in supabase/functions working. In my case the .npmrc would just be identical in each anyway (adding a token with access to our private packages); the doc could go into more detail as to the rationale for the rationale behind maintaining strict isolation between functions and how that applies to e.g. the shared code between them (and the implications of per-function import maps on that shared code as well 😵).

Anyway, this seems to be working as per the docs. My "Describe the solution you'd like" answer would like the general .npmrc hierarchy even above supabase/functions to work for a painless DX, but the docs being correct addresses my "alternatives you've considered" complaint (per function and global options are now documented) so we can close this off if there's no interest in implementing my dream solution :)

[elyobo]

Closing because this does work as documented now. Minimal benefit (and possible confusion when it fails to deploy) from my suggestion of picking up a local .npmrc e.g. in the user's home dir during development.