Skip to content

Decoupling Your IDE from Orchestration Scripts

Why hardcoding nvim in your dev.sh or Makefile is an anti-pattern.

When building full-stack applications, orchestrating multiple background processes (like a backend server, frontend watcher, and a documentation server) is essential. Tools like tmux and make are fantastic for this.

However, a common mistake is hijacking the developer's window by forcing a specific Integrated Development Environment (IDE) to open as part of the orchestration.

The Problem

If your dev.sh includes lines like: 

tmux new-window -t $SESSION -n "Nvim"
tmux send-keys -t $SESSION:Nvim "nvim ." C-m
You are making a massive assumption: Every developer on your team uses Neovim.

If a new developer prefers VS Code, IntelliJ, or Emacs, running make dev will either crash, open an unwanted program, or break their existing terminal workflow. This creates friction and ruins the onboarding experience.

The Solution

Orchestration scripts should only manage infrastructure, not user preferences.

Instead of launching the IDE, your dev.sh should simply launch the necessary dev servers (FastAPI, Tailwind Watcher, MkDocs) and leave the user in a safe, generic "Main" terminal window. The developer is then free to open the project in their preferred editor externally.

Best Practices for DevX Scripts:

  1. Be Agnostic: Never assume the developer's OS (beyond POSIX standards) or IDE.
  2. Fail Gracefully: Use || true on shutdown commands so missing processes don't crash the teardown script.
  3. Respect the $EDITOR Variable: If you absolutely must open a file programmatically from a script, use the user's $EDITOR environment variable instead of hardcoding vim or nano.