fix(cli): print declarative-schema-written line in sync bootstrap (CLI-1980)

[Coly010]

What changed

On the db schema declarative sync bootstrap path (no declarative files present → the CLI offers to generate them), the TS handler generated, wrote, and catalog-warmed the declarative schema but never told the user where the files were written. Go's bootstrap delegates to declarative.Generate, which prints Declarative schema written to <dir> to stderr after the write and the catalog warm (apps/cli-go/internal/db/declarative/declarative.go:133→138-155→156, reached via cmd/db_schema_declarative.go:389→366).

The sync bootstrap now emits that line:

• after legacyWriteDeclarativeSchemas and the catalog warm, matching Go's ordering;
• on both the interactive-accept and --yes/SUPABASE_YES paths (Go prints it in both);
• regardless of --no-cache (Go's print sits outside the if !noCache warm gate — the warm is skipped, the line is not);
• printing the relative dir, exactly what Go's utils.GetDeclarativeDir() returns (the declarative_schema_path config value — already supabase/-prefixed when relative — or the supabase/database default). Go chdirs into the workdir, so it never prints a resolved absolute path. This follows the convention being applied to db pull's identical line in fix(cli): print Connecting line and relative paths in db pull output (CLI-1978) #5968 (CLI-1978).

Integration coverage: exact line text + stderr stream + single emission, ordering (after the declarative catalog warm, before the diff's exports) via export-call tracking in the existing seam mock, plus --yes and --no-cache scenarios. SIDE_EFFECTS.md documents the new stderr line.

Review findings deliberately left open (out of scope for CLI-1980)

• generate (and pre-fix(cli): print Connecting line and relative paths in db pull output (CLI-1978) #5968 pull) still print the absolute dir for their ports of this same Go line (generate/generate.handler.ts:275, pull/pull.handler.ts:377). That is a separate pre-existing parity divergence: this PR's relative rendering is the Go-faithful one. pull's is being fixed in fix(cli): print Connecting line and relative paths in db pull output (CLI-1978) #5968; generate needs the same one-line declarativeDirRel treatment as a follow-up. Once all three converge, the emission is a candidate for a hoisted shared helper per the repo's hoist-before-you-duplicate rule.
• Zero-files-generated edge: Go prints the written-to line before runDeclarativeSync's "did generation produce files?" check, so a pathological zero-file generation still prints the line before erroring. The TS handler keeps its pre-existing files-check-before-warm ordering, so that failure path errors without the line. Left as-is to avoid reordering pre-existing bootstrap verification in this PR.

Fixes CLI-1980
https://linear.app/supabase/issue/CLI-1980/db-schema-declarative-sync-bootstrap-omits-the-declarative-schema

[Coly010]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep them coming!

Reviewed commit: 37ff443fa6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Supabase CLI preview

npx --yes https://pkg.pr.new/supabase/cli/supabase@37ff443fa6eb249c40ec401df4d287ab3d86591a

Preview package for commit 37ff443.

[kanadgupta]

Small DRY suggestion that Claude suggested (and I verified) otherwise LGTM

CLI-1980 is fixed correctly: the sync bootstrap now prints Declarative schema written to <bold dir> to stderr after the write and the catalog warm, outside the --no-cache gate, on both the interactive-accept and --yes paths — matching Go's declarative.Generate (declarative.go:133→138-155→156) exactly, including the relative GetDeclarativeDir() rendering (the TS toml reader mirrors Go's supabase/-prefixing at config.go:982-984). The diff is proportionate — the ~105 test lines pin the exact text/stream/ordering and would fail without the fix; all 30 sync integration tests pass locally. One non-blocking inline suggestion: this adds a third literal copy of the parity-critical message string (generate and pull have the others), and a one-line shared formatter in the already-shared legacy-pgdelta.write.ts is separable from the deferred rel/abs convergence. The PR body's disclosed zero-files-generated ordering divergence is a reasonable out-of-scope call.

[kanadgupta]

DRY (non-blocking): this is now the third literal copy of the Declarative schema written to line (generate/generate.handler.ts:275, pull/pull.handler.ts:377). Go avoids the duplication structurally — sync's bootstrap delegates to the shared declarative.Generate, so the string lives in one place per path (declarative.go:156, pull.go:119).

The PR body's rationale for deferring a hoist (the three call sites don't yet print the same rendering) applies to unifying which dir is printed, but the format helper is separable from that convergence: a one-liner in legacy-pgdelta.write.ts (which all three handlers already import) would pin the parity-critical string in one place today, with each caller passing its current dir —

export const legacyDeclarativeSchemaWrittenLine = (dir: string) =>
  `Declarative schema written to ${legacyBold(dir)}\n`;

— and would turn the CLI-1978 pull fix and the generate follow-up into one-argument changes. Fine to batch with the generate follow-up if you prefer, but worth doing before a fourth copy appears.