feat: accept RegExp values in Expression/thenElse for CORS options - #1944
Open
IzaakGough wants to merge 4 commits into
Open
feat: accept RegExp values in Expression/thenElse for CORS options#1944IzaakGough wants to merge 4 commits into
IzaakGough wants to merge 4 commits into
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request extends the Expression type and related helper functions to support RegExp and Array<string | RegExp> types, enabling dynamic selection of CORS origins via ternary expressions. It also updates the cors option in HTTPS options to use the shared CorsOption type and adds comprehensive unit tests. However, a high-severity issue was identified in src/params/types.ts where a single RegExp (not wrapped in an array) falls through to the default else block in refOf, resulting in an unquoted string representation that is invalid in CEL. A suggestion has been provided to explicitly handle RegExp and wrap its string representation in JSON.stringify.
A single RegExp (not wrapped in an array) passed to thenElse fell through to arg.toString(), producing an unquoted /pattern/ in the generated CEL string, which is invalid and fails at deploy time.
…pression-for-cors-options
IzaakGough
marked this pull request as ready for review
August 6, 2026 12:25
Replace the eight inline copies of the Expression type bound with a single exported ExpressionValue alias, so future additions to the set of values an Expression can resolve to only need editing in one place. Also close two gaps in the new tests: - the nested thenElse case resolved the outer true branch, so the nested expression was never evaluated. Drive it from the false branch instead and assert both inner branches. - the onRequest CORS case only asserted the true branch, so an implementation that always returned ifTrue would have passed. Add the false-branch case, asserting the non-matching origin is not allowed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1943
Expression<T>was constrained tostring | number | boolean | string[], so a param ternary could not select betweenRegExpvalues even thoughcorsaccepts them. Users hit a type error when writing something likeparams.defineBoolean("X").thenElse(/a\.com$/, /b\.com$/)for a v2 HTTPS function'scorsoption.This widens the
Expressiontype parameter to a new exportedExpressionValueunion that also coversRegExpandArray<string | RegExp>, adds those expression forms toCorsOption, and fixes CEL serialization so aRegExpis emitted as its string form rather than being dropped byJSON.stringify(which turns/foo/into{}).relnote: none