Redwood: [CLI] automate background checks for new versions, prompt for upgrade

[thedavidprice]

This is an enhancement to CLI behavior.

Ideally, the Redwood CLI will auto-check if it can be upgraded:

• run background check
• if a more recent version is available, unobtrusively prompt user (e.g. do not interrupt a process like yarn rw dev, although this will likely be the most frequently used command)
• confirm the current version and provide the most recent version
• bonus: Provide a link to release notes and/or strong messaging to read release notes before upgrading
  
  
  
  • many releases include breaking changes, we need to emphasize this will messaging/content
  
  
  • consider checking release notes if the words "break" or "breaking" are included; give warning if so
  
  
• prompt user to run yarn rw upgrade when ready to upgrade all RW packages

[geoff616]

I would like to help with this, and wanted to confirm I understand the goal of the feature and figure out where the notice should be displayed.

The goal of the feature is to inform developers they are not running the latest version of redwood, and encourage them to safely upgrade?

I've started looking into how it could be implemented, and thinking it makes sense as a yargs middleware so the feature can run on all (or a subset) of yarn redwood commands without changing anything in commands/. For checking the versions, I can get both currently installed and latest by shelling out to yarn outdated @redwoodjs/core. Going to defer on the bonus part about breaking changes until the main part is working, but I could try to parse the release notes returned from Github's API.

The main decision I need to make next is how to inform the user there is a newer version. I don't want to slow down the CLI with the yarn outdated check (400-1000ms in local testing), but do want the notice to consistently be in the same place (i.e. not logging it immediately in the middle of the console when the async check returns). To get the notice at the top of the logs like the examples below, I am thinking of having the middleware run a non-blocking check for a new version on every command. If there is a new version, I would set a flag in a file to indicate there is a newer version. To consistently have the notice at the top of the logs, I could block (1-2 ms in local testing) while reading the flag before kicking off another async check for a new version. This would prompt the user to upgrade on the 2nd redwood command after the new version becomes available.

Do you think the consistent location of the message is important for users, or that the notice should be somewhere other than the top of the console logs?

Example Notices

~/redwood-app$ yarn rw dev
yarn run v1.22.4
$ /redwood-app/node_modules/.bin/rw dev
Notice - A Redwood Upgrade is Available to 0.10.0 from 0.8.2 - Check out the [Release Notes](https://github.com/redwoodjs/redwood/releases) before running `yarn rw upgrade`
$ /redwood-app/node_modules/.bin/prisma generate --watch
...
09:17:05 web | ℹ ｢wds｣: 404s will fallback to /index.html

---

~/redwood-app$ yarn rw build
yarn run v1.22.4
$ /redwood-app/node_modules/.bin/rw build
Notice - A Redwood Upgrade is Available to 0.10.0 from 0.8.2 - Check out the [Release Notes](https://github.com/redwoodjs/redwood/releases) before running `yarn rw upgrade`
  ✔ Generating the Prisma client...
  ✔ Building "api"...
  ✔ Building "web"...
✨  Done in 14.90s.

[thedavidprice]

@geoff616 this would be fantastic! Thank you for offering to jump in. I've assigned this to you.

The goal of the feature is to inform developers they are not running the latest version of redwood, and encourage them to safely upgrade?

^^ Yes indeed! In general, we are attempting to release more often and want it to be convenient+simple to 1) know a release is available and 2) upgrade. However, because Redwood is early it's often not "safe" to upgrade without checking the release notes. This is also important because most new feature and improvement communication is via Release Notes. Here's how I'd prioritize goals:

1. Notify developer a new version is available: display new version number and display current version for comparison
2. Provide the link to GitHub Release Notes: I suggest this be the static link to the overview Release page (and not the specific release).
3. Give yarn rw upgrade command reminder

yargs middleware

^^ ✅ 🚀

Going to defer on the bonus part about breaking changes

^^ understood and we'd want to discuss implications for standardizing the Release Notes structure.

But, thinking from how we can "help developers follow best practices and develop good habits" --> I'd rather individuals assume _every_ upgrade has the potential to break things and looking at Release Notes is not skippable. If they rely on the tool to warn them, then their habits will be formed differently. Thoughts/reactions to this?

Do you think the consistent location of the message is important for users, or that the notice should be somewhere other than the top of the console logs?

^^ In regards to your overall design approach discuss prior to this question, I definitely give it a 👍. Doing this somehow async from the command being run was a primary concern of mine. And it feels very reasonable this would show up on the _next_ command run.

But personally I had assumed this message would display at the end of the console logs. It feels a bit out of context to me if there's content between the command and the initial command output. Some output has many lines (especially for generators) and could easily push this off-screen. Also, in response to your mockup (very helpful!), I'm ok with it spanning multiple lines and including a symbol/emoji to stand out. TBD

Additionally, if this is potentially a "final task" that runs at the end of a command, it could always check for the _flag_ as the last step -- if yarn outdated was run async, in some cases, it might have had time to run and would catch the update on the same command. Otherwise, it would catch on the next command run.

Last question --> what event would clear the flag and/or how many times should the "hey, you there, upgrade your things!" message be displayed. Once, X times, ... or forever until they upgrade?

[geoff616]

Thanks for the additional context @thedavidprice.

I agree with

individuals assume every upgrade has the potential to break things and looking at Release Notes is not skippable.'

and always pointing people to the release notes.

I've moved the console log to the process.exit hook so it is consistently the last message in the console.

I used an exponential backoff so it isn't displayed on every command, and reset the counters when there is a newer version published. I've also added a configuration option to redwood.toml so it can be turned off completely for a project if they don't want to be reminded.

I've opened #692 with the current implementation.