Add basic migration support to layout system

[franknoirot]

To support my work on #7564, I need a proper way to get users with persisted layout configs out there to migrate to new layout configurations. This provides a first pass at such a system.

How it works

1. A Map with keys of target versions and values with the outcome version and an array of migrations to apply is defined. Developers will add to this map over time, and likely remove earlier items after version are no longer seen in the wild.
2. A migration consists of a matcher function and an array of transformation functions. The matcher function is run on each layout node recursively, and if there is a match all transformations are applied in order, receiving the layout node (possibly transformed by earlier transformations) as input. The matcher function can also return true to match on all nodes.
3. As a part of the layout parsing step, a migration function is passed in which takes this migration map and applies the migrations in order, matching on version numbers until there are no more matches.
4. If any of this errors, we bail out to the latest default layout.
5. We save the layout during load to apply any transformations performed during it.

This PR introduces our first migration from v1 to v2. In it, we apply no transformations. Only the version number should increment. In the demo below I show a contrived example of adding a migration from v2 to v3.

Demo

Screenshare.-.2025-12-01.10_28_42.AM-compressed.mp4

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
modeling-app	Ready	Preview	Comment	Dec 3, 2025 0:22am

[pierremtb]

Alright dope, not a migration expert but this looks all sound! Thanks for the extensive testing too!

[pierremtb]

TIL

[franknoirot]

Haha I probably should have made it just a number but I goofed from the jump naming the first "v1" 🤦🏻

[franknoirot]

I guess it could just be a string. Who cares what the version string is

[andrewvarga]

I think it's really nice to try to keep user's layouts, to be honest at first I would have thought that especially if version changes are rare it's much easier to just live with the fact that users need to reconfigure their layouts every once in a while,

[franknoirot]

to be honest at first I would have thought that especially if version changes are rare it's much easier to just live with the fact that users need to reconfigure their layouts every once in a while,

Yeah @andrewvarga I expect these versions will slow down tremendously in the future. One of the issues that I want to solve with this is for cases like the Bodies pane (#7564), which will update the Feature Tree pane everyone is used to to be its own Split layout with the operations list up top and the new bodies list below. I don't have a way to ship that update to users without blowing away their layout today. So this little system makes it so we can write a migration that switches in the bodies pane, increment the version, and users will get it when they open the app without losing the other stuff they've configured. We haven't provided any affordance to "reconfigure their layout" in major ways yet, like adding a Split for example.

[andrewvarga]

to be honest at first I would have thought that especially if version changes are rare it's much easier to just live with the fact that users need to reconfigure their layouts every once in a while,

Yeah @andrewvarga I expect these versions will slow down tremendously in the future. One of the issues that I want to solve with this is for cases like the Bodies pane (#7564), which will update the Feature Tree pane everyone is used to to be its own Split layout with the operations list up top and the new bodies list below. I don't have a way to ship that update to users without blowing away their layout today. So this little system makes it so we can write a migration that switches in the bodies pane, increment the version, and users will get it when they open the app without losing the other stuff they've configured. We haven't provided any affordance to "reconfigure their layout" in major ways yet, like adding a Split for example.

That totally makes sense and it will be appreciated by users I think!

Also, confirmed those 2 issues look fixed now!

[andrewvarga]

Weird screenshot diff, I don't see any visual difference.