`functions deploy` fails to read `.npmrc` environment variables for private npm registry auth (workspace `deno.json`)

[addniner]

Bug report

Describe the bug

When using a root-level workspace deno.json at supabase/functions/deno.json (instead of per-function deno.json files), supabase functions deploy fails to resolve the environment variable in .npmrc.

The .npmrc file uses ${NPM_AUTH_TOKEN} for private registry authentication. functions serve reads this variable correctly (from supabase/functions/.env), but functions deploy does not — resulting in a registry authentication failure.

.npmrc configuration

@myorg:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=${NPM_AUTH_TOKEN}

The NPM_AUTH_TOKEN is provided via supabase/functions/.env, which functions serve loads automatically.

Project structure

supabase/functions/
├── deno.json              # Root workspace config
│   ├── "workspace": ["./*"]
│   └── "imports": {
│         "@my-private-pkg": "npm:@myorg/my-package@^1.0.0",
│         ...
│       }
├── .npmrc                 # Private registry auth
├── .env                   # NPM_AUTH_TOKEN=ghp_xxxxx
├── function-a/
│   ├── index.ts
│   └── deno.json          # Function-specific imports only
├── function-b/
│   └── ...
└── _shared/               # Shared utilities

Why this structure?
The official docs recommend per-function deno.json, but this creates a dependency management problem with _shared/ code — shared utilities would need their npm dependencies duplicated across every function's deno.json. A root workspace deno.json solves this. This approach is also discussed as practical in Discussion #33595.

Steps to reproduce

1. Set up the project structure above with a private npm package
2. Configure .npmrc with ${NPM_AUTH_TOKEN} environment variable
3. Set the token in supabase/functions/.env
4. Run supabase functions serve → Works, private package resolves correctly
5. Run supabase functions deploy → Fails, authentication error (.npmrc env var not resolved)

Expected behavior

functions deploy should resolve environment variables in .npmrc the same way functions serve does.

Workaround

Running functions serve before deploy makes it work. The serve process appears to cache the resolved npm packages, which deploy then picks up:

# In CI/CD pipeline:

- name: Start Supabase services
  run: supabase start -x imgproxy,supavisor,realtime,storage-api,studio,mailpit,logflare,vector

- name: Warm up functions (workaround)
  run: |
    supabase functions serve --no-verify-jwt &
    SERVE_PID=$!
    sleep 3
    # Must call a function that imports the private package
    curl -i --fail http://127.0.0.1:54321/functions/v1/health || true
    kill $SERVE_PID || true
    wait $SERVE_PID 2>/dev/null || true

- name: Deploy Edge Functions
  run: supabase functions deploy --no-verify-jwt --prune --yes

Important: The health endpoint must actually import the private package — simply running serve is not enough. The package needs to be loaded at least once.

// health/index.ts
import {} from "@my-private-pkg"; // Force package resolution

Deno.serve(() => new Response("ok", { status: 200 }));

This was discovered empirically after multiple failed attempts and has been the only reliable CI/CD method.

Environment

• Supabase CLI: v2.75.0
• Deno: v2.7.1
• OS: Ubuntu 24.04 (GitHub Actions) / macOS (local)

Related issues

• Support for Deno workspaces #3047 — Deno workspace support
• deno monorepo support does not support using dependencies in workspace packages #4550 — Workspace package dependencies not resolved
• fail to deploy functions that use deno workspace packages supabase#35021 — Deploy fails with workspace packages

[nathanschram]

Yeah, I think you've traced this correctly - functions serve and functions deploy handle env vars quite differently under the hood.

From reading the CLI source, serve.go calls parseEnvFile() which reads your supabase/functions/.env and injects all the parsed variables into the Docker container's environment. So NPM_AUTH_TOKEN is available to Deno when it resolves your .npmrc during serve.

bundle.go doesn't do any of that. The only env vars it passes to the bundling container are DENO_NO_PACKAGE_JSON=1 (conditionally) and NPM_CONFIG_REGISTRY (if set in the host environment via os.Getenv()). NPM_AUTH_TOKEN is never forwarded, so .npmrc's ${NPM_AUTH_TOKEN} resolves to an empty string and you get the auth failure.

Your functions serve workaround works because both commands share the same Docker volume for Deno's cache (/root/.cache/deno). Serve resolves and caches the private packages with the token, then deploy reads from that cache.

Your PR #4933 looks like the right fix and follows the same pattern as PR #3020 (which added NPM_CONFIG_REGISTRY forwarding). One thing worth noting - it forwards from the host env (os.Getenv), so it'll work for CI/CD pipelines where you set NPM_AUTH_TOKEN as an environment variable. It won't pick up the token from supabase/functions/.env for local dev though - that'd need bundle.go to call parseEnvFile() like serve.go does. Might be worth mentioning in the PR description so the maintainers can decide if they want both paths covered.

This is the same pattern as issue #959 from 2023 where DENO_AUTH_TOKENS wasn't being forwarded to the bundle container.

Let me know how the PR goes - happy to help if the maintainers want any changes.

[addniner]

Good point. This PR targets the CI/CD use case for now. Loading .env during deploy would be a larger change — happy to explore that in a follow-up if maintainers want it.