One of the most terrifying moments in life comes when I see that list of Dependabot alerts in my email - even without opening up the email, I know that means that at least one of my repos needs me to go use the dreaded npm update - or at least npm install - not that using npm is in itself frightening, but it's the unknown breaking changes that scare me the most. Take for example the recent upgrade in TailwindCSS from 2.x to 3.x. To be fair, they do warn that this is a breaking change, but it takes a lot more digging to figure out what and why it breaks. When coupled with some PostCSS changes at the same time, you can hit a wall for several hours. In my case, I had to go back to first principles, carefully follow through the original setup instructions and finally get everything back to where it was before the update.
So here's my challenge - how can we make these kinds of updates more seamless? There may never be a perfect upgrade, but if (for example) I was to open an old Word document in the latest O365 version - I would expect it to look somewhat the same as the original. Fonts would have been converted, text markup would have been re-written. I might never be able to re-open it in the older version of Word again, but that's OK.
Let me talk you through the TailwindCSS experience - show you what I mean...
/tailwind.config.js
module.exports = {
purge: {
content: ["./**/*.html", "./**/*.scss", "./**/*.js"],
},
};
/tailwind.config.js
module.exports = {
content: ["./modules/**/*.{html,scss,js}", "./views/**/*.{html,scss,js}"],
};
This is a pretty simple example - I'm not using any of the main options in this file, but here's my point. Given that the original file MUST be in our 'standard v2.x' syntax and we need the new file in the 'standard v3.x' syntax - would it be too hard to write a migration tool to create a new version of the tailwind.config.js file during the update process? In this case, content simply moves from being a child of purge to being at the root level. At that point, we would then be able to do things like offer automatic upgrades, or guided upgrades - depending on the level of comfort that the user has.
At the end of the day, no-one knows your code like you do - especially right at the point of releasing a new version. Any migration assistance that you can give HAS to be useful!