Migrate from a custom canvas

This guide assumes you are replacing local graph code, not greenfield. Follow the canonical SvelteKit integration page first, then use the checklist below.

Checklist

1. Add npm dependencies and ssr.noExternal entries (see integration guide).
2. Swap imports: local canvas / detail / semantic style helpers → @restormel/ui-graph-svelte.
3. Swap types and layout/trace/workspace → @restormel/graph-core subpaths or barrel.
4. Ensure global CSS satisfies the variable contract; add styles.css from the UI package if needed.
5. Remove duplicate components and stale viewModel copies from the repo—single source of truth is npm.
6. Run pnpm run check, targeted tests, and a manual smoke route if you have one.

Decision hints

• Compare / lineage / projection / evaluation? Prefer the published @restormel/graph-reasoning-extensions package (plus @restormel/contracts) and map results into GraphData — do not fork Contract v0 DTOs. Add internal packages only for org-specific logic on top.
• Monorepo pattern: npm canvas + contracts-backed extensions + one adapter that converts snapshots into GraphData. See Performance & scale if you need to cap graph size.
• Already deleted legacy graph code? Focus on adapter correctness and CSS parity; run the verification commands from the integration page.

Performance

Large graphs: pre-filter or cluster in your adapter before calling computeLayout / GraphCanvas. Details: Performance & scale.

Risk callouts

• Duplicate package names: a monorepo workspace package named @restormel/graph-core vs npm can confuse resolution—prefer a single source (npm or explicit tarball overrides).
• Lockfile pins: ensure ui-graph-svelte and graph-core resolve the same version.
• Registry lag: immediately after graph-v* publishes, npm view can be stale briefly.

Maintainer detail: restormel-graph-sophia-consumer.md.