Solidarity — The CLI for Developer Sanity

Add Solidarity to your project for multi-machine peace of mind

How many times have you pushed up your code just to have a team member or client grab the latest and then *sad trombone* 😭 it just fails to work.

The hunt for the issue is always an unwelcomed and time-stricken stress. Besides implying some grueling insecurity with your project, it’s hard to plan for this common headache. And of course, it always ends up being something simple and preventable. We just need a good way to prevent it! That’s why we made free, simple, and open-source Solidarity.

Solidarity is a command-line tool that lets you check your machine’s environment against a project’s expected environment, and warns you if you’re missing something.

An environment checker for project dependencies across multiple machines.

Imagine this scenario:

Betty pulls down the latest code to find it doesn’t work on her machine. You then ask her to run $ yarn solidarity to make sure the results are clean. She reports back that the command failed because it identified she was missing a required binary, but she installed the missing item and now the project is 💯 and everyone is happy.

THAT is what solidarity does. It helps you lock down the ever-growing environmental tooling you need for your project.

Solidarity is the perfect tool for making sure your team is sharing the same complex environment without worrying about the environment complexity.

See it in action — Let’s add this to a project:

Solidarity is project agnostic, so try to read between the lines as we apply it to a concrete example. For this example, I’ll add Solidarity to a React Native project since those always contain numerous moving parts, and there’s an existing Solidarity snapshot we can use.

We’ll forego global installing and simply use the node_modules of a single project. To start, let’s install two things: The Solidarity tool, and the React Native Solidarity snapshot plugin.

$ yarn add solidarity solidarity-react-native --dev

You’re now ready to take a snapshot of what’s important for a React Native project. Just type this one command.

$ yarn solidarity snapshot

That’s it!

The system will walk you through it from there. The following will happen:

Since you don’t have a .solidarity file, you’ll be prompted to create one It will ask what plugin you’d like to use to take a snapshot of the environment rules

We’ll use the React Native plugin that we just installed. The whole dance looks like so:

Automatic snapshot hawtness 🔥

This generates all the environment rules and installed versions pertaining to React Native on your system in a .solidarity file. Now if you run a solidarity check, you’ll pass with flying colors! But will other machines?

Check your .solidarity file into version control, and now you can add the checking command, yarn solidarity for checking on production, CI, or any other machine. It’s that easy!

What if there’s no “snapshot” for my tech stack?

Is it easy to write your own plugin? Yes, it’s very easy… but you really don’t have to. Writing rules by hand is a simple as listing aspects of your environment, in a JSON file.

Just open up a .solidarity file, and the structure is for you to open an object where every key is a requirement. The value will be the rules that enforce that requirement!

Any developer can read this random set of example requirements:

A .solidarity file is just a simple JSON file. The above file has three requirements: Node, Watchman, and Optimize Service.

Node : checks for a binary of a certain version to be installed

: checks for a binary of a certain version to be installed Watchman : this will check for a binary of any version, but only for MacOS. We even provided a friendly message to help the user

: this will check for a binary of any version, but only for MacOS. We even provided a friendly message to help the user Optimize Service: Comprised of two rules. One to check for the existence of a CLI, and the other to check for an environment variable to be set

Writing Rules: Will your rules look like that? That’d be crazy if it did. But something tells me you already know what environment issues to check for. Perhaps a specific Android SDK, or an environment variable that’s always missing? See everything rules can do from the docs here: https://github.com/infinitered/solidarity/blob/master/docs/options.md

Writing a Plugin: Once you’ve written a rule-set, you’re 80% of the way there to making a plugin. See how to convert your file to a plugin that you can share with everyone here: https://github.com/infinitered/solidarity/blob/master/docs/plugins.md

That’s it for making custom rules! Everything is right here on the docs site.

Why not just use containers?

For the exact two conditions where containers are hard to enforce. As software consultants and open source contributors, it’s unreasonable for us to impose complicated containers outside of our organization. Solidarity is “light-weight environment checking” for a reason. Our on-boarding, and migration: two things we have to keep lean and scalable for each project. Bonus Fact: It’s easy to just add a small dependency and focus on the project tasks at hand.