Using AI to migrate your migrations [tutorial (kind of)]

[gebeer]

Hi there,

why the heck would you want to migrate your migrations?

Since v6 of RockMigrations there's a new feature called "config migrations" which you can read more about here.

In a nutshell: instead of having an often lengthy migration function like
 

$rm->migrate([
    'fields' => [...],
    'templates' => [...]
])

with hundreds of lines in either site/migrations.php or site/modules/Site.module.php or other places, we can neatly organize our migration definitions into single files inside site/RockMigrations/fields and site/RockMigrations/templates (...roles, ...permissions). Where each file has the name of the field/template/role/permission and returns an array of  settings. If you have module specific migrations, they go under /site/modules/MyModule/RockMigrations/(fields/templates/etc)

This is absolutely wonderful for several reasons. Here's just a few that come to mind:

• clean structure
• smaller migration files
• easy to discover in explorer panel
• faster migrations because only migrations for changed files will fire
• portability across projects

Because I immediately fell in love with this concept, I am currently updating migrations for all projects to the new structure. This can be a very tedious task. We could write a script (and maybe this is the ultimate solution). BUT since I'm lazy, I just commanded my favorite AI assistant to do the job for me. I did this in windsurf editor Write mode (Cascade), but you can also use cursor's composer for this. Let me share how I approached it.

I created the directories "fields" and "templates" under site/RockMigrations.  And one migration file each for a field and a template to have examples to pass to the AI.
Then I copied the 'fields' array from above mentioned $rm->migrate(['fields => []]) (that was originally in my Site.module.php) and pasted it into the windsurf Cascade (or cursor composer) chat. Along with these instructions:

 

For each item in this array do the following operations:
1. create file site/RockMigrations/fields/{array_key}.php
2. add namespace ProcessWire and return the array found under this {array_key}
Mirror structure of @seo_fieldset.php 

Where @seo_fieldset.php is passing the contents of site/RockMigrations/fields/seo_fieldset.php as context to the AI.

And here's what happened:

windsurf Cascade decided to do the operation in batches. It would let me check the results after every 4 files or so and asked me if I wanted to continue with the next batch. After about 10 minutes all my 31 field migrations where refactored into the new structure and I was very happy following along while sipping away at my coffee :-)

After that I did the same for the 'templates' array.

Some considerations on why I chose this exact approach:

• I could have given the whole Site.module.php file as context and asked the AI to read the fields array from there. But that file is pretty large and the fields array alone was about 400 lines of code. And that might have exceeded the context window or at least confused the AI.
• I used the phrase "Mirror structure of ..." because I found that to be a very effective prompt whenever you want the assistant to write code based on an example. Actually I did not find that out by myself (I'm not that great of a prompt engineering genius). Got it from IndyDevDan over at YT. Highly recommended channel btw.

To wrap things up, I can highly recommend switching to the new config migrations structure. So much cleaner. So much better. A big praise to @bernhard for coming up with this. Also praises to the developers over at cursor and codeium (windsurf) for these amazing tools. And, not to forget: Hail Claude! 

[bernhard]

Hey @gebeer thx for that very cool tutorial! I migrated migrations for RockCommerce manually one by one 😅

1 hour ago, gebeer said:

This is absolutely wonderful for several reasons. Here's just a few that come to mind:

Not to forget that config migrations make sure that you don't get circular reference issues as they create empty fields/templates on the first run and then do the actual migrations on the second.

I also love them and I have no idea why it took so long to come up with that concept 🤷‍♂️