Hello all,
I was just made aware that in the web frontend world, the React framework provide “code mods” to help automatically upgrade packages to a new version. Here’s an example.
Although GHC version upgrades are getting easier, I wonder if people have experience with automatic upgrades like React’s? Is this something we should look into as a community: a collection of upgrade scripts for new versions of GHC and other important libraries, like aeson and text?
I really we wish we had more solutions in this direction!
I remember a few years ago there was a breaking change to do with mtl, and I suggested we make some form of automatic migration for it. It only required changing imports so it should have been relatively easy. This seemed like the sort of thing in hlint’s wheelhouse so I gave implementing it a go. Here is the issue for that: Linting for deprecated re-exported modules · Issue #1460 · ndmitchell/hlint · GitHub.
I quickly got stuck for two reasons. hlint doesn’t perfectly understand which identifiers come from where, so I ran into cases where it missed things. It also turned out that apply-refact didn’t support the sort of refactor that would be required to fix this issue.
I’m sure these sorts of issues are surmountable, but I definitely left this attempt with the impression that these sorts of code refactors are more effort than they initially appear. I also realized that even if I could make these changes automatically, I would still need to reformat exports (either manually or using a code formatter if appropriate) to match a library’s code style.
Often as well, the code changes to deal with a breaking change tend to be trivial and just a few lines of code, and the bottleneck is maintainers’ resources (reviewing PRs, releasing new versions, etc).
A lower effort alternative to automatic code migration is to write a migration guide. GHC has been doing this for a long time (Migration Guide · Wiki · Glasgow Haskell Compiler / GHC · GitLab), but they are not widely known about. I have seen some packages also do this in their changelogs. I think this sort of thing can be extremely useful. It’s not as good as something automated, but it’s also a lot less effort.
Hmm that makes sense, and no automation can help. Ultimately, a human should review all the changes, regardless of whether it was done automatically or not.
I’m also thinking that there’s a difference between migrations from a compiling version to another (e.g. map f xs to fmap f xs), and migrations from a piece of code that compiles with GHC verion X, to a different piece of code that only compiles with GHC version Y. This kind of type-aware migration seems like it would require lots of tooling.
Well, I’‘ll keep this idea in my back pocket for the time being