Dev Teams, Lock Down Environment Versions With Volta

[00:00 - 00:15] Our last lesson had us upgrading the React app from React version 16.4 to react 17.0, and we resolved any errors that arose as a result of the upgrade. And that's all well and good, but there's more that we could do.

[00:16 - 00:35] In fact, more that we should do to ensure that when any other developers join our team and develop a new feature, it doesn't break the app right after deployment because they were developing locally on a different version of Node than the app is running on in production. I speak from personal experience when I say that this does happen in real life.

[00:36 - 00:52] That deployment went down in history for the dev team that lived it, the dev team that I was a part of as Dark Thursday. We were developing in Node.js 9 locally, but the Node.js version that was installed when we deployed to production was Node.6.

[00:53 - 01:00] That was a very long night. So let's take a couple of steps to prevent such catastrophes from happening.

[01:01 - 01:16] No developer should have to live through that if a little extra upfront work can prevent it. In this lesson, we'll learn how to explicitly define our project's environment configurations so that it's harder for devs to do the wrong thing than it is to do the right one.

[01:17 - 01:37] So the first thing that we're going to do is define the Node engines in our package.json. If you're not familiar with Node engines, it's a rarely discussed but very useful code snippet that you can include in a project's package.json file to let anyone downloading the code know exactly which versions of Node.js, npm, and yarn are required for the app to run.

[01:38 - 01:45] As the npm docs themselves put it, you can specify the version of Node that your stuff works on. That's it. Plain and simple.

[01:46 - 02:02] When engines are included, or you use the wildcard asterisk in a package.json, Node assumes any version of it will work. So that's why you would like to specify at least the lowest version of Node that your React application will successfully run on.

[02:03 - 02:17] So with that in mind, let's define our Node and Yarn versions for our app. Open up the client folder's package.json file and at the very end, right after license, following lines.

[02:18 - 03:01] Now, when a developer attempts to install the dependencies and run this app on a Node.js version other than the defined one, an error will be thrown in the console. So here is an example of a screenshot where I set the engine's node version to 12, but my local development environment is running Node.js 14.15.5. Here's my current Node version, 14.17.2.

[03:02 - 03:11] Now if I attempt to run it, we get this error of the engine node is incompatible with this module. Expected version 12 got 14.17.2.

[03:12 - 03:15] Cannot run with an incompatible environment. Great.

[03:16 - 03:46] So this warning message should deter most developers from attempting to go much further with an incompatible version of Node. There is one catch though, including engines alone in the package.json doesn't guarantee a developer must use the specified versions as defined. And if you're a dev lacking the recommended version of Node or NPM or Yarn or what have you, but you're excited to start developing that shiny new feature, you might be tempted to ignore the warnings provided by engines in the command line and forge ahead.

[03:47 - 03:56] For that reason, we're going to make it even easier for any dev to do the right thing. So easy in fact that you'll wonder how you ever developed without this little addition to your tooling setup.

[03:57 - 04:21] It's called Volta. So Volta is an awesome tool designed to make managing our JavaScript command line tools such as Node, NPM, Yarn, or Executables shipped as part of JavaScript packages really, really easy. Similar to package managers, Volta keeps track of which project, if any, you're working on based on your current directory.

[04:22 - 04:57] The tools in your Volta tool chain automatically detect when you're in a project that's using a particular version of the tools and takes care of routing to the right version of the tools for you. It's very cool in practice. Up to now, I'd been using NVM to manage and switch between different versions of Node.js, depending on which project I'm working on, but it was more complicated to set up initially and, more importantly, Volta takes the thinking part out of the equation. When it's set up in a project and installed on a local machine, I don't even have to think about switching versions. Volta just does it for me.

[04:58 - 05:14] So to get started, let's download Volta locally. We can do so by opening up a new terminal window and running the following command. You're going to curl get Volta.sh pipe bash.

[05:15 - 05:34] Now, to ensure that our Volta has installed successfully, open another new terminal window and type Volta-V. And we have 1.0.5, so we are good to go and ready to start using Volta.

[05:35 - 05:50] So now, we're ready to set up a specific version of Volta in our project. So let's go back into our client folder. And then we are going to run the following command to pin a version of Node to our app.

[05:51 - 06:15] We're going to do Volta pin Node 14.0.0. So even if you don't have this particular version of Node.js downloaded locally , by running this command, Volta will not only go out and fetch that version, but it will automatically add it to your package JSON right under the engine's info that we just added at the end of this file.

[06:16 - 06:30] Now it is right here. So if you look at your package JSON, now the bottom of the file as Volta. And if you check your terminal's local version with the Node-V command, it should say the same thing.

[06:31 - 06:43] And lo and behold, it does. So Volta was great for that, but Volta does more. We're not only going to specify our Node version and stop there, we're also going to specify our Yarn version for this project too.

[06:44 - 06:54] So pinning a particular version of Yarn is just as easy as pinning a particular version of Node. Once again in the command line, we'll do Volta pin Yarn.

[06:55 - 07:02] And now we see that we have a particular version of Yarn set up as well, 1.22. 11.

[07:03 - 07:19] And if we check what's running in our terminal, the very same version. For reference, my previous version of Yarn was 1.20.0, which you can still see if you go to another terminal that is not inside this particular file.

[07:20 - 07:28] And that's just the tip of the iceberg of Volta's capabilities. If you're interested to see what else it can do, I'd encourage you to check out the rest of Volta's documentation.

[07:29 - 07:43] It's quite thorough. We've really done some good in this lesson. Not only have we defined recommended Node and Yarn versions for any developer who joins the project now, but we've also made it harder to start doing local development on the wrong versions of Node and Yarn, thanks to Volta.

[07:44 - 08:01] This sort of low-level project configuration, although it only took a few extra minutes and lines of code now, is going to make a world difference to a development team in the future. If we can prevent even one failed deployment due to something as mundane as incompatible Node versions in development versus production, it will be worth it.