Belajar Tmux - Production-Ready Setup, Dotfiles & Portability

#Pendahuluan

Di episode 25 sebelumnya kita membahas integrasi dengan editor & developer ecosystem — menghubungkan tmux dengan Neovim/VS Code, lazygit, dan session switcher fzf. Semua setup itu berharga, tetapi ada satu pertanyaan yang belum terjawab: bagaimana membawanya ke mesin lain? Setup yang hebat tidak ada artinya jika tidak bisa direproduksi — dan reproduksibilitas adalah definisi kerja dari "production-ready".

Ini adalah masalah yang dialami setiap engineer yang pindah mesin: laptop baru, workstation kantor, server baru, atau container CI. Tanpa persiapan, setiap pindahan berarti membangun kembali konfigurasi dari nol, mengulang kesalahan yang sama, dan kehilangan keybinding yang sudah nyaman. Konfigurasi yang tidak ter-version control adalah pengetahuan yang hilang setiap kali mesin berganti.

Pada episode ini kita akan membangun fondasi yang menyelesaikan semua itu: menyimpan ~/.tmux.conf dan plugin di repo dotfiles, script instalasi otomatis (bootstrap) yang siap jalan di mesin kosong, conditional config untuk menangani perbedaan Linux/macOS, lalu checklist production-ready — backup/restore session, konfigurasi aman dan deterministic, standarisasi workflow di tim, serta dokumentasi keybinding untuk onboarding.

#Dotfiles: Satu Konfigurasi untuk Semua Mesin

#Mengapa Dotfiles Harus Versioned

~/.tmux.conf adalah aset yang sama berharganya dengan kode aplikasi — ia menyimpan jam-jam keputusan: keybinding yang disesuaikan, tema yang dipilih, plugin yang disaring. Perlakukan ia seperti kode:

Version control: setiap perubahan bisa dilacak, di-revert, dan dikaitkan dengan alasannya (commit message).
Backup: mesin rusak, konfigurasi tidak hilang.
Berbagi antar mesin: satu sumber kebenaran untuk semua mesin, tidak ada drift.
Onboarding: tim bisa memulai dari konfigurasi yang sudah teruji, bukan dari nol.

Prinsip intinya sederhana: jangan pernah mengandalkan konfigurasi yang hanya hidup di satu mesin. File yang tidak pernah keluar dari mesin aslinya adalah file yang siap menghilang.

#Struktur Repo Dotfiles yang Benar

Dotfiles tidak harus satu file raksasa. Konfigurasi yang dipisah per bagian lebih mudah di-maintain dan di-review. Untuk tmux, pola conf.d yang disource berurutan sangat efektif: file 10-basics.conf dimuat lebih dulu, lalu 20-theme.conf, lalu 30-platform-*.conf — nama dengan angka memberikan urutan yang eksplisit dan deterministik.

#Setup Script: Bootstrap Otomatis

Mesin baru seharusnya siap dalam hitungan menit: git clone repo, jalankan satu script, selesai. Script bootstrap melakukan tiga hal: membuat symlink dari repo ke ~, menginstal TPM beserta plugin, dan memverifikasi bahwa tmux memuat konfigurasi tanpa error. Jika salah satu langkah gagal, script berhenti — tidak ada setengah-setengah.

#Menangani Perbedaan OS: Linux vs macOS

Satu konfigurasi yang sama untuk semua OS jarang berjalan mulus. Perbedaan yang paling umum: clipboard (di macOS, pbcopy/pbpaste; di Linux, xclip/xsel), dan kadang perbedaan pada default-terminal dan binding copy. Solusinya bukan dua file yang berbeda total, melainkan satu konfigurasi inti yang identik di semua mesin, plus satu file kecil khusus platform yang dimuat bersyarat.

#Conditional Config di ~/.tmux.conf

if-shell memungkinkan tmux memuat konfigurasi yang berbeda berdasarkan kondisi eksternal — misalnya hasil uname -s:

~/.dotfiles/
├── .tmux.conf
├── .tmux/
│   ├── conf.d/
│   │   ├── 10-basics.conf
│   │   ├── 20-theme.conf
│   │   ├── 30-platform-macos.conf
│   │   └── 30-platform-linux.conf
│   └── plugins/
├── install.sh
├── bin/
│   └── tmux-cleanup.sh
└── README.md

#!/usr/bin/env bash
set -euo pipefail
 
DOTFILES="$HOME/.dotfiles"
 
ln -sf "$DOTFILES/.tmux.conf" "$HOME/.tmux.conf"
ln -sfn "$DOTFILES/.tmux/conf.d" "$HOME/.tmux/conf.d"
 
if [ ! -d "$HOME/.tmux/plugins/tpm" ]; then
  git clone https://github.com/tmux-plugins/tpm "$HOME/.tmux/plugins/tpm"
fi
 
tmux source-file "$HOME/.tmux.conf"

Baca dari kiri ke kanan: repo menyimpan satu ~/.tmux.conf yang isinya konfigurasi inti; conf.d menampung bagian-bagian yang disource berurutan; if-shell memilih file platform yang tepat; dan file platform masing-masing hanya berisi perbedaan kecil — di contoh ini, perintah copy yang menulis ke clipboard sistem. Konfigurasi inti tetap satu, perbedaan diisolasi ke file kecil yang mudah di-review.

Warning

Uji konfigurasi di kedua platform sebelum menyimpannya. pbcopy tidak ada di Linux dan xclip tidak selalu ada di macOS. Pola yang benar: file platform hanya berisi perintah yang tersedia di platform itu, dan jika sebuah perintah bergantung pada paket eksternal (xclip), pastikan ia diinstal di bagian bootstrap mesin tersebut. Konfigurasi yang mengasumsikan satu OS adalah konfigurasi yang akan gagal di mesin lain.

#Production-Ready Checklist

Konfigurasi yang bisa direproduksi adalah awal; konfigurasi yang bisa diandalkan di production adalah tujuan. Berikut area yang harus kalian tutup.

#Backup & Restore Session

Session tmux adalah state kerja kalian — dan state harus bisa diselamatkan. Dua plugin yang kita singgung di episode 12:

tmux-resurrect: menyimpan dan memulihkan layout session, window, pane, dan cwd.
tmux-continuum: otomatis menyimpan secara berkala dan me-restore saat server dimulai.

Keduanya dimasukkan lewat TPM seperti plugin lain. Yang sering dilupakan: uji restore-nya. Konfigurasi restore yang tidak pernah diuji adalah konfigurasi yang akan gagal di saat paling dibutuhkan — persis seperti backup database yang tidak pernah diuji restore-nya.

#Konfigurasi Aman & Deterministic

Deterministic berarti: mesin yang sama, langkah yang sama, hasil yang sama. Praktik yang mendukungnya:

Urutan eksekusi eksplisit: penamaan 10-, 20-, 30- pada conf.d menjamin urutan tanpa ambiguitas.
Versi plugin di-pin: plugin yang di-clone tanpa versi bisa berubah kapan saja. Pin ke tag atau commit yang teruji, atau terima bahwa update bisa mengubah perilaku.
Hindari path absolut: gunakan ~ dan $HOME agar konfigurasi portabel antar user dan mesin.
Set renumber-windows on: window selalu bernomor berurutan, tidak bergantung pada urutan pembuatan — output script yang bergantung pada nomor window menjadi lebih stabil.

#Standarisasi Workflow Tmux di Tim

Ketika tmux dipakai bersama di sebuah tim (misalnya untuk akses bersama ke server production, episode 17), standarisasi mengurangi kesalahan. Tetapkan satu konfigurasi sebagai acuan, review perubahan seperti review kode, dan simpan di repo tim (atau fork dari dotfiles pribadi). Perbedaan kecil antar anggota tidak masalah selama prefix, keybinding inti, dan pola session naming konsisten — karena itulah yang dipakai saat kolaborasi dan saat onboarding orang baru.

#Dokumentasi Keybinding untuk Onboarding

Keybinding yang tidak terdokumentasi adalah pengetahuan tersembunyi. Untuk tim, buatlah cheatsheet singkat di README repo dotfiles: tabel prefix, navigasi pane, window/session, copy mode, dan custom binding. Untuk diri sendiri, ada cara otomatis yang bagus — tmux sendiri bisa mencetak semua binding:

Ekspor keybinding tmux ke cheatsheet

tmux list-keys > ~/.dotfiles/docs/tmux-keys.txt

tmux list-keys mencetak seluruh keybinding yang aktif. Simpan outputnya ke repo sebagai referensi yang selalu sinkron dengan konfigurasi — tidak pernah ketinggalan seperti dokumentasi manual.

#Checklist Production-Ready

Gunakan checklist berikut sebagai tolok ukur kesiapan setup kalian:

Konfigurasi tersimpan di repo dotfiles yang ter-version control.
Bootstrap mesin baru berhasil dengan satu perintah di Linux dan macOS.
conf.d disource berurutan, urutan eksplisit dan deterministik.
Perbedaan platform diisolasi di 30-platform-*.conf dan teruji di kedua OS.
Session restore (resurrect/continuum) aktif dan restore-nya pernah diuji.
Versi plugin di-pin atau ada kebijakan update yang disadari.
Keybinding terdokumentasi (README + tmux list-keys) untuk onboarding.
Config divalidasi dengan tmux source-file tanpa error sebelum dipakai.

#Kesalahan Umum (Common Pitfalls)

Hardcode path yang tidak portabel. Path absolut seperti /home/arman/.tmux.conf di dalam config atau script membuat setup gagal di user lain. Solusi: gunakan ~ dan $HOME, dan jadikan repo path sebagai variabel di script.
Menyimpan config tapi tidak pernah menguji restore. Plugin restore dipasang, tetapi pertama kali diuji justru saat mesin rusak. Solusi: uji restore di mesin staging secara berkala.
Satu file untuk semua OS. Menulis bind-key ... copy-pipe-and-cancel "pbcopy" langsung di ~/.tmux.conf membuat Linux gagal. Solusi: pisahkan ke file platform dan muat dengan if-shell.
Plugin tanpa versi yang berubah diam-diam. Update plugin merubah perilaku setup tanpa ada yang menyadari. Solusi: pin versi atau jadwalkan review update, bukan update otomatis buta.
Dokumentasi yang membusuk. Cheatsheet ditulis sekali lalu tidak pernah diperbarui. Solusi: jadikan tmux list-keys sebagai sumber, atau perbarui README di commit yang sama dengan perubahan config.
Bootstrap yang tidak diuji dari mesin kosong. Script bekerja di mesin kalian, tetapi gagal di mesin bersih karena urutan dependensi. Solusi: uji di VM atau container sekali dalam satu siklus rilis.

#Penutup

Pada episode 26 ini, kalian telah menyiapkan tmux menuju standar production: dotfiles yang ter-version control dengan struktur conf.d yang jelas, script bootstrap satu perintah yang memasang symlink dan TPM, conditional config berbasis if-shell untuk menangani perbedaan Linux/macOS, backup/restore session dengan resurrect/continuum, konfigurasi aman dan deterministic, standarisasi workflow di tim, serta dokumentasi keybinding untuk onboarding.

Poin kunci yang perlu kalian bawa:

Dotfiles adalah aset: version, backup, dan bagikan; jangan biarkan ia hidup di satu mesin.
Bootstrap satu perintah mengubah pindah mesin dari proyek menjadi rutinitas.
if-shell + file platform memisahkan perbedaan OS dari konfigurasi inti.
Backup tanpa restore yang teruji adalah ilusi; deterministik berarti hasil yang bisa diprediksi.
Standarisasi tim berfokus pada konsistensi inti (prefix, keybinding, naming), bukan keseragaman total.

Dengan setup yang reproducible di tangan, kalian hampir sampai di puncak series ini. Di episode 27 selanjutnya, sebagai episode penutup, kita akan membahas ekosistem alternatif & refleksi akhir — perbandingan jujur tmux melawan Zellij dan GNU Screen, kapan memakai masing-masing, panduan migrasi dari GNU Screen ke tmux, serta rekap perjalanan dan checklist daily-driver untuk membangun muscle memory yang bertahan. Pastikan tetap semangat!