refactor(migration-tools): dag → migration-graph, MigrationChainEntry → MigrationEdge#383
Merged
Conversation
Contributor
📝 WalkthroughWalkthroughThis PR refactors the migration graph module by renaming Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
@prisma-next/mongo-runtime
@prisma-next/family-mongo
@prisma-next/sql-runtime
@prisma-next/family-sql
@prisma-next/middleware-telemetry
@prisma-next/mongo
@prisma-next/extension-paradedb
@prisma-next/extension-pgvector
@prisma-next/postgres
@prisma-next/sql-orm-client
@prisma-next/sqlite
@prisma-next/target-mongo
@prisma-next/adapter-mongo
@prisma-next/driver-mongo
@prisma-next/contract
@prisma-next/utils
@prisma-next/config
@prisma-next/errors
@prisma-next/framework-components
@prisma-next/operations
@prisma-next/ts-render
@prisma-next/contract-authoring
@prisma-next/ids
@prisma-next/psl-parser
@prisma-next/psl-printer
@prisma-next/cli
@prisma-next/emitter
@prisma-next/migration-tools
prisma-next
@prisma-next/vite-plugin-contract-emit
@prisma-next/mongo-codec
@prisma-next/mongo-contract
@prisma-next/mongo-value
@prisma-next/mongo-contract-psl
@prisma-next/mongo-contract-ts
@prisma-next/mongo-emitter
@prisma-next/mongo-schema-ir
@prisma-next/mongo-query-ast
@prisma-next/mongo-orm
@prisma-next/mongo-query-builder
@prisma-next/mongo-lowering
@prisma-next/mongo-wire
@prisma-next/sql-contract
@prisma-next/sql-errors
@prisma-next/sql-operations
@prisma-next/sql-schema-ir
@prisma-next/sql-contract-psl
@prisma-next/sql-contract-ts
@prisma-next/sql-contract-emitter
@prisma-next/sql-lane-query-builder
@prisma-next/sql-relational-core
@prisma-next/sql-builder
@prisma-next/target-postgres
@prisma-next/target-sqlite
@prisma-next/adapter-postgres
@prisma-next/adapter-sqlite
@prisma-next/driver-postgres
@prisma-next/driver-sqlite
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
docs/planning/benchmarks/migration-graph-baseline.md (1)
168-178: Residual "dag" terminology in the rendering-pipeline section.After the module rename, the table caption ("Relies on") and the prose still describe the underlying layer as "dag layer" / "dag-shaped loop" / "dag ops". For consistency with the rest of the document (and the renamed
graph.tssource it points at), consider replacing these with "graph layer" / "graph-shaped loop" / "graph ops". Same applies to the file path mentiongraph-render.tsalready being correct — only the surrounding labels are stale.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/planning/benchmarks/migration-graph-baseline.md` around lines 168 - 178, Update all remaining "dag" terminology in the rendering-pipeline section to "graph" for consistency: change table cells "dag layer" → "graph layer" and "dag-shaped loop" → "graph-shaped loop", and update prose references like "dag ops" to "graph ops"; ensure occurrences near the functions/methods migrationGraphToRenderInput, extractRelevantSubgraph, truncateGraph and in the paragraph mentioning graph-render.ts are replaced accordingly. Search the block for any other "dag" tokens and rename them to "graph" so labels/captions and surrounding text match the renamed graph.ts source.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/planning/benchmarks/migration-graph-baseline.md`:
- Line 7: The docs refer to the old export path
`@prisma-next/migration-tools/dag` which no longer exists; update the "Scope"
paragraph in migration-graph-baseline.md to reference the current export path
(`@prisma-next/migration-tools/graph` or the package's `./graph` export) and
adjust any mention of the `MigrationGraph` data structure accordingly; also
replace or add a canonical link to the package README or package.json export
section to avoid future drift (look for mentions of MigrationGraph and the
string "dag" in migration-graph-baseline.md to locate the text to change).
---
Nitpick comments:
In `@docs/planning/benchmarks/migration-graph-baseline.md`:
- Around line 168-178: Update all remaining "dag" terminology in the
rendering-pipeline section to "graph" for consistency: change table cells "dag
layer" → "graph layer" and "dag-shaped loop" → "graph-shaped loop", and update
prose references like "dag ops" to "graph ops"; ensure occurrences near the
functions/methods migrationGraphToRenderInput, extractRelevantSubgraph,
truncateGraph and in the paragraph mentioning graph-render.ts are replaced
accordingly. Search the block for any other "dag" tokens and rename them to
"graph" so labels/captions and surrounding text match the renamed graph.ts
source.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: 53f80e8b-bf1e-4a5d-8169-b2aff33e5e19
📒 Files selected for processing (22)
docs/planning/benchmarks/migration-graph-baseline.mdpackages/1-framework/3-tooling/cli/src/commands/migration-apply.tspackages/1-framework/3-tooling/cli/src/commands/migration-new.tspackages/1-framework/3-tooling/cli/src/commands/migration-plan.tspackages/1-framework/3-tooling/cli/src/commands/migration-show.tspackages/1-framework/3-tooling/cli/src/commands/migration-status.tspackages/1-framework/3-tooling/cli/src/utils/command-helpers.tspackages/1-framework/3-tooling/cli/src/utils/formatters/graph-migration-mapper.tspackages/1-framework/3-tooling/cli/test/commands/migration-apply.test.tspackages/1-framework/3-tooling/cli/test/commands/migration-e2e.test.tspackages/1-framework/3-tooling/cli/test/commands/migration-plan-command.test.tspackages/1-framework/3-tooling/cli/test/commands/migration-plan.test.tspackages/1-framework/3-tooling/cli/test/commands/migration-ref.test.tspackages/1-framework/3-tooling/cli/test/utils/graph-helpers.tspackages/1-framework/3-tooling/migration/README.mdpackages/1-framework/3-tooling/migration/package.jsonpackages/1-framework/3-tooling/migration/src/exports/graph.tspackages/1-framework/3-tooling/migration/src/exports/types.tspackages/1-framework/3-tooling/migration/src/graph.tspackages/1-framework/3-tooling/migration/src/types.tspackages/1-framework/3-tooling/migration/test/graph.test.tspackages/1-framework/3-tooling/migration/tsdown.config.ts
saevarb
force-pushed
the
tml-2297-prereqs
branch
2 times, most recently
from
c42f69e to
dfa911e
Compare
The file holds the high-level migration-graph operations (`reconstructGraph`, `findPath`, `findLeaf`, `findLatestMigration`, `findReachableLeaves`, `detectCycles`, `detectOrphans`). "DAG" is a misnomer — the module detects cycles, doesn't forbid them. Now that the previous reshape (44d73c6, e71f9fa) split out the types into `graph.ts` and the generic BFS primitive into `graph-ops.ts`, this file has one clear job; rename to match. The new name pairs with the existing structure: * `graph.ts` → migration-graph types * `graph-ops.ts` → generic BFS primitive * `migration-graph.ts` → migration-graph operations Mechanical rename: * `git mv src/dag.ts → src/migration-graph.ts` * `git mv src/exports/dag.ts → src/exports/migration-graph.ts` * `git mv test/dag.test.ts → test/migration-graph.test.ts` * Public subpath: `./dag` → `./migration-graph` in package.json exports + tsdown.config entry * README subpath table + module-graph diagram * All in-workspace consumers updated to import from `@prisma-next/migration-tools/migration-graph` No behavioural change; tests + typecheck green.
The type is used exclusively as a graph edge: it has `from` / `to` endpoints, lives in neighbour-indexed maps (`forwardChain`, `reverseChain`, `migrationByHash`), is returned as edge lists from `findPath` / `detectOrphans`, and every local variable holding one is already named `edge` / `edges` / `incomingEdge`. `MigrationEdge` matches the implementation vocabulary; `ChainEntry` is legacy from the pre-graph linear-chain era and actively misleads readers. Type-only change. No runtime impact. * Type declaration in `src/graph.ts` * Re-export name in `src/exports/graph.ts` and the README subpath table * Every call site updated (CLI src + tests + fixture helpers + README) * In-tree spec/plan docs that mention the type also updated
saevarb
force-pushed
the
tml-2297-prereqs
branch
from
dfa911e to
9719418
Compare
saevarb
changed the title
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/1-framework/3-tooling/migration/src/migration-graph.ts (1)
24-24: Rename residualentrywording toedgefor consistency.After the type rename, these identifiers/comments still use old terminology and can cause minor confusion during maintenance.
♻️ Suggested cleanup
-function appendEdge(map: Map<string, MigrationEdge[]>, key: string, entry: MigrationEdge): void { +function appendEdge(map: Map<string, MigrationEdge[]>, key: string, edge: MigrationEdge): void { const bucket = map.get(key); - if (bucket) bucket.push(entry); - else map.set(key, [entry]); + if (bucket) bucket.push(edge); + else map.set(key, [edge]); }- * Find the latest migration entry by traversing from EMPTY_CONTRACT_HASH + * Find the latest migration edge by traversing from EMPTY_CONTRACT_HASHAs per coding guidelines: "
**/*.{md,ts,tsx}: Keep docs current (READMEs, rules, links) and prefer links to canonical docs over long comments."Also applies to: 315-316
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/3-tooling/migration/src/migration-graph.ts` at line 24, The identifier "entry" is a leftover from an old type name and should be renamed to "edge" for clarity; update the appendEdge function signature (appendEdge(map: Map<string, MigrationEdge[]>, key: string, entry: MigrationEdge) -> use "edge" instead of "entry"), change all internal references inside appendEdge from entry to edge, and similarly rename any other residual identifiers/comments referring to "entry" (notably the other occurrences around the MigrationEdge handling) to "edge" to keep naming consistent with the MigrationEdge type.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/1-framework/3-tooling/cli/src/commands/migration-status.ts`:
- Line 159: The current edgeKey in deriveEdgeStatuses (`const edgeKey = (e:
MigrationEdge) => `${e.from}\0${e.to}``) only uses from/to and will collide when
two distinct MigrationEdge instances share endpoints; change the key to include
a unique identifier for the MigrationEdge (for example add or use an existing
field like e.id, e.migrationId or e.name) so the key becomes something like
`${e.from}\0${e.to}\0${e.id ?? e.migrationId ?? e.name}`; update the
MigrationEdge type if necessary to expose a stable unique id and use that
property in edgeKey and any lookups to ensure edges are disambiguated.
---
Nitpick comments:
In `@packages/1-framework/3-tooling/migration/src/migration-graph.ts`:
- Line 24: The identifier "entry" is a leftover from an old type name and should
be renamed to "edge" for clarity; update the appendEdge function signature
(appendEdge(map: Map<string, MigrationEdge[]>, key: string, entry:
MigrationEdge) -> use "edge" instead of "entry"), change all internal references
inside appendEdge from entry to edge, and similarly rename any other residual
identifiers/comments referring to "entry" (notably the other occurrences around
the MigrationEdge handling) to "edge" to keep naming consistent with the
MigrationEdge type.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: 184260aa-b131-499a-8ae8-d81a94db0c74
📒 Files selected for processing (21)
packages/1-framework/3-tooling/cli/src/commands/migration-apply.tspackages/1-framework/3-tooling/cli/src/commands/migration-new.tspackages/1-framework/3-tooling/cli/src/commands/migration-plan.tspackages/1-framework/3-tooling/cli/src/commands/migration-show.tspackages/1-framework/3-tooling/cli/src/commands/migration-status.tspackages/1-framework/3-tooling/cli/src/utils/command-helpers.tspackages/1-framework/3-tooling/cli/src/utils/formatters/graph-migration-mapper.tspackages/1-framework/3-tooling/cli/test/commands/migration-apply.test.tspackages/1-framework/3-tooling/cli/test/commands/migration-e2e.test.tspackages/1-framework/3-tooling/cli/test/commands/migration-plan-command.test.tspackages/1-framework/3-tooling/cli/test/commands/migration-plan.test.tspackages/1-framework/3-tooling/cli/test/commands/migration-ref.test.tspackages/1-framework/3-tooling/cli/test/utils/graph-helpers.tspackages/1-framework/3-tooling/migration/README.mdpackages/1-framework/3-tooling/migration/package.jsonpackages/1-framework/3-tooling/migration/src/exports/graph.tspackages/1-framework/3-tooling/migration/src/exports/migration-graph.tspackages/1-framework/3-tooling/migration/src/graph.tspackages/1-framework/3-tooling/migration/src/migration-graph.tspackages/1-framework/3-tooling/migration/test/migration-graph.test.tspackages/1-framework/3-tooling/migration/tsdown.config.ts
✅ Files skipped from review due to trivial changes (10)
- packages/1-framework/3-tooling/cli/test/commands/migration-ref.test.ts
- packages/1-framework/3-tooling/cli/test/commands/migration-e2e.test.ts
- packages/1-framework/3-tooling/cli/test/commands/migration-apply.test.ts
- packages/1-framework/3-tooling/cli/src/commands/migration-show.ts
- packages/1-framework/3-tooling/cli/src/commands/migration-new.ts
- packages/1-framework/3-tooling/cli/src/utils/command-helpers.ts
- packages/1-framework/3-tooling/cli/test/commands/migration-plan.test.ts
- packages/1-framework/3-tooling/migration/src/exports/migration-graph.ts
- packages/1-framework/3-tooling/cli/test/utils/graph-helpers.ts
- packages/1-framework/3-tooling/migration/src/graph.ts
🚧 Files skipped from review as they are similar to previous changes (5)
- packages/1-framework/3-tooling/cli/src/commands/migration-plan.ts
- packages/1-framework/3-tooling/migration/src/exports/graph.ts
- packages/1-framework/3-tooling/cli/src/commands/migration-apply.ts
- packages/1-framework/3-tooling/migration/package.json
- packages/1-framework/3-tooling/migration/README.md
| if (mode === 'offline') return []; | ||
|
|
||
| const edgeKey = (e: MigrationChainEntry) => `${e.from}\0${e.to}`; | ||
| const edgeKey = (e: MigrationEdge) => `${e.from}\0${e.to}`; |
Contributor
There was a problem hiding this comment.
Disambiguate edge identity in deriveEdgeStatuses to avoid collisions.
Line 159 keys edges only by from/to. Distinct migrations with the same endpoints will collide, which can hide or misclassify statuses for one of those edges.
🐛 Proposed fix
- const edgeKey = (e: MigrationEdge) => `${e.from}\0${e.to}`;
+ const edgeKey = (e: MigrationEdge) => `${e.from}\0${e.to}\0${e.migrationHash}`;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/1-framework/3-tooling/cli/src/commands/migration-status.ts` at line
159, The current edgeKey in deriveEdgeStatuses (`const edgeKey = (e:
MigrationEdge) => `${e.from}\0${e.to}``) only uses from/to and will collide when
two distinct MigrationEdge instances share endpoints; change the key to include
a unique identifier for the MigrationEdge (for example add or use an existing
field like e.id, e.migrationId or e.name) so the key becomes something like
`${e.from}\0${e.to}\0${e.id ?? e.migrationId ?? e.name}`; update the
MigrationEdge type if necessary to expose a stable unique id and use that
property in edgeKey and any lookups to ensure edges are disambiguated.
wmadden
pushed a commit
that referenced
this pull request
May 4, 2026
… → MigrationEdge (#383) closes [TML-2326](https://linear.app/prisma-company/issue/TML-2326/rename-dagts-graphts-p2-of-tml-2297) closes [TML-2327](https://linear.app/prisma-company/issue/TML-2327/rename-migrationchainentry-migrationedge-p3-of-tml-2297) part of [TML-2297](https://linear.app/prisma-company/issue/TML-2297/pn-invariant-aware-routing) ## Intent Two mechanical renames in the migration-tools package to land before the invariant-aware-routing work (M1/M2/M3 of [TML-2297](https://linear.app/prisma-company/issue/TML-2297)). Both names are legacy from the pre-graph linear-chain era and now misdirect readers; renaming first keeps the upcoming routing diff focused on routing. - **`dag.ts` → `migration-graph.ts`** ([TML-2326](https://linear.app/prisma-company/issue/TML-2326)) — the file holds the high-level migration-graph operations (`reconstructGraph`, `findPath`, `findLeaf`, `findLatestMigration`, `findReachableLeaves`, `detectCycles`, `detectOrphans`). "DAG" is a misnomer — the module detects cycles rather than forbidding them. After main's earlier reshape (44d73c6, e71f9fa) split the types into `graph.ts` and the generic BFS primitive into `graph-ops.ts`, this file has one clear job. The new name slots in alongside its siblings: - `graph.ts` → migration-graph types (`MigrationGraph`, `MigrationEdge`) - `graph-ops.ts` → generic BFS primitive - `migration-graph.ts` → migration-graph operations (this rename) The rename runs end-to-end: internal source file, test file, public subpath (`@prisma-next/migration-tools/dag` → `…/migration-graph`), barrel file, `package.json` exports, `tsdown` entry, README, and every in-workspace consumer's import string. - **`MigrationChainEntry` → `MigrationEdge`** ([TML-2327](https://linear.app/prisma-company/issue/TML-2327)) — the type is used exclusively as a graph edge: `from` / `to` endpoints, lives in neighbour-indexed maps (`forwardChain`, `reverseChain`, `migrationByHash`), returned as edge lists from `findPath` / `detectOrphans`. Every local variable holding one is already named `edge` / `edges` / `incomingEdge`. `MigrationEdge` matches the implementation vocabulary. ## Change map - **Implementation (file/type renames)**: - [packages/1-framework/3-tooling/migration/src/migration-graph.ts (was dag.ts)](packages/1-framework/3-tooling/migration/src/migration-graph.ts) — migration-graph operations - [packages/1-framework/3-tooling/migration/src/exports/migration-graph.ts (was exports/dag.ts)](packages/1-framework/3-tooling/migration/src/exports/migration-graph.ts) — public-subpath barrel, re-exports from `../migration-graph` - [packages/1-framework/3-tooling/migration/src/graph.ts](packages/1-framework/3-tooling/migration/src/graph.ts) — `MigrationEdge` declaration (type lives in the existing types-only file, not the renamed operations file) - [packages/1-framework/3-tooling/migration/src/exports/graph.ts](packages/1-framework/3-tooling/migration/src/exports/graph.ts) — re-exported name follows the rename - **Implementation (package wiring)**: - [packages/1-framework/3-tooling/migration/package.json](packages/1-framework/3-tooling/migration/package.json) — `exports` map: `./dag` → `./migration-graph` - [packages/1-framework/3-tooling/migration/tsdown.config.ts](packages/1-framework/3-tooling/migration/tsdown.config.ts) — entry: `exports/dag` → `exports/migration-graph` - [packages/1-framework/3-tooling/migration/README.md](packages/1-framework/3-tooling/migration/README.md) — subpath table + module-graph diagram updated - **Implementation (consumers)**: - CLI commands and helpers under `packages/1-framework/3-tooling/cli/src/**` — every `from '@prisma-next/migration-tools/dag'` flipped to `…/migration-graph`, plus `MigrationEdge`-typed call sites - CLI test files under `packages/1-framework/3-tooling/cli/test/**` — same import-path updates, including `vi.mock('@prisma-next/migration-tools/migration-graph', …)` - **Tests (evidence)**: - [packages/1-framework/3-tooling/migration/test/migration-graph.test.ts (was dag.test.ts)](packages/1-framework/3-tooling/migration/test/migration-graph.test.ts) — same assertions under the new file name; no behavioural drift ## The story Two commits: 1. **Rename the file + subpath in one commit.** `git mv src/dag.ts src/migration-graph.ts`, plus `test/dag.test.ts` → `test/migration-graph.test.ts` and `src/exports/dag.ts` → `src/exports/migration-graph.ts`. `package.json` exports map flips `./dag` → `./migration-graph`; `tsdown.config.ts` entry follows; README subpath table + module-graph diagram updated; every in-workspace consumer's import string flipped from `@prisma-next/migration-tools/dag` to `…/migration-graph`. 2. **Rename the type.** `MigrationChainEntry` → `MigrationEdge` at the declaration in `src/graph.ts`; every call site (graph internals, CLI, tests, fixtures, in-tree spec/plan docs) updated to match. Type-only change, no runtime impact. ## Behavior changes & evidence **None.** Two mechanical commits. No control-flow change, no API addition, no removed functionality. - **Implementation**: see Change map above. - **Tests**: existing `dag.test.ts` (now `migration-graph.test.ts`) suite continues to pass under the new name; no test logic changed. CLI suite green (757/757). Migration-tools suite green (195/195). Typecheck clean. ## Compatibility / migration / risk - **Public subpath rename: `@prisma-next/migration-tools/dag` → `@prisma-next/migration-tools/migration-graph`.** Every in-workspace consumer is updated in this PR. The package isn't published, so no out-of-tree consumers exist; any in-progress branch that still imports from `…/dag` will need a one-line edit on rebase. - **`MigrationChainEntry` → `MigrationEdge`.** Same story — in-workspace rename, in-progress branches need a one-line edit on rebase. - **No behavioural risk.** Pure refactor; tests prove equivalence. ## Follow-ups / open questions - Prereq for [TML-2328](https://linear.app/prisma-company/issue/TML-2328) (M1 marker storage) and the upcoming M2 (`invariantId` authoring) and M3 (`findPathWithInvariants`) tickets — those PRs target the new names from the start. - ADRs and other markdown docs that still mention `dag.ts` / `MigrationChainEntry` will be cleaned up in a later sweep alongside the M3 spec finalization. ## Non-goals / intentionally out of scope - No invariant-aware routing behaviour. M3 ships separately under [TML-2297](https://linear.app/prisma-company/issue/TML-2297). - No marker-storage changes. M1 is [TML-2328](https://linear.app/prisma-company/issue/TML-2328), shipping in parallel. - No re-thinking of `findPath` / `findPathWithDecision` semantics. That's the routing-spec work, not these renames.
5 tasks
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.
closes TML-2326
closes TML-2327
part of TML-2297
Intent
Two mechanical renames in the migration-tools package to land before the invariant-aware-routing work (M1/M2/M3 of TML-2297). Both names are legacy from the pre-graph linear-chain era and now misdirect readers; renaming first keeps the upcoming routing diff focused on routing.
dag.ts→migration-graph.ts(TML-2326) — the file holds the high-level migration-graph operations (reconstructGraph,findPath,findLeaf,findLatestMigration,findReachableLeaves,detectCycles,detectOrphans). "DAG" is a misnomer — the module detects cycles rather than forbidding them. After main's earlier reshape (44d73c6, e71f9fa) split the types intograph.tsand the generic BFS primitive intograph-ops.ts, this file has one clear job. The new name slots in alongside its siblings:graph.ts→ migration-graph types (MigrationGraph,MigrationEdge)graph-ops.ts→ generic BFS primitivemigration-graph.ts→ migration-graph operations (this rename)The rename runs end-to-end: internal source file, test file, public subpath (
@prisma-next/migration-tools/dag→…/migration-graph), barrel file,package.jsonexports,tsdownentry, README, and every in-workspace consumer's import string.MigrationChainEntry→MigrationEdge(TML-2327) — the type is used exclusively as a graph edge:from/toendpoints, lives in neighbour-indexed maps (forwardChain,reverseChain,migrationByHash), returned as edge lists fromfindPath/detectOrphans. Every local variable holding one is already namededge/edges/incomingEdge.MigrationEdgematches the implementation vocabulary.Change map
../migration-graphMigrationEdgedeclaration (type lives in the existing types-only file, not the renamed operations file)exportsmap:./dag→./migration-graphexports/dag→exports/migration-graphpackages/1-framework/3-tooling/cli/src/**— everyfrom '@prisma-next/migration-tools/dag'flipped to…/migration-graph, plusMigrationEdge-typed call sitespackages/1-framework/3-tooling/cli/test/**— same import-path updates, includingvi.mock('@prisma-next/migration-tools/migration-graph', …)The story
Two commits:
git mv src/dag.ts src/migration-graph.ts, plustest/dag.test.ts→test/migration-graph.test.tsandsrc/exports/dag.ts→src/exports/migration-graph.ts.package.jsonexports map flips./dag→./migration-graph;tsdown.config.tsentry follows; README subpath table + module-graph diagram updated; every in-workspace consumer's import string flipped from@prisma-next/migration-tools/dagto…/migration-graph.MigrationChainEntry→MigrationEdgeat the declaration insrc/graph.ts; every call site (graph internals, CLI, tests, fixtures, in-tree spec/plan docs) updated to match. Type-only change, no runtime impact.Behavior changes & evidence
None. Two mechanical commits. No control-flow change, no API addition, no removed functionality.
dag.test.ts(nowmigration-graph.test.ts) suite continues to pass under the new name; no test logic changed. CLI suite green (757/757). Migration-tools suite green (195/195). Typecheck clean.Compatibility / migration / risk
@prisma-next/migration-tools/dag→@prisma-next/migration-tools/migration-graph. Every in-workspace consumer is updated in this PR. The package isn't published, so no out-of-tree consumers exist; any in-progress branch that still imports from…/dagwill need a one-line edit on rebase.MigrationChainEntry→MigrationEdge. Same story — in-workspace rename, in-progress branches need a one-line edit on rebase.Follow-ups / open questions
invariantIdauthoring) and M3 (findPathWithInvariants) tickets — those PRs target the new names from the start.dag.ts/MigrationChainEntrywill be cleaned up in a later sweep alongside the M3 spec finalization.Non-goals / intentionally out of scope
findPath/findPathWithDecisionsemantics. That's the routing-spec work, not these renames.