As a team, it’s nice to have a ground set of similar tools. At Cookies for example, everybody uses Tmux and Tmuxinator, regardless of their terminal or editor choice.
For those of you who have never heard of Tmuxinator, it’s a fantastic Ruby gem that allows you to preconfigure, on a project basis, your tmux views.
After a few years using it, we’ve picked up some tips on how to make the most of it.
TIP #1, always have Tmuxinator ready
There is nothing more fustrating than cloning a new project, installing your Ruby version or gemset and the realising that your favorite tool is not there.
To have Tmuxinator installed alongide every new version of Ruby you would install, just edit
~/.rvm/gemsets/default.gems and add
tmuxinator at the bottom of the file.
Now, installing a new Ruby version will automatically install the Tmuxinator gem.
TIP #2, don’t set with the defaults
Tmuxinator has a very useful
pre that will be run before any Tmux windows are created.
This is extremely useful to launch related services that you don’t wan’t to have always running on your machine.
For example, one of our projects is using MongoDB and Elasticsearch.
I don’t always want to have Mongo (or ES) running when I boot my machine, you can, using homebrew services if you’re using Mac, write your
pre command like this:
pre: - brew services start mongodb26 - brew services start elasticsearch
Secondly, we use gard on most of our projects. As we all have a large monitor to work with, we can maximize the layout by setting our default view to have 3 panes instead of 2.
Here is our usual config
windows: - editor: layout: main-vertical panes: - $EDITOR - bundle exec guard - - server: heroku local - console: rails c - logs: tail -f log/development.log
This means that my coding window looks like this:
If you combine this window layout with your Tmux windows movement VIM like and the Zoom shortcut you then have a very powerfull interface at your fingertips.
You can use the 5 tmux standard layout, or define your own
TIP #3, share your tmuxinator file with everyone
As seen with TIP #2, it’s useful to put some elements on configuration in Tmuxinator itself.
If you maintain your files well, I would recommend that you share them with your team. Worst case, it gives a point of reference for people who have a different setup; best scenario, it becomes the defactor way of starting the application.
We are not starting VIM using the vim command, but the
$EDITOR ENV variable, allowing anyone to pick their favorite.
Add a local-config folder to your project and copy your project-name.yml tmuxinator ready file.
When a new person starts to work on the project, you only have to run
ln -ls local-config/project-name.yml ~/.tmuxninator
Now every time your tmuxinator config is updated in the repo, you will have the latest version available.
I find it’s a much better option than adding the whole Tmuxinator config into the Readme, since you will have to keep both versions in sync with every minor change.
These are just 3 quick tips that makes our lives easier. But if you have some Tmuxinator tips you can’t do without, please feel free to share in the comment section.