My understanding is they made an LLM skill for updating because it’s trendy and people are gonna point an agent at it anyway. I think the winning idea is you can update components in your design system piecemeal instead of needing to do a Migration.
Oh yes you are right. My bad. I got my dependencies backwards. We were using react 17 and wanted to upgrade to 18, but first we had to migrate an entire app on MUI v4 to v5 first since v4 was not supported by 18. And it was an upgrade full of breaking changes.
My point still stands that having a UI library like MUI deeply ingrained into your app can cause dependency and other issues like this. The speed you get upfront can bite you if you don’t plan carefully. Sure there are steps we could have taken to avoid such a mess. But that’s not how things often work out.
Ticking up a version number is all fine and good until it requires a dependency upgrade you aren’t ready for. If for example you wanted to upgrade MUI from 4 to 5, you’d find react 17 wasn’t supported. And if you weren’t ready or able to upgrade react, then you’d just be stuck using a UI library going more out of date by the day.
With shadcn / the copy paste format, you’ll almost never see that happen. The button shadcn provides for example is just css / tailwind. And if you did ever for some reason want to bring in a dependency for your button component you wouldn’t have to consider its effect on your other UI elements. The rest of your components can live independently (for the most part)
We have customized UI components we got from shadcn and now some use radix and some use base ui, and some have other dependencies or no dependencies at all. Properly tree shaken this is not a big deal at all and we can upgrade components individually as needed.
For boring applications this may be a bit much. But even then if you wait too long and mantine falls behind more than a couple versions, who knows how easy it would be to get your whole project up to date.