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.
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 --devYou’re now ready to take a snapshot of what’s important for a React Native project. Just type this one command.
$ yarn solidarity snapshotThat’s it!
The system will walk you through it from there. The following will happen:
- Since you don’t have a
.solidarityfile, 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:
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
- Watchman: 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.
Solidarity is the lockfile for your environment. Help us make it awesome!
- Star and share the repo: https://github.com/infinitered/solidarity
- Add it to your projects for peace of mind
- Publish your own plugins as you see fit
- Did you enjoy this article? Hold down the clap button for a few to thank.
- Join us in Slack to ask questions or chat: http://community.infinite.red/
Credits
- Steve Kellock — creator of Gluegun and inspiration for creating Solidarity
- Jamon Holmgren — significant contributor to Gluegun’s recent facelift
- Kevin VanGelder — helped make Solidarity work on Windows 💯%
- Random Hacktoberfest people who showed up to help this project!
- Blog content by Gant Laborde
About Gant
View technical tweets and puns with @GantLaborde on Twitter, or follow him on Medium and GitHub. You can see where he’s speaking next on http://GantLaborde.com/
Gant Laborde is Chief Technology Strategist at Infinite Red, published author, adjunct professor, worldwide public speaker, and mad-scientist in training.
Read the writings of Gant and his coworkers in our Red Shift publication or invite him to speak at your next conference.
