Skip to content

fix: trust discovered entry points for hyphenated functions#10573

Open
IzaakGough wants to merge 2 commits into
mainfrom
@invertase/fix-function-names-which-include-hyphens-clean
Open

fix: trust discovered entry points for hyphenated functions#10573
IzaakGough wants to merge 2 commits into
mainfrom
@invertase/fix-function-names-which-include-hyphens-clean

Conversation

@IzaakGough
Copy link
Copy Markdown

@IzaakGough IzaakGough commented May 28, 2026

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.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

const serveFunctions = new FunctionsServer();

export const initializeFunctionsShellContext = (
context: Record<string, any>,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

According to the repository style guide (GEMINI.md, line 38), any should not be used as an escape hatch. Since context is a REPL context object that can hold arbitrary values, we should type it as Record<string, unknown> instead of Record<string, any>.

Suggested change
context: Record<string, any>,
context: Record<string, unknown>,
References
  1. Never use any or unknown as an escape hatch. Define proper interfaces/types or use type guards. (link)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants