feat: check that migrations are ordered - #30
Merged
Conversation
Migrations apply in filename order, which matches the order their numbers imply only while the prefixes are padded to the same width. Opt-in via `--check-migration-order`, or `checkMigrationOrder` in the config.
Equal-width prefixes sort the same way in any positional scheme, so width is the invariant that makes filename order the intended order — a letter or timestamp convention holds on its own terms. `checkMigrationOrder` now also takes a RegExp saying where the prefix ends.
`checkMigrationOrder: { enabled, prefixPattern }` replaces the
boolean-or-RegExp union, and core merges the CLI flag over the config
instead of replacing it, so `--check-migration-order` turns the check on
without discarding a configured prefixPattern.
No default: only the project knows which convention its filenames were named for, and a wrong guess passes a check that never looked at the right prefix. `--check-migration-order` contributes only `enabled`, so the pattern has to come from the config.
With prefixPattern required, naming a pattern is already the opt-in. The CLI flag takes the pattern as its value, so it no longer needs merging over the config — it overrides it like every other option.
One paragraph, one example. Drops the duplicate from the config block, which is about shaping the introspection DB.
ilbertt
force-pushed
the
claude/migration-ordering-flag-70b751
branch
from
September 1, 2026 12:46
3bab5d3 to
afb66ba
Compare
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
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.
Migrations apply in filename order, and that is the order you meant only while every filename carries a sequence prefix of the same width —
1, 2, 10applies as1, 10, 2, silently building a schema production never had.Naming a prefix pattern is what turns the check on — in the config, or as the flag's value:
There's no default pattern: only the project knows which convention its filenames were named for, and a wrong guess passes a check that never looked at the right prefix.
Width, not "is it a number", is what's checked: equal-width prefixes sort the same way in any positional scheme, so a scheme that doesn't number at all is held to its own terms (
/^[a-z]{4}_/,/^\d{14}_/). It fails on a migration with no prefix, on two claiming the same prefix (0035twice), and on prefixes of differing widths. Gaps are fine.Deliberately not folded into
--check: unlike the other checks it guards generation itself rather than the output, so it runs in every mode — and folding it in would break CI for projects with unprefixed migrations that work fine today.