个人 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.