perf: hoist v3/v4/v5 schema migrations to load-time - #198
Merged
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 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 |
Removes the per-parse schema migration overhead from every documentSchema.parse(...) call. The pre-hoist schema was wrapped in a z.preprocess that ran upgradeV3DocumentToV4 + upgradeV4DocumentToV5 on every parse, including in-memory parses of v5 docs. - documentSchema is now a pure v5 validator; the z.preprocess wrapper is removed and both upgraders are exported - New migrateRawDocumentToCurrent helper in document/migrate.ts composes the two upgraders into the load-time equivalent of the old chain - DocumentService.getProject / listProjects wired to run the helper before parse - browserShim get callback and localStorage-load IIFE wired; new shim docs written as v5 directly - NewEditorShell.handleBrowseProject and EditorEmptyState.openLoadedProject (renderer disk-load paths) wired to run the helper before parse - migrateProjectDataToAxcutDocument updated to call the new helper so the v2 -> v3 -> v4 -> v5 chain still lives in one place - Existing schema tests updated to model the new contract - New tests for migrateRawDocumentToCurrent (v3/v4/v5/non-doc/v2) - Test fixtures (projectStore, useTimeline, EditorEmptyState) bumped to v5 to model the new bridge contract (load sites now return v5) - technical-documentation/architecture/document-model.md updated Every render-side setDocument / saveDocument / loadProject is now a single z.literal(5) + shape check on already-v5 data, instead of a function call into each upgrader + the parse. Note for #195: that PR adds a v5->v6 upgrader to the same z.preprocess chain this PR removes. Either land this PR first and rebase #195 on top, or combine them — the only conflict point is the z.preprocess line.
EtienneLescot
force-pushed
the
ponytail/hoist-schema-migrations
branch
from
July 29, 2026 09:16
0b630d3 to
2239d35
Compare
The Electron main bundle is built by vite-plugin-electron with configFile: false, so the root resolve.alias never applies to it. Importing the composer from document/migrate.ts dragged that module's @/-aliased value import (PROJECT_VERSION) into main and broke the build. Move migrateRawDocumentToCurrent into schema/index.ts (alias-free), re-export it from migrate.ts for existing callers, and stop hardcoding schemaVersion in the browser shim so it tracks axcutSchemaVersion across bumps.
EtienneLescot
force-pushed
the
ponytail/hoist-schema-migrations
branch
from
July 29, 2026 09:22
2239d35 to
cf9566a
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.
perf: hoist v3/v4/v5 schema migrations to load-time
Removes the per-parse schema migration overhead from every
documentSchema.parse(...)call.What changed
The pre-hoist
documentSchemawas wrapped in az.preprocessthat ranupgradeV3DocumentToV4+upgradeV4DocumentToV5on every parse — including in-memory parses of documents that were already v5. Both upgraders are guarded byif (doc.schemaVersion !== 3|4) return raw;, so they were fast no-ops for v5 inputs but still a function call per parse. Multiplied across everysetDocument/saveDocument/loadProjectround-trip, that's a measurable per-parse overhead.The fix hoists the migration to load time:
documentSchemais now a pure v5 validator — thez.preprocesswrapper is removed and the upgraders (upgradeV3DocumentToV4,upgradeV4DocumentToV5) are now exported.migrateRawDocumentToCurrenthelper insrc/lib/ai-edition/document/migrate.ts— composes the two upgraders into the load-time equivalent of the old chain. Modeled after the existingmigrateProjectDataToAxcutDocument(v2 → v3).documentSchema.parse:electron/ai-edition/document-service.ts—getProjectandlistProjectsJSON-read paths.src/native/browserShim.ts—getcallback and the localStorage-load IIFE (the shim persists documents to localStorage in browser-mode preview, and new shim documents are now written as v5 directly so the renderer's pure-v5parseDocumentaccepts them on the first read).documentSchema.parse:src/components/ai-edition/NewEditorShell.tsx—handleBrowseProject(loads a.openscreenfile viawindow.electronAPI.loadProjectFile).src/components/ai-edition/EditorEmptyState.tsx—openLoadedProject(same path).migrateProjectDataToAxcutDocumentupdated to call the new helper before the v5-validatingdocumentSchema.parse, so the v2 → v3 → v4 → v5 chain still lives in one place.projectStore.test.ts,useTimeline.test.ts, andEditorEmptyState.test.tsxuse a v3sampleDocto model the bridge response. After the hoist the bridge contract is v5 (every load site runs the helper), so the fixtures now useschemaVersion: 5.migrateRawDocumentToCurrentinmigrate.test.ts:documentSchema.parsewith no errordocument-model.mddescribes the load-time chain and the new contract.Why this matters
Every render-side
setDocument/saveDocument/loadProjectis now a singlez.literal(5)+ shape check on already-v5 data, instead of a function call into each of the two upgraders + the parse. The upgraders only run on the first read of a v3/v4 document from disk (or localStorage), which is the only time the work is needed.Files changed
Gates
npx tsc --noEmit— clean (exit 0)npm run test— 1150/1150 (1144 baseline + 6 new tests formigrateRawDocumentToCurrent)npm run lint— no new warnings (7 pre-existing warnings, all in files unrelated to this PR)Interaction with #195
PR #195 (in flight on
ponytail/drop-legacy-aspect-and-annotation) adds a v5→v6 upgrader to the samez.preprocesschain. This PR removes that chain, so #195's upgrader needs to be hoisted to load-time too. Two options:migrateRawDocumentToCurrentpattern and adds the v5→v6 step at the end of the chain.z.preprocessline; trivial to resolve.Either works. The conflict is mechanical, not architectural.
Labels