davewasmer
commented
7 years ago Braindump:
Should investigate https://github.com/facebook/jscodeshift.
We could include a set of "migrations" for each version, which are codemods that transform an app source code to what is expected in the next version. For things that can't be codemodded, the upgrade command gives us a good, high visibility spot to enumerate those manual actions that are necessary (and we can potentially programmatically detect their presence, so we only warn for things that actually need to happen).
Once things settle down for a 1.0 version, breaking changes will be introduced via deprecations first, so codemods wouldn't need to run on upgrades that introduce deprecations. This means that users can run them at their leisure, which is good for DX, but means we would need to be able to track which codemods have been run, and which still need to. Or, perhaps the codemods could be idempotent, so we could just re-run all of them, and duplicate runs won't hurt anything.
denali upgrade, when run inside a Denali app or addon, should upgrade to the specified (latest by default) version of Denali. This includes updating package.json and installing the version, but also running any kind of blueprint necessary to update any app structures or files.An open question:
Do we simply run a blueprint again and, a la ember-cli, give the user the option to accept the change? Or do we try to do something more sophisticated as well/instead? For example, ship Denali itself with migration scripts, something more like codemod.