End Your Development Nightmares with envinfo and Solidarity

Hi, my name is Trevor Brendel. I'm a developer and I work for Modus Create. This presentation is called End Your Development Environment Nightmares with Envinfo and Solidarity. 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. These mention other relevant information such as operating system, Node.js, Yarn and MPM 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 part of the infomercial where we smash cabbages into a blender and 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 5 new developers getting started from different backgrounds on a React Native app. We all had different machine setups and React Native is a little finicky sometimes. This originally started with a shell script combining OS, Xcode, Node.js, MPM, Yarn, everything. But I realized that command minus v until you table flip isn't a lot of fun and that's a lot of commands to type in. Then I realized we're probably not the only ones having this problem so I wrote a PR to React Native to just give them my shell script that I used under React Native info. It was suggested 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 in 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. And 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's sake. Also, there's a sister project that is a bash related script for get-env.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 run it out.

So it turns out, all 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 plug-ins. 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. The 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 modiscreate.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 InvenFo or Solidarity.