[CorieW]

Rejects the .env values the extension refuses at install time, so the kit's deploy fails instead of deploying and quietly deleting less data. Values the extension accepts, its option labels included, still deploy and run as they did in the extension. Fixes #3258 (part of #3249).

Changes

• assertValidParams() in src/config.ts. It reads each param's declared input (no copied lists): a select value must be one of the option values or labels, and a text value must match its validationRegex. The error names the param, the bad value and the allowed values, and lists every bad param at once.
• Unset and empty values are skipped, so optional params can stay blank as in the extension. Blank required params are still handled by assertRequiredParams() (see decision(delete-user-data): kit/extension parity – blank required params fail the kit deploy, the extension uses defaults #3256).
• assertParams() runs both checks at module load and throws once, so a blank required param and an invalid value are reported in the same deploy. assertRequiredParams() itself is unchanged, as the other kits share it.
• Option labels (Recursive, Shallow, Yes, No, United States, Belgium, Singapore) are accepted, as the extension's installer accepted them. They run as they did in the extension: Recursive deletes shallowly, Yes leaves auto-discovery off, and a location label gives a database URL that doesn't exist. The README warns about this and says to use the values.
• Tests in tests/valid-params.test.ts and tests/index.test.ts. README (Configuration) and CHANGELOG updated.
• Issue edit: the "Precedent: feat(storage-resize-images): reject unknown IMAGE_TYPE values at config resolve time #3124" line now points at the existing assertRequiredParams() / validatePathListsFromEnv() pattern. feat(storage-resize-images): reject unknown IMAGE_TYPE values at config resolve time #3124 was closed; fix(storage-resize-images): reject unsupported IMAGE_TYPE values #3169 (open, into next) proposes the IMAGE_TYPE checks.

Example error:

Error: Invalid parameter values: FIRESTORE_DELETE_MODE="RECURSIVE" must be one of: recursive, shallow. Fix them in this instance's .env or .env.<projectId> file, or remove the entries to use their defaults.

Testing

Deployed on a test project: the extension firebase/delete-user-data@0.1.30, the kit from kits and the fixed kit, each with its own Firestore database. Each had FIRESTORE_PATHS=users/{UID} and was seeded with users/<uid>, users/<uid>/sub/s1, things/t-<uid> {uid} and a control doc; then a test user was deleted.

Bad values (extension checked with the instances API validateOnly=true; kits with a real firebase deploy):

.env value	Extension	Kit before	Kit after
FIRESTORE_DELETE_MODE=RECURSIVE / recursivex	rejected	deploys	deploy fails
FIRESTORE_DELETE_MODE=Recursive (label)	accepted	deploys	deploys¹
ENABLE_AUTO_DISCOVERY=true / YES	rejected	deploys	deploy fails
SELECTED_DATABASE_LOCATION=us-east1 / US-CENTRAL1	rejected	deploys	deploy fails
SELECTED_DATABASE_INSTANCE=https://x.firebaseio.com	rejected	deploys	deploy fails
CLOUD_STORAGE_BUCKET=gs://x / Upper_Case	rejected	deploys	deploy fails
blank SELECTED_DATABASE_INSTANCE / SELECTED_DATABASE_LOCATION	accepted	deploys	deploys

¹ The deploy run rejected labels; accepting them came later (32a478f) and is covered by unit tests, not a fresh deploy.

The kit before deployed with all five bad values in one .env; the runtime env held them as written.

User deletion (extension and fixed kit with recursive / yes, kit before with RECURSIVE / true):

Doc	Extension	Kit before	Kit after
users/<uid>	deleted	deleted	deleted
users/<uid>/sub/s1	deleted	left behind	deleted
things/t-<uid> (uid field, auto-discovery)	deleted	left behind	deleted
control doc	kept	kept	kept

The kit before logged firestoreDeleteMode: "RECURSIVE", enableAutoDiscovery: false and a non-recursive delete.

Unit tests: vitest run passes (16 files, 165 tests), including every option label being accepted and a blank required param plus an invalid value being reported in one error. Prettier passes on the changed files. tsc passes, but only with a temporarily available @types/node: on kits, pnpm build fails with TS2688: Cannot find type definition file for 'node' because @types/node isn't installed, which this change doesn't cause.

Other kits read .env the same way and probably have the same gap.

[gemini-code-assist]

Code Review

This pull request introduces deploy-time validation for .env configuration parameters in the delete-user-data kit to prevent silent misconfigurations. It adds the assertValidParams function to validate parameter values against allowed options or regex patterns, calls this validation at module scope, updates the documentation and changelog, and includes comprehensive unit tests. The review feedback suggests a minor improvement in config.ts to avoid redundantly wrapping validationRegex in a new RegExp constructor if it is already a RegExp object.