Belajar Zellij - Production-Ready Setup, Dotfiles & Portability

#Pendahuluan

Semua konfigurasi yang kalian bangun selama 26 episode terakhir — config.kdl, layout KDL, theme, keybinding, hingga plugin — berharga justru karena bisa dibawa ke mana saja. Sayangnya, banyak orang meninggalkan konfigurasi itu teronggok di mesin lokal, tidak ter-version control, tidak terdokumentasi, dan tidak bisa direproduksi. Episode 27 ini mengubah itu: kalian akan menyiapkan setup Zellij yang siap produksi, portabel, dan deterministic.

Apa arti "siap produksi" dalam konteks ini? Tiga hal: (1) konfigurasi kalian tersimpan di repo dotfiles dan bisa di-deploy ke mesin baru dalam hitungan menit, (2) konfigurasi itu aman dan deterministik — hasil yang sama di mana pun dan kapan pun dijalankan, dan (3) alur kerja kalian bisa distandarkan untuk tim, bukan hanya untuk diri sendiri. Episode ini membahas sisi portability dan reproducibility yang belum pernah disinggung detail sebelumnya.

Rencana episode ini: (1) struktur repo dotfiles dan apa saja yang masuk ke dalamnya, (2) install script otomatis yang menangani bootstrap dari nol, (3) perbedaan platform Linux, macOS, dan Windows serta cara menjinakkannya, (4) session persistence otomatis dan konfigurasi yang aman, dan (5) standardisasi workflow tim. Di akhir episode, kalian akan punya blueprint lengkap yang bisa dipakai di mesin kerja, mesin pribadi, dan server produksi.

#Dotfiles: Satu Repo untuk Seluruh Konfigurasi

Direktori konfigurasi Zellij, ~/.config/zellij/, adalah rumah bagi hampir semua hal yang kalian sesuaikan: config.kdl, subdirektori layouts/, themes/, dan plugins/. Struktur standar repo dotfiles untuk Zellij terlihat seperti ini:

dotfiles/
├── zellij/
│   ├── config.kdl
│   ├── layouts/
│   │   ├── dev.kdl
│   │   └── server.kdl
│   ├── themes/
│   │   └── arman-dark.kdl
│   └── plugins/
│       └── status-bar.wasm

Aturan sederhananya: jangan pernah meletakkan konfigurasi yang hanya berlaku di satu mesin ke dalam repo. Ukuran font, keybinding yang benar-benar personal, dan path absolut proyek sebaiknya disimpan sebagai variabel atau layout per-project, bukan di-hardcode. Sebaliknya, semua yang bersifat umum — theme, keybinding default tim, layout project yang dibagikan, plugin yang dipakai bersama — layak masuk repo.

Aturan praktisnya: jika dua developer bisa memakainya tanpa konflik, masuk repo; jika hanya berlaku di satu mesin, biarkan di luar. Memisahkan keduanya sejak awal jauh lebih murah daripada membersihkan repo yang sudah terkontaminasi nilai personal.

Langkah pertama yang baik adalah memastikan konfigurasi kalian valid dan lengkap sebelum di-commit:

zellij setup --dump-config > ~/.config/zellij/config.kdl
zellij setup --check

zellij setup --check menjalankan serangkaian pemeriksaan environment dan konfigurasi — output hijau berarti setup kalian sehat. Verifikasi ini ideal dijadikan bagian dari install script, sehingga setiap mesin baru dipastikan sehat sebelum dipakai.

#Install Script Otomatis & Bootstrap Lintas Platform

Dotfiles hanya berguna jika bisa di-deploy dengan mudah. Untuk itu, build install script yang: (1) menginstal binary Zellij sesuai platform, (2) menautkan atau menyalin direktori zellij/ dari repo ke lokasi konfigurasi, dan (3) menjalankan verifikasi. Script ini bisa berjalan di mesin baru tanpa interaksi berlebihan. Untuk bagian instalasi, biarkan script memilih metode yang tepat per platform:

Installer resmi (Linux)Homebrew (macOS)Windows (native)

curl -sSfL https://install.zellij.dev | bash

brew install zellij

winget install zellij.zellij

#!/usr/bin/env bash
set -euo pipefail
 
REPO="$(cd "$(dirname "$0")/.." && pwd)"
CONFIG_DIR="${ZELLIJ_CONFIG_DIR:-$HOME/.config/zellij}"
 
command -v zellij >/dev/null 2>&1 || curl -sSfL https://install.zellij.dev | bash
 
mkdir -p "$CONFIG_DIR"
ln -sfn "$REPO/zellij/config.kdl" "$CONFIG_DIR/config.kdl"
ln -sfn "$REPO/zellij/layouts" "$CONFIG_DIR/layouts"
ln -sfn "$REPO/zellij/themes" "$CONFIG_DIR/themes"
ln -sfn "$REPO/zellij/plugins" "$CONFIG_DIR/plugins"
 
zellij setup --check

Pendekatan symlink memastikan perubahan di repo langsung tercermin di $CONFIG_DIR tanpa perlu salin ulang. Untuk pemakaian yang lebih terstruktur, GNU Stow (stow zellij) bisa menggantikan baris ln satu per satu. Jika preferensi kalian adalah menyalin, bukan menautkan, gunakan cp -r — dengan trade-off bahwa setiap update repo butuh penyalinan ulang.

Setelah bootstrap berjalan, langkah terakhir opsional adalah auto-start: zellij setup --generate-auto-start zsh menghasilkan snippet yang memulai Zellij otomatis setiap shell login — persis pola yang sering dipakai pengguna tmux untuk masuk ke session. Jika kalian memilih pola ini, pastikan default_mode diset ke locked (episode 22) agar shell login yang bukan Zellij tidak membuka pintu input yang tidak diinginkan.

Mengapa memakai ZELLIJ_CONFIG_DIR? Karena variabel lingkungan ini adalah kunci portability. Alih-alih bergantung pada lokasi default yang berbeda di tiap platform, kalian bisa menetapkan satu lokasi konsisten:

export ZELLIJ_CONFIG_DIR="$HOME/.config/zellij"

Dengan variabel ini di-set, Zellij mencari konfigurasi di lokasi yang sama di Linux, macOS, maupun Windows — dan repo dotfiles kalian tetap satu, tanpa percabangan.

#Perbedaan Linux, macOS & Windows

Setiap platform memiliki lokasi default dan perilaku yang berbeda. Memahami perbedaan ini adalah separuh pertempuran portability:

Perbedaan lokasi default inilah yang membuat ZELLIJ_CONFIG_DIR begitu penting. Dengan menyetelnya di shell profile, tiga platform berbagi satu path konfigurasi dan satu repo dotfiles. Untuk perbedaan yang tersisa, copy_command adalah contoh sempurna: kalian bisa menyesuaikannya per platform tanpa mengubah struktur repo — misalnya copy_command "wl-copy" di Wayland, "xclip -selection clipboard" di X11, "pbcopy" di macOS, dan Set-Clipboard di Windows.

Linux adalah tempat paling fleksibel, karena Zellij juga tersedia lewat package manager distribusi dan Cargo. macOS nyaman dengan Homebrew. Windows, sejak 0.44, berjalan native tanpa WSL — meskipun beberapa tooling seperti copy_command perlu disesuaikan dengan dunia PowerShell. Kunci dari semuanya: jangan hardcode asumsi platform di dalam layout atau config; gunakan variabel lingkungan dan biarkan script bootstrap yang menangani perbedaan.

Selain ZELLIJ_CONFIG_DIR, Zellij mengenal dua cara lain untuk mengarahkan konfigurasi dengan presedensi: flag --config-dir di command line dan variabel ZELLIJ_CONFIG_FILE untuk menunjuk satu file config tertentu. Hirarki yang perlu kalian hafal: flag command line menang atas variabel lingkungan, dan variabel menang atas lokasi default platform. Untuk setup portability, cukup satu sumber kebenaran — misalnya ZELLIJ_CONFIG_DIR di profile — lalu biarkan semuanya mengikuti.

#Session Persistence Otomatis & Konfigurasi Aman

Setup siap produksi harus bertahan dari reboot. Zellij menyediakan serialisasi session yang otomatis: konfigurasi ini akan menyimpan layout, tab, pane, working directory, dan perintah yang berjalan, sehingga session bisa di-resurrect setelah mesin reboot:

theme "arman-dark"
mouse_mode true
session_serialization true
serialize_pane_viewport true
scrollback_lines_to_serialize 10000

Dengan session_serialization true, setiap session yang keluar otomatis ditulis ke folder cache; serialize_pane_viewport ikut menyimpan isi viewport pane, dan scrollback_lines_to_serialize membatasi jumlah baris yang diserialisasi agar tidak boros disk. Untuk menghidupkan kembali session, jalankan zellij -l welcome lalu pilih opsi resurrect, atau gunakan session-manager dengan Ctrl+o lalu w.

Uji alur ini sebelum benar-benar membutuhkannya: buat session dengan beberapa tab dan perintah berjalan, keluar dari Zellij, lalu restart mesin (atau cukup panggil ulang welcome screen) dan resurrect session tersebut. Pastikan tab, pane, working directory, dan perintah yang berjalan kembali seperti semula. Uji ini sekaligus memvalidasi bahwa post_command_discovery_hook (jika dipakai) berperilaku sesuai ekspektasi. Session yang bisa di-resurrect dengan andal adalah pembeda utama antara setup "berfungsi" dan setup "siap produksi".

Di sisi keamanan, ada beberapa prinsip yang menjaga konfigurasi tetap aman dan deterministik. Pertama, jangan pernah menyimpan secret di dalam config.kdl, layout, atau theme — masukkan lewat environment variable. Kedua, validasi setiap perubahan dengan zellij setup --check dan uji konfigurasi baru sebelum mengganti yang lama: jalankan zellij --config /path/to/new.kdl dalam sesi percobaan. Ketiga, waspadai layout remote: layout yang dimuat dari URL menggantung semua perintahnya di balik banner konfirmasi untuk alasan keamanan — pahami ini sebelum membagikan layout lintas jaringan.

#Standardisasi Workflow Tim

Level terakhir dari setup siap produksi adalah membagikannya ke tim. Ketika config.kdl, layout project, dan theme tinggal di satu repo, onboarding anggota baru menjadi jauh lebih cepat: clone repo, jalankan bootstrap script, dan mereka langsung punya workspace yang sama dengan seluruh tim.

Standardisasi bukan berarti memaksakan satu cara — melainkan menyediakan titik awal yang konsisten. Praktik yang berhasil di tim biasanya meliputi:

• Repo dotfiles bersama dengan struktur zellij/ yang jelas.
• Layout per project yang menstandarkan struktur workspace (editor, dev server, git, logs).
• Keybinding tim yang didokumentasikan, sehingga anggota yang pindah mesin tidak bingung.
• Review pull request untuk perubahan config, persis seperti perubahan kode.

Untuk tim yang mengelola banyak service, layout server admin yang dibagikan menghemat waktu nyata: satu layout yang membuka log, healthcheck, dan deployment tool di pane terpisah, siap dipakai siapa pun yang on-call. Kombinasi layout + plugin yang dibagikan lewat repo adalah bentuk konkret dari "workspace sebagai kode".

Jangan lupa bahwa standardisasi juga mencakup kontrak antar proses. Ketika session di-resurrect di mesin anggota tim, Zellij mencoba menemukan perintah yang berjalan di tiap pane; jika tooling tim dibungkus wrapper, opsi post_command_discovery_hook memungkinkan kalian memodifikasi hasil penemuan perintah itu. Hook ini menerima perintah yang terdeteksi lewat variabel lingkungan RESURRECT_COMMAND dan mengembalikan versi yang ingin dijalankan — detail kecil yang menghindarkan tim dari kejutan saat session dihidupkan kembali di mesin orang lain.

#Kesalahan Umum (Common Pitfalls)

1. Menyimpan path absolut personal di config bersama. Layout dengan cwd="/home/arman/project" akan rusak di mesin lain. Solusi: pakai environment variable atau layout per-project, bukan path hardcode.
2. Symlink putus setelah clone di lokasi berbeda. Script bootstrap yang mengasumsikan repo selalu di ~/dotfiles gagal di mesin lain. Solusi: hitung path repo relatif terhadap lokasi script ($(dirname "$0")).
3. Mengabaikan perbedaan copy_command. Paste bekerja di Linux tetapi tidak di macOS/Windows. Solusi: sesuaikan copy_command per platform di script bootstrap.
4. Session tidak muncul setelah reboot. Kalian lupa session_serialization true, atau mengubahnya tanpa restart Zellij. Solusi: set session_serialization true, restart, lalu uji resurrect.
5. Secret bocor ke repo. API key atau token tertulis di config.kdl. Solusi: selalu pakai environment variable untuk secret, dan jangan pernah meng-commit file yang mengandung nilai sensitif.

#Penutup

Episode 27 ini menutup bab portability: konfigurasi Zellij kini hidup di repo dotfiles, ter-deploy lewat bootstrap script yang menangani perbedaan platform, dan diverifikasi dengan zellij setup --check. Session persistence otomatis memastikan workspace bertahan dari reboot, prinsip keamanan menjaga konfigurasi tetap deterministik, dan standardisasi workflow membuat seluruh tim bisa berangkat dari titik awal yang sama.

Poin yang harus kalian bawa:

• ~/.config/zellij/ — config, layout, theme, plugin — layak masuk repo dotfiles.
• Bootstrap script harus menangani instalasi, penautan, dan verifikasi sekaligus.
• ZELLIJ_CONFIG_DIR menyatukan lokasi konfigurasi lintas Linux, macOS, dan Windows.
• session_serialization dan serialize_pane_viewport membuat session bertahan dari reboot.
• Config yang dibagikan harus bebas secret dan bebas path absolut personal.

Di episode 28, episode terakhir series ini, kita memandang Zellij dari ketinggian: perbandingan jujur Zellij melawan tmux dan GNU Screen, kapan memakai yang mana, panduan migrasi dari tmux dengan Tmux mode, rekap lengkap perjalanan dari episode 0 sampai 27, dan checklist daily-driver untuk membangun muscle memory. Sampai jumpa di episode 28 — episode penutup!