fix(functions): resolve nested ternary CEL expressions in params

[Om-singhaI]

Description

Fixes #7755.

A v1 runWith option built from a nested thenElse makes firebase-functions emit a chained CEL ternary into functions.yaml, and the emulator then fails to load the function:

FirebaseError: CEL tried to evaluate param."xxx" ? "aaa" : params.PROJECT_ID == "yyy" in a context which only permits literal values

The cause is in src/deploy/functions/cel.ts. The ternary regexps used a greedy (.+), so the last " ? " and " : " in the string ended up as the delimiters and the condition swallowed the first ternary whole. The two sibling forms are worse, because their conditions are anchored on params.X tokens and still parse, so only the branches split in the wrong place and they quietly return the wrong value with no error. On main, {{ params.FLAG ? "a" : params.OTHER ? "b" : "c" }} with FLAG false and OTHER true returns "c" where "b" is correct.

A regexp can't express this: ternaries nest to any depth, the SDK emits them without parentheses, and a quoted literal is allowed to contain either token. So this replaces them with a left to right scan that tracks quoting and pairs delimiters by depth. The condition it produces is dispatched to the comparison evaluators that already exist, which leaves comparison semantics, type coercion checks and error messages untouched. Branch evaluation is now recursive so a branch can be a ternary itself, and wantType is threaded down unchanged, so every leaf is still type checked exactly as before.

Three shapes behave differently from main:

• Delimiters that can't be paired up now raise. Before, a " ? " with no matching " : " fell through to isComparisonExpression(), and resolveComparison() takes no wantType, so a string field came back as a boolean.
• A ternary that isn't the whole expression is rejected, since the body now has to start with {{ and end with }}. resolveString() only ever hands the resolver whole {{ ... }} substrings, so that matches what it passes.
• A value holding a double quote alongside a " ? " or a " : " is ambiguous. The SDK builds string operands as "${value}" without escaping, and nothing can tell a value's own quote from a real one. Where a split would cut a branch in half the expression is rejected, so most of these raise where main resolved them, and in rarer nested shapes the two disagree on the value instead. Expressions whose quotes line up are unaffected, and a " : " with no " ? " anywhere is left to the comparison evaluators exactly as before.

That structural check runs when the expression is split rather than only on the branch that gets selected, so a broken expression raises whichever way the params point. Resolution stays lazy about param values, so a missing param in a branch that is never selected still doesn't raise.

Scenarios Tested

Unit tests in src/deploy/functions/cel.spec.ts, beside the source as CONTRIBUTING asks, plus one in src/deploy/functions/params.spec.ts for the resolveString() path. cel.spec.ts is at 62 passing, up from 41. Reverting only cel.ts to main and rerunning both specs gives 15 failures, 14 and 1, including the exact error from the issue, so the new cases pin the fix rather than the implementation.

Covered:

• the expression from the issue, asserted for all three values of PROJECT_ID, and the same shape with number branches
• nesting in either branch, and a chain three levels deep with each of the four arms selected in turn
• the boolean param and dual param forms that silently returned the wrong branch
• params, lists and literals as branches of a nested ternary, with type checking
• quoted branches holding " ? " or " : ", in the true branch and in the false branch
• values holding double quotes, in the condition and in either branch, as a list element, and written by hand as \"
• a nested ternary interpolated into a longer string through resolveString(), and one sitting next to a second expression, which is how serviceAccount and vpcConnector reach the resolver
• the rejected shapes above, plus a missing delimiter, an empty branch, {{ }}, a bare colon, the double question mark form, a missing param in a nested branch and in a nested condition, a branch of the wrong type, and loose whitespace such as {{ params.FOO == 22 ? 10 : 0 }}

Also ran npx mocha src/deploy/functions/build.spec.ts alongside the two above, 114 passing, since that module imports cel.ts, plus npm run test:compile, which is clean. prettier --check passes on the changed files. eslint reports no errors and no new warnings.

Sample Commands

No commands or flags change. To run the affected tests:

npx mocha src/deploy/functions/cel.spec.ts src/deploy/functions/params.spec.ts

[gemini-code-assist]

Code Review

This pull request replaces the regular-expression-based parsing of CEL ternary expressions with a manual scanner and parser to support nested ternaries of any depth and correctly handle string literals containing double quotes or delimiters. It also adds comprehensive unit tests for these scenarios. The review feedback points out a redundant check in splitTernary where rescanned.kind === "misquoted" is evaluated, which can be simplified since scanTernary with ignoreQuotes set to true will never return a misquoted status.

[gemini-code-assist]

Since rescanned is obtained by calling scanTernary(body, true) with ignoreQuotes set to true, it can never return { kind: 'misquoted' }. Therefore, the check rescanned.kind === 'misquoted' is redundant and will always evaluate to false. We can simplify this statement to just return rescanned;.

Suggested change

	return rescanned.kind === "misquoted" ? { kind: "none" } : rescanned;
	return rescanned;

[Om-singhaI]

You're right that the case can't happen at runtime, which is what the comment above the line says. The check is still doing work for the compiler though: scanTernary is declared as returning TernaryScan, which is wider than this function's return type, so return rescanned; fails npm run test:compile with TS2322: Type 'TernarySplit | { kind: "misquoted"; }' is not assignable to type 'TernarySplit'. I'd rather keep the narrowing than widen the return type or assert past it.