It's quite an indictment of the current state of our tooling (not just tmux) that such an application as this is necessary. Why isn't it easy to configure this in tmux itself, and persist the resulting configuration?
This doesn't let you persist ad hoc setups, but I have a `~/lib/tmux-code` file that I source from `~/.bash_profile` with entries like this:
function ins-code {
env_name=code
long_name=insurance
short_name=ins
tmux_session=${short_name}-${env_name}
if tmux list-sessions | grep ${tmux_session}; then
tmux attach-session -t ${tmux_session}
else
cd ~/src/${long_name}/backend/app/models && \
tmux new-session -d -s ${tmux_session} && \
tmux rename-window -t ${tmux_session}:1 models
cd ~/src/${long_name}/backend/app/controllers && \
tmux new-window -t ${tmux_session}:2 -n controllers
cd ~/src/${long_name}/backend/app/views && \
tmux new-window -t ${tmux_session}:3 -n views
cd ~/src/${long_name}/backend/app/assets/stylesheets && \
tmux new-window -t ${tmux_session}:4 -n css
tmux select-window -t ${tmux_session}:1 && \
tmux -2 attach-session -t ${tmux_session}
fi
}
Then I can just say `ins-code` and it will either launch a new session or attach if it already exists.I highly recommend https://github.com/tmuxinator/tmuxinator if you haven't tried it, I've actually used it to run whole microservice environments locally and works without a hitch