Repository navigation
feat(config): accept env() on number, boolean, enum and list fields in the config schema - #7333
Conversation
…lds in the config schema The loader resolves env(VAR) on any field and coerces it to the field's type, but the published CLI config schema typed number, integer, boolean and enum fields strictly, so env() references there showed as editor errors. Those fields now accept their usual value or an env() string matching the loader's syntax. The project-config schema is unchanged, since it describes resolved values. Closes CLI-2857
There was a problem hiding this comment.
Superseded by a newer AI review
🤖 AI Review
Both independent reviews completed with no findings. My code inspection found no additional actionable issues. All 366 targeted leaves have an env() branch, and removing those branches exactly restores the trusted generated schema. Loader compatibility and unchanged ProjectConfig behavior were verified by inspection. Tests were not run because dependencies are absent.
Findings
No issues found.
Stats
Claude findings: 0 · Codex findings: 0 · Confirmed: 0 · Refuted: 0 · Uncertain: 0
Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
…nst the loader String-list fields such as auth.additional_redirect_urls now accept an env() reference in place of the whole list, matching the loader's comma-split coercion. The copied-rule test is replaced by an agreement test that, for every leaf in the CLI schema, checks the published schema accepts env() exactly when the loader resolves it. Unused keyword entries are dropped.
|
/ai-review |
There was a problem hiding this comment.
🤖 AI Review
Both independent reviews were available. Claude's single finding is confirmed as a latent nit: annotated env() union members receive a redundant branch without changing validation. Codex reported no findings. No blocking issues identified.
Findings
| Severity | Location | Category | Sources | Claim |
|---|---|---|---|---|
| ⚪ NIT | packages/config/src/json-schema-document.ts:98 |
correctness |
claude | Existing env() union members carrying annotations such as x-secret or description are not recognized, causing an additional redundant env() branch. |
Stats
Claude findings: 1 · Codex findings: 0 · Confirmed: 1 · Refuted: 0 · Uncertain: 0
Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: manual · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
avallete
left a comment
There was a problem hiding this comment.
LGTM. Checked the published schema against the real-world sample configs and develop's schema. env() is accepted on number, boolean, enum, string-list and union fields, while typos like max_rows = "1000", pool_mode = "statement" and enable_signup = "true" are still rejected. Hover docs are unchanged, and project-config.schema.json is byte-identical to develop's. A Codex review at c19ef9c3d also approved it, including the fix for annotated env() options.
Non-blocking:
- No field in
config.schema.jsonis a list of enum values today, so the rule that rejectsenv()there is only covered by the unit test. It's worth keeping that test when such a field is added. - The PR moves
typeintoanyOfon these fields. That's a visible change for anyone generating types fromconfig.schema.json, so it may deserve a line in the release notes.
|
thanks for checking it against the real configs!
|
Summary
The config loader resolves
env(VAR)on any field and then coerces it to the field's type, but the publishedconfig.schema.jsontyped number, integer, boolean, enum and string-list fields strictly. Somax_rows = "env(MAX_ROWS)"loads fine but shows as an error in the editor.Those fields now accept either their usual value or a string matching the loader's
env()syntax. A mistyped literal likemax_rows = "1000"orpool_mode = "statement"still fails.toPublishedJsonSchemaDocumenttakes anacceptEnvReferencesoption, and the CLI config schema turns it on. Each affected field becomes ananyOfof its original type and anenv()string, withdescription,defaultandexampleskept on the outer node so hover docs look the sameauth.additional_redirect_urlsaccept anenv()string in place of the whole list, since the CLI splits the resolved value on commas. Lists of enums don't, as the loader doesn't split thosestorage.file_size_limit) get one extraenv()branch rather than a nested oneproject-config.schema.jsondoesn't change, since it describes values afterenv()has been resolvedapps/docs/public/cli/config.schema.jsonis regeneratedajvis added as a dev dependency of@supabase/configso tests can check the published schema against what the loader acceptsSchema shape change
If you generate types or other tooling from
config.schema.json, the affected fields now read as a union: theirtypemoves from the field itself into the firstanyOfbranch, next to theenv()branch. Configs that validated before still validate.Linked issue
Closes CLI-2857