End Your Development Nightmares with envinfo and Solidarity

I my name is Trevor Brindle and I work for Modus Create. This presentation is called End Your Development Environment Nightmares with Envinfo and Solidarity. So your development environment. Your development environment is everything. The sum of all the tools and processes you use while developing software. Files, variables, binaries, apps, everything down to the shell you use when you're developing your application. A great example is react Native. The stack itself plus all the build tools, the debug tools, everything you use, editors, terminals, browsers, everything all counts. And it's growing in complexity. And wherever there's complexity, there's bugs. So the problems. Works on my computer. The evergreen command not found. What version do you have? What version do I need? And every issue template ever. Please mention other relevant information such as operating system, node.js, yarn, and npm versions. That's a lot of commands to type in. So how do I find this? If I need to find what Android SDK version I have? I don't remember. And I wrote a library that gets it. So this is the part of the infomercial where we smash cabbages into a blender and we have to say there's got to be a better way. There is. Know what you have and enforce what you use using nvinfo and solidarity. So nvinfo. What exactly is it? Let's back up a second with a story time. Imagine five new developers getting started from different backgrounds on a react Native app. We all had different machine setups.

So there's nothing inherently bad about having different machine setups. The problem is when they start to differ in ways that matter to your codebase. Version differences. You're using Xcode 10, I'm using Xcode 9. So how do we fix this?

Well, you could do the manual way. You could have some kind of a readme that says, you know, if you're using OS X, you need to have this version of node. If you're using Windows, you need to have this version of node. But that's a maintenance nightmare. It can drift from your actual requirements. You're trying to keep this updated, but people are changing stuff. And also it's not very scalable. Imagine if you had a large team and every time a new developer came on, you had to like have a training session with them. And you're like, hey look, if you're on OS X, you need to have this version of node. If you're on Windows, you need to have this version of node.

Instead we want it to be automated. We want to be able to check our development environment. And if it's not what we need, we want to be able to bail out or at least give them a nice warning message, something like this. So here we have a react Native app, and I'm checking my development environment with nvinfo. And it says my Xcode version is out of date. I need to install the latest one.

So let's look at an example of how we would do this. So I'm going to show you all the code up front and then we will go through it. So let's take a look at this nvinfo. So this is the nvinfo file. This is inside your project directory. And basically this is a JSON file. And it defines all the tools that your codebase requires, plus the versions and other metadata about those tools. So this is everything you need to know about your codebase and its development environment.

So let's take a look at the code. So basically, here in the main function, we're using a library called solidarity to read the JSON file, parse it, and then use that to basically go through each of the tools and do a check.

So let's take a look at how we check a particular tool. So this is how we check node. Every tool can have different ways to check it. So, for example, with node, we're going to use the node version manager. We're going to grab the node version that we have locally and then we're going to compare it to the version that we require, which is this one here. And we're going to do a semver range check. So if it's a valid semver range that's supported, here's a link to the docs. And then we're going to call this function called output.

So let's take a look at how this output works. So basically here, we're going to do a check if we pass. So basically, if the tool is installed and the version is correct, we're going to call this function called output pass. If not, we're going to call output fail. And then we're just going to basically pass the tool and the version that we need.

So you can see here, we're just going to log a message saying that basically this tool is installed and the version is correct. So we're going to pass green basically. And here we're going to log a message saying that basically this tool is installed, but the version is wrong.

So I'm going to show you how this looks in the terminal. So here I am in a react Native app, and I'm going to run nvinfo. And it's going to give me this nice little report. And you can see here, I'm on OS X, I'm on the latest version of node, and I'm on the latest version of react native. So this is what you want to see. Everything is good to go.

So let's say I change this node version to something that's wrong. So I'm going to say that I need node 10. And then I'm going to run nvinfo again. And you can see here, it's going to throw an error. It's going to say I have the wrong version of node. So it's going to fail red. And then if I go back and I fix the version, it's going to pass again.

So this is the basic gist. It's really simple. And then you can use it on your own codebases, get it up and running, and then you can run it on CI. So we're going to talk about that in a minute.

So nvinfo is just one tool, but there are a bunch of tools that are out there. And we actually have a website called Choose a Linter. So this is a site that helps you pick out a linter and a formatter for your project. Basically, you answer a bunch of questions, it picks out the best tool, and then it actually generates the configuration file for you.

And react Native is a little finicky sometimes. This originally started with a shell script combining OS, Xcode, Node, npm, yarn, everything. But I realized that command minus V until you table flip isn't an awful lot of fun. And that's a lot of commands to type in. Then I realized, you know, we're probably not the only ones having this problem. So I wrote a PR to react Native to kind of just give them my shell script that I used under react Native info. And it was suggested, you know, this probably shouldn't be our library. Why don't you write it? And so I did. The whole story is on Medium and on my blog, nvinfo and OSS story. And I highly recommend you take a look. So this is nvinfo. It might be a little anticlimactic, but it's incredibly useful because no one has really conglomerated this information together all at once. There's actually 17 different calls made to various system binaries just to show what's on this screen. And this is about 20% of what nvinfo can do. So the easiest way to run nvinfo is through NPX. Chances are it's probably already on your machine. You can also install it globally or download and run a binary. We bundle the node binary in there with it just for convenience sake. Also there's a sister project that is a bash-related script for getenv.info and then you pipe it directly to your bash. You can also add it directly as a dependency in one of your projects. So if you want to do that, you can import any one of the helpers that nvinfo uses under the hood and await them and then log them out. Or you can run nvinfo directly using run in a configuration object. Something that looks a little bit like this. So you pick and choose anything that you want, CPU, memory, bash, go, chrome, npm packages, and then print it out. So it turns out all of these projects saw a definite need for this type of thing, especially in issue templates, helping maintainers get better information to help people better.

So what if you needed more control on a per project basis rather than just running a script? You want to use Solidarity. So Solidarity is cross-platform, it's a light touch, it's time-saving, it's very easy to get started with. You can check files, variables, anything you can dump into a CLI or shell, and can also handle custom plugins. So getting started with Solidarity is easy. You install it, you create a.solidarity file, and then you run it. So this is the configuration. You create a object of requirements, you name it yarn or npm or whatever, give it a semver to look for, and a possible error message. The neat thing here is we can actually add it as templates, the installed version and the wanted version, so you can actually give your developers awesome error messages that they can copy and paste in scripts that will fix it for them. So this is it in action. You can check node npm binary, they both checked out. Your yarn binary is actually ahead of what you're supposed to be on for this project, and we know that yarn is not necessarily deterministic if it's not on the same version. So Solidarity checks failed. We can copy and paste in that curl script, and then it'll check out. So what if we actually wanted that 1.6 version, we wanted to update? Well, simple as run solidarity snapshot, and then it'll set yarn to that version. Run it again, and everything checks out. Some neat tricks you can do. I call it paint it red mode. It's called unterminated escape code, so if you know anything about terminal, go look up terminal escape codes, and you can use that in your script. Don't terminate it, so on your npm pre-build hook, if it fails, you just paint the background red, but you still let the developer continue to build. So it's a nice way to give them that warning without actually ruining their flow. So you can put this on pre-commit hooks, pre-build hooks, and it's especially nice on pre-commit for git config. So if you want to make sure everyone's actually committing with the right email, this is a good way to do it. So here it is. You can have something not checking out, but still letting your developer continue building. And that's it.

If you like this content and want to see more, you can always look at moduscreate.com, follow us on Twitter, you can follow me on Twitter, and reach out to me directly if you want to see anything new in InvenFlow or Solidarity. Thanks.