Skip to content

feat(config): accept env() on number, boolean, enum and list fields in the config schema - #7333

Merged
Coly010 merged 4 commits into
developfrom
columferry/cli-2857-accept-env-references-on-number-and-boolean-fields-in-the
Oct 27, 2026
Merged

Coly010 merged 4 commits into
developfrom
columferry/cli-2857-accept-env-references-on-number-and-boolean-fields-in-the

Conversation

@Coly010

@Coly010 Coly010 commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Summary

The config loader resolves env(VAR) on any field and then coerces it to the field's type, but the published config.schema.json typed number, integer, boolean, enum and string-list fields strictly. So max_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 like max_rows = "1000" or pool_mode = "statement" still fails.

  • toPublishedJsonSchemaDocument takes an acceptEnvReferences option, and the CLI config schema turns it on. Each affected field becomes an anyOf of its original type and an env() string, with description, default and examples kept on the outer node so hover docs look the same
  • String lists such as auth.additional_redirect_urls accept an env() 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 those
  • Fields that are already a union (e.g. storage.file_size_limit) get one extra env() branch rather than a nested one
  • project-config.schema.json doesn't change, since it describes values after env() has been resolved
  • apps/docs/public/cli/config.schema.json is regenerated
  • ajv is added as a dev dependency of @supabase/config so tests can check the published schema against what the loader accepts

Schema shape change

If you generate types or other tooling from config.schema.json, the affected fields now read as a union: their type moves from the field itself into the first anyOf branch, next to the env() branch. Configs that validated before still validate.

Linked issue

Closes CLI-2857

…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
@Coly010
Coly010 requested review from a team and supabase-oss as code owners October 26, 2026 15:32
@Coly010 Coly010 self-assigned this Oct 26, 2026

@github-actions github-actions Bot left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
@Coly010 Coly010 changed the title feat(config): accept env() references on number, boolean and enum fields in the config schema feat(config): accept env() on number, boolean, enum and list fields in the config schema Oct 26, 2026
@avallete
avallete self-requested a review October 27, 2026 08:20
@avallete

Copy link
Copy Markdown
Member

/ai-review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 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 avallete left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.json is a list of enum values today, so the rule that rejects env() there is only covered by the unit test. It's worth keeping that test when such a field is added.
  • The PR moves type into anyOf on these fields. That's a visible change for anyone generating types from config.schema.json, so it may deserve a line in the release notes.

@Coly010

Coly010 commented Oct 27, 2026

Copy link
Copy Markdown
Contributor Author

thanks for checking it against the real configs!

  1. yep, the list-of-enums test stays as the guard until a field like that turns up
  2. good shout - the release notes generator reads PR bodies, so i've reworded the "Schema shape change" section to speak to anyone generating types from config.schema.json

@Coly010
Coly010 added this pull request to the merge queue Oct 27, 2026
Merged via the queue into develop with commit 3507dba Oct 27, 2026
56 checks passed
@Coly010
Coly010 deleted the columferry/cli-2857-accept-env-references-on-number-and-boolean-fields-in-the branch October 27, 2026 14:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants