個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證Diffs two SQL setups' query results on isolated in-memory Postgres instances (via PGlite) -- catches migration regressions before they touch a real database.
翻譯準備中
取自儲存庫 README
正在載入完整 README。 以下為已儲存的摘錄。
Runs the same query probes against two SQL setups (e.g. two versions of a migration) on isolated in-memory Postgres instances and reports exactly what differs — catches migration regressions before they touch a real database.檢視完整 README ↗Runs the same query probes against two SQL setups (e.g. two versions of a migration) on isolated in-memory Postgres instances and reports exactly what differs — catches migration regressions before they touch a real database.
PGlite — real PostgreSQL compiled to WASM, no Docker, no external service — has made "spin up a real Postgres in a test" fast enough to do per-test rather than per-CI-run. The pattern of using it to validate a single migration against seed data is already common. What's missing is the comparative version: when you refactor a migration history (squash old migrations, rewrite one for performance, reorder them), the risky question isn't "does the new migration run," it's "does it produce exactly the same query-visible results as what it replaced?" The existing open-source Postgres migration tools (Flyway, Liquibase, Atlas, Sqitch, pgroll, graphile-migrate, pgschema) all handle applying migrations; none of them diff two migration paths' resulting data against each other.
import { diffScenarios } from "pglite-diff";
const report = await diffScenarios(
{ setup: originalMigrationSql },
{ setup: refactoredMigrationSql },
[
{ name: "subscription pricing", sql: "select plan, monthly_price, annual_price from subscriptions order by id" },
{ name: "active users", sql: "select id, email from users where active order by id" },
]
);
if (!report.ok) {
console.error(JSON.stringify(report, null, 2));
process.exit(1);
}
Each scenario's setup SQL (schema + migrations + seed data, however you assemble it) runs against its own isolated in-memory PGlite instance. Every probe query then runs against both, and results are compared row-by-row, column-by-column. The report tells you exactly which probe found a difference, which row, which columns changed, and the before/after values — or, if a probe query itself fails on one side (e.g. a renamed column), that's reported distinctly rather than silently swallowed.
Overall: REGRESSION DETECTED
Probe "subscription pricing": MISMATCH
row 0: changed columns [annual_price]
before: {"plan":"starter","monthly_price":"10","annual_price":"96.0"}
after: {"plan":"starter","monthly_price":"10","annual_price":"108.0"}
- uses: jayblast-spec/pglite-diff@main
with:
config: ./pglite-diff.config.mjs
Or directly:
npx pglite-diff ./pglite-diff.config.mjs
Where the config file default-exports { before, after, probes }:
// pglite-diff.config.mjs
export default {
before: { setup: `/* schema + migrations + seed data, as they are today */` },
after: { setup: `/* schema + migrations + seed data, after your change */` },
probes: [
{ name: "pricing", sql: "select plan, annual_price from subscriptions order by id" },
],
};
npm install --save-dev pglite-diff @electric-sql/pglite
ORDER BY has no guaranteed row order in Postgres — write your probes with ORDER BY for deterministic, meaningful diffs. This is a deliberate simplicity choice, not an oversight: set-based comparison would hide genuinely meaningful ordering regressions (e.g. a broken ORDER BY clause) behind a false "no diff."before/after) failed to even build, so a broken migration doesn't get misreported as "every probe found a difference."npx tsx examples/demo.ts
information_schema — two schemas that produce identical query results for your probes are treated as equivalent, which is usually what you actually care about.npm install
npm run typecheck
npm test
npm run build
MIT
This is one of 8 independent open-source infrastructure tools, each built against a real, researched gap:
Built by ArkNet Digital.