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.

That is if you’re using RVM obviously. I’m not an RBenv expert but this plugin looks like a good solution.

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.