Do you have a list of shell or batch scripts sitting inside your codebase that perform development tasks? Have you ever had to implement the same script in a different language because most of your team uses Unix/Linux, but a fraction of your team uses Windows? Does your team store the scripts in various places or different languages?
I recently reflected on this problem while working with a client on an application distributed across a few repositories. I produced a solution that helped overcome some of the script blight that was affecting our project. My solution was to build a Command Line Interface (CLI) for my team. Back in the day, building a CLI was tedious, but now it is easy! Let’s dig into the problems we were able to overcome by creating our own tooling!
Using Gluegun, I was able to consolidate a few commands to help my development process a ton. I could execute scripts to launch my front end for local development, spin up my Docker containers, and launch a local windows application in one command. The best part is I did not have to change to three different directories to launch these services, and it will work for my team working with Unix/Linux or my team working on Windows. I can now run the tool for updating our types based on our API. In addition, I added some quality-of-life scripts for clearing out caches that I usually did by hand. The best part is that I can now share these scripts with my team by creating a new repository/package! I intend to add the generators that we previously wrote in Plop.js to be our one-stop-shop for developing our specific application.
As our team adds new scripts, we will have a central location to put the scripts in for working with the application regardless of the repository the scripts directly influence. Now our team can write the scripts once and run them on Windows or Unix/Linux! And finally, we can start everything we need without changing directories 1000 times a day!