fix: trust discovered entry points for hyphenated functions

[IzaakGough]

Related to #8469

Companion SDK PR: #1896

This PR updates firebase-tools to trust the entryPoint emitted by firebase-functions discovery instead of re-deriving it from function ids.

Problem

The companion firebase-functions change fixes discovery for quoted export names containing hyphens, for example:

const func = onRequest((req, res) => {
  res.send("ok");
});

export { func as "dummystore-bot" };

After that SDK fix, the discovered entryPoint is correctly preserved as dummystore-bot.

However, firebase-tools still had two places that assumed hyphens should be converted into dot notation:

• gen2 deploy code set FUNCTION_TARGET by rewriting entryPoint with - -> .
• functions:shell reconstructed shell bindings from trigger.name instead of using the discovered trigger.entryPoint

That behavior is still correct for grouped exports like grouped.fn, but it is incorrect for flat quoted export names that literally contain hyphens.

Change

This PR makes firebase-tools use the SDK-provided entryPoint as the source of truth.

Gen2 deploy

cloudfunctionsv2 now sets:

• FUNCTION_TARGET = buildConfig.entryPoint

without rewriting hyphens to dots.

Functions shell

functions:shell now initializes REPL bindings from trigger.entryPoint rather than deriving a path from trigger.name.

This preserves both behaviors correctly:

• grouped exports continue to bind as nested paths like grouped.fn
• quoted export names with hyphens remain flat bindings like dummystore-bot

Tests

This PR adds or updates coverage for:

• gen2 deploy requests preserving a hyphenated FUNCTION_TARGET
• shell context initialization using trigger.entryPoint for both:
  • flat hyphenated names
  • grouped dotted entry points

Relationship To firebase-functions

This PR is the CLI-side follow-up to the primary SDK fix in firebase-functions.

On its own, this change improves correctness whenever entryPoint is already accurate. Together with the companion firebase-functions PR, it fixes the full quoted-hyphen export flow end to end.

Companion PR: #1896

Validation

Validated with:

• targeted cloudfunctionsv2 and shell-context regression tests
• the companion local firebase-functions fix
• a packaged end-to-end flow using:
  • npm pack on local firebase-functions
  • installing that tarball into local firebase-tools
  • npm pack on local firebase-tools
  • deploying from a throwaway test project using the packed CLI and packed SDK

That deploy successfully recognized and updated a function named dummystore-bot.

[gemini-code-assist]

Code Review

This pull request updates the Firebase Functions Shell and Cloud Functions v2 deployment to preserve hyphenated entry points instead of replacing hyphens with dots. It refactors the shell context initialization to use trigger.entryPoint directly and updates FUNCTION_TARGET accordingly, accompanied by new unit tests. The review feedback suggests replacing the any type in the context parameter of initializeFunctionsShellContext with unknown to align with the repository's TypeScript style guidelines.

[cabljac]

Nice cleanup, and the new shell spec covering the hyphenated and grouped cases is exactly what I was hoping to see.

One nit: now that we trust the discovered entryPoint instead of deriving it, the validation in src/deploy/functions/runtimes/discovery/v1alpha1.ts (assertBuildEndpoint, ~line 233) becomes the only guard on it, and I believe "" would still pass the "string" check and flow through to an empty FUNCTION_TARGET env var and a "" shell binding. Worth verifying I've read that right. Whenever we start trusting an upstream value at a boundary, the validation there should tighten to match. Please reject empty strings, e.g.

entryPoint: (ep) => typeof ep === "string" && ep.length > 0,

Follows the custom-validator pattern already used for platform two lines up, so should be a cheap change.

[cabljac]

lgtm, one small comment

I think this + the SDK equivalent are safe independent of each other, but users wont see a fix until they update both right?

[IzaakGough]

yeah both fixes are needed for #8469