fix(cli): match Go path.Match character-class negation in legacy seed globbing#5856
Merged
Coly010 merged 2 commits intoJul 10, 2026
Conversation
… globbing (CLI-1880) legacyMatchPattern (apps/cli/src/legacy/commands/db/shared/legacy-seed-ops.ts) treated a leading `!` inside a `[...]` class the same as `^` (shell/fnmatch negation), but Go's path.Match grammar only negates on `^` -- `!` is an ordinary literal class member. A [db.seed].sql_paths entry like `[!a].sql` therefore matched `b.sql` in TS where the Go CLI would not, letting `db push --include-seed` / remote reset apply files outside the Go-compatible seed set. apps/cli/src/legacy/shared/legacy-path-match.ts already ports Go's path.Match byte-for-byte (correct ^-only negation, escapes, malformed- pattern detection) for the sibling db-new/migration seed pipeline. Delete the duplicate, buggy matcher and rewire both legacyMatchPattern callers (db/shared/legacy-seed-ops.ts's seed glob, db/reset/reset.handler.ts's --version glob) onto the shared, already-tested legacyPathMatch instead of patching the copy in place.
…CLI-1880 follow-up) legacyGlobSeedFiles discarded legacyPathMatch's badPattern signal, so a malformed [db.seed].sql_paths entry (e.g. an unterminated `[` class) fell through to the generic "no files matched pattern" warning instead of Go's "failed to glob files: syntax error in pattern" (fs.Glob's up-front Match(pattern, "") validation). The sibling seed pipeline (legacy-seed.ts:resolveSeedFiles) already handled this; mirror it here now that both pipelines share legacyPathMatch. Flagged independently by all four review-changes reviewers as a same-scope, cheap parity win.
Contributor
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. Another round soon, please! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
Contributor
Supabase CLI previewnpx --yes https://pkg.pr.new/supabase/cli/supabase@5ca135233e46d1b00c07af2098cf1df83ff0bfd0Preview package for commit |
avallete
approved these changes
Jul 10, 2026
Coly010
deleted the
columferry/cli-1880-legacymatchpattern-match-go-pathmatch-character-class
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Current Behavior
legacyMatchPattern(the glob matcher backing[db.seed].sql_pathsanddb reset --version) treated a leading!inside a[...]bracket class the same as^— shell/fnmatch-style negation. Go'spath.Match(whichapps/cli-go'sfs.Glob/afero.Globactually use for this) only negates on^;!is an ordinary literal class member. So a pattern like[!a].sqlmatchedb.sqlin the TS port where the Go CLI would not, meaningdb push --include-seed/db resetcould read, hash, and execute seed SQL outside the set the user's Go-compatible config intended.Verified directly against the real Go stdlib source (
$GOROOT/src/path/match.go) available on this machine, and againstapps/cli-go/pkg/config/config.go(fs.Glob) andapps/cli-go/internal/migration/repair/repair.go(GetMigrationFile/afero.Glob) — both go through the samepath.Matchgrammar.New Behavior
Rather than patching the bug in place, this fixes it by deleting the duplicate:
apps/cli/src/legacy/shared/legacy-path-match.ts(legacyPathMatch) is already a byte-faithful, already-tested port of Go'spath.Match— introduced earlier for the siblingdb new/migration seed pipeline (legacy-seed.ts) — with correct^-only negation, escapes, and malformed-pattern (ErrBadPattern) detection.legacyMatchPatternand itsmatchClass/matchhelpers are removed, and both call sites are rewired ontolegacyPathMatch:legacy-seed-ops.ts's own seed glob (globOne)reset.handler.ts's--versionmigration-file glob (behavior-identical here —vis validated as digits-only before the glob ever runs, so no bracket syntax is reachable on this path)A follow-up commit closes a related gap all four
review-changesreviewers independently flagged:legacyGlobSeedFileswas discardinglegacyPathMatch'sbadPatternsignal, so a malformed pattern (e.g. an unterminated[class) fell through to the genericno files matched patternwarning instead of Go'sfailed to glob files: syntax error in pattern(fs.Glob's up-frontMatch(pattern, "")validation). The sibling pipeline (legacy-seed.ts:resolveSeedFiles) already did this correctly — mirrored it here now that both pipelines sharelegacyPathMatch.Behavior change worth calling out for release notes: any existing
[db.seed].sql_pathsconfig relying on[!x]as shell-style negation will now select a different (Go-correct) set of seed files with no error — e.g.[!0-9]now means "the literal characters!,0-9", not "not a digit". Use[^x]for negation, matching Go/the real Go CLI. This is a correctness fix (the legacy shell's contract is strict Go parity), but it is a silent behavior change for anyone who had unknowingly depended on the old, non-Go-compatible negation.Related Issue(s)
Fixes https://linear.app/supabase/issue/CLI-1880
Notes for reviewers
review-changes(architect/engineer/security/DX, run against the first commit) all returned APPROVE/SHIP IT. Judgement calls deliberately left open rather than expanded into this PR:legacy-seed-ops.tsandlegacy-seed.ts) still duplicate the outerfs.Glob-style directory-walk/dedup logic (both now delegate the leaf matcher tolegacyPathMatch, but the surrounding glob-resolution code is still two separate ports). Flagged by the architect reviewer as a good candidate for a follow-up consolidation, out of scope for this fix.sql_paths' glob dialect (Gopath.Matchsemantics,^-only negation, no POSIX classes) isn't documented anywhere user-facing (packages/config/src/db.ts). Flagged by the DX reviewer as worth a docs follow-up, not blocking.