feat: accept RegExp values in Expression/thenElse for CORS options - #1944
feat: accept RegExp values in Expression/thenElse for CORS options#1944IzaakGough wants to merge 6 commits into
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
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
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.
…pression-for-cors-options
…pression-for-cors-options
cabljac
left a comment
cabljac
left a comment
There was a problem hiding this comment.
Nice work @IzaakGough, solid PR. Checked out the branch, ran the specs and compiled the #1943 repro against it, all good. The refOf fix and the two-branch E2E preflight tests are exactly the right shape. This all makes sense to me, but since it widens the public API (Expression, CorsOption, new ExpressionValue export) we'll run it by the Firebase team before it lands.
Small asks inline. One more on the issue itself: this fully fixes #1943 as filed, but the author also mentions wanting regex CORS patterns read directly from .env files (via #1903), which this doesn't cover (an env var string still won't become a RegExp). Since merge auto-closes the issue, please reply on the thread first clarifying that. Whenever a fix partially addresses what a reporter wants, say so before the close, otherwise they reopen confused.
| | boolean | ||
| | RegExp | ||
| | Array<string | RegExp>; | ||
| cors?: CorsOption; |
There was a problem hiding this comment.
HttpsOptions.cors now references CorsOption in the public API, but it isn't in this module's export list (line 54). I ran api-extractor against the branch and it flags (ae-forgotten-export) The symbol "CorsOption" needs to be exported by the entry point, so the docs render the type unlinked. It's a warning rather than a failure, and v1 has the same gap on master, but since we're touching this surface please add CorsOption to the export type {...} here and in v1's provider.
| * `Array<string | RegExp>` are additionally allowed so that expressions can | ||
| * select between literals for options that accept them, such as `cors`. | ||
| */ | ||
| export type ExpressionValue = |
There was a problem hiding this comment.
Tiny one: string[] is already covered by Array<string | RegExp>, so the union member is redundant for the type checker. Your comment explains it documents the param-holdable types, which is a fair reason to keep it, so your call. If you keep it, no change needed.
| * - Numbers and booleans are not quoted explicitly | ||
| */ | ||
| function refOf<T extends string | number | boolean | string[]>(arg: T | Expression<T>): string { | ||
| function refOf<T extends ExpressionValue>(arg: T | Expression<T>): string { |
There was a problem hiding this comment.
The doc comment above refOf still only describes strings, arrays, numbers and booleans. Please add a line for the new RegExp behavior (emitted as its quoted string form) so it matches what the function does.
2 participants
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