If your users globally install your CLI's, will they ever update them? How will they know about new features and patches? How do you check for updates without impacting performance? How do you respect user preferences to ignore your updates?
These are all solved problems with the wonderful update-notifier
library.
Instructor: [0:00] When you have a CLI out and in the wild, you're going to find that versioning is actually a difficult problem as well. When you have published a new version of your CLI, it's not necessarily clear that people will know about it, particularly if they've done a global install of your CLI. They may be slow to receive patches or updated features and that might be a problem.
[0:27] Fortunately, there is a package for that. That package is called update-notifier. That is responsible for this square box, which you've probably seen in your CLIs but not really wondered where they came from. I'm going to implement it in this CLI that I already have published. We'll see how it works.
[0:48] I have this CLI available. I happen to know that the latest published version is 1... To simulate a CLI that is out of date, locally installed CLI that is out of date, I'm going to backdate this to .9.. We're going to try to run this to see if there has been a version update detected.
[1:07] The best place to install update-notifier is inside of whatever my initialization code is. For me, that's base.ts. I'm going to import. I'm going to paste in my pre-prepared code. This basically requires update-notifier and then also reads in package.json of the project, which for the user is going to be the version of the CLI that they have installed.
[1:35] Inside of my init code, I'm going to paste in the boilerplate for using this update-notifier. Primarily there are three fields to take care of. There's the raw package.json field. There's a field for updateCheckInterval. This will basically debounce the number of times we're checking so we're not checking too often.
[1:56] We're also going to use this should notify npm script field basically to get past the fact that we're using a framework and we're not directly invoking this update-notifier in a top-level script. Then we're going to call this notifier.notify command.
[2:10] This looks synchronous, but it actually is totally async and therefore doesn't have any performance impact on your initialization. That's very important. In fact, it's going to run that update-notifier, check the latest version and save it, and only tell you about it the next time you run it. That's a very important and interesting feature of update-notifier.
[2:31] Now let's test it out. I'm going to run yarn mycli name. Remember, the latest version that I have is .9, but the published version is 1., so it is out of date. I'm going to cancel out of this. You can see because I've run this before that it's already cached the update.
[2:47] It's telling the user there's an update available. It looks like it's a major version. It leaves the power in the hands of the end user to decide if they really want to update that CLI. That's update-notifier in a nutshell. It's a very good thing to include by default in all your initialization code for your CLIs.
[3:07] In practice, you probably want to check for updates in a slightly longer interval, for example weekly. You can actually check out some of the other great options as well if you want to customize the behavior of how update-notifier works. It's a good library to incorporate by default.