Functions deploy: shipped package-lock.json pins the developer's registry, blocking private-registry environments

What happened?

rayfin functions init + rayfin up package rayfin/functions/ as a source-only zip (node_modules/ and dist/ excluded) and upload it to /__private/functions/deploy, where the build host runs its own npm install. The zip includes package-lock.json.

That lockfile is generated on the developer's machine, so every resolved URL points at whatever registry that developer installs from. In an enterprise environment where npm is proxied through a private registry (JFrog Artifactory in our case), all 31 entries resolve to https://<company>.jfrog.io/artifactory/api/npm/<repo>/... — a host the Fabric build host presumably has neither a route to nor credentials for.

To be upfront: I stopped before deploying rather than risk it, so I have not observed the remote failure. I would like to confirm whether this is the expected outcome and what the intended path is, rather than guess and build a workaround you may be about to obsolete.

Two things make this higher-stakes than a normal packaging wrinkle:

• A functions-deploy failure rethrows and fails the whole rayfin up. So turning functions on couples an otherwise-healthy app deploy to this, which makes it hard to trial incrementally on a real app.
• @microsoft/fabric-user-data-functions is declared as "experimental" — a floating dist-tag. It moved from 1.35.0-alpha.1412 to 1.35.0-alpha.1541 within a single working session. If the remote build runs npm install, the shipped lockfile pin isn't authoritative; if it runs npm ci, then an unpublished alpha would break previously-working deploys retroactively.

Questions

1. What is the intended flow for private or proxied registries? Options I considered, none documented: rewriting resolved hosts at package time; a supported --registry / .npmrc passthrough for the remote build; or vendoring tarballs as relative file:./*.tgz dependencies. The packager's own validator hints at the last one (external-file-dep, and the message "Local packages must use relative file:./*.tgz paths") — is that route supported, and does it extend to transitive dependencies?
2. Does the remote build run npm ci or npm install? The fact that a lockfile is generated when absent ("No package-lock.json on disk — generating one from package.json for deploy") suggests ci, but it isn't stated anywhere I could find.
3. Does the functions host permit arbitrary outbound HTTPS? There is no mail-capable AudienceType, so a "notify by email" function has to call an external HTTP endpoint (a Power Automate trigger, for example). The bundled rayfin-functions agent skill documents fetch against OneLake with an OBO token, but that doesn't settle whether general egress is allowed. Documenting this either way would save people guessing.

Steps to reproduce

1. Configure npm to install through a private registry (e.g. npm config set registry https://<company>.jfrog.io/artifactory/api/npm/<repo>/).
2. In an existing Rayfin app: npx rayfin functions init.
3. Inspect rayfin/functions/package-lock.json — every resolved URL points at the private registry, not registry.npmjs.org.
4. Set services.functions.enabled: true and run npx rayfin up. The zip uploaded to the build host carries that lockfile.

Environment

• Rayfin CLI: 1.34.0
• @microsoft/fabric-user-data-functions: experimental → resolved to 1.35.0-alpha.1541
• Node: 24.x
• OS: Windows 11
• npm proxied through a private registry (JFrog Artifactory)

Notes

Happy to test any suggested approach and report back — we have a scaffolded functions project ready and a concrete use case (invoke from the app, read a selected record, notify the signed-in user). The packages themselves resolve fine through our proxy; it is only the lockfile shipped to the remote build host that is the problem.

Start with the package produced by npx rayfin functions init at rayfin/functions/package-lock.json, then reproduce the private-registry setup and inspect the zip uploaded by npx rayfin up. Done means establishing how the remote build handles the lockfile, registry access, and outbound HTTPS, then documenting or implementing the supported deployment path.