Flint: lint your project for sources of contributor friction
I wrote previously on the benefits of bootstrapping consistency. Predictable scripts for automating setup and running tests greatly reduce the friction for newcomers to a project.
Recently, I've jumped back into some of my older projects and immediately felt the pain of not having bootstrap or test scripts to get up and running. Wanting a way to quickly check a project for these missing scripts and (other items that help reduce contributor friction), I wrote Flint as a small Bash script. Here's what it does:
While Bash was a good fit for the initial version, I have some ideas for Flint that really demand a higher level language:
- Open an issue in a GitHub repository. I'd like to run Flint in a project and just have it open an issue in the repo with each of the lint errors as TODO tasks in the issue body.
- Add missing files based on templates. I want to ship some default licenses (or pull them from choosealicense.com), and just add them to the project automatically. Boilerplate README, and CONTRIBUTING guides would be a logical addition, too.
Rewriting in Go
Ruby is my primary language, and I've written plenty of CLI apps in Ruby, but I thought I'd give Go a shot for this one, primarily for the reasons Mitchell Hashimoto and Jeremy Saenz have written about.
It's still early, but I've enjoyed writing a command line app in Go. Jeremy's cli.go project has captured much of the declarative expressiveness I like about David Copeland's gli CLI framework for Ruby.
See Flint on GitHub.