Global or local CLI? Three tools changed my rule

I used to install CLIs globally because typing the command directly was convenient. After too many problems building mobile apps, I reconsidered that habit. More recently, a coworker showed me that a global install could still be useful. Then I found tools designed to support both global and local installs. These three examples changed how I choose between them.

Capacitor taught me to keep the CLI local

Years ago, I used globally installed tools such as Capacitor’s cap across multiple projects. It was simply more convenient. As the apps and their dependencies changed, I ran into more problems with those global installations, which slowed development down.

I discovered npx and started keeping the Capacitor CLI in each project, running it with npx cap. The command stayed short, and each project used its own CLI version. A little extra typing was well worth it.

Nx showed me a useful global shortcut

More recently, I was using npx nx because I thought I needed the prefix to run the workspace’s version. A coworker typed nx directly. That was news to me: the global Nx command hands control to the version installed in the workspace. I wish I’d known earlier. I could have shortened the colossal pnpm run nx run project:... commands I was typing.

Just remember to update the global nx from time to time. If it gets too old, it may forget how to find a newer workspace.

Appium lets me choose what to share

The Nx discovery made me curious about other CLIs. While working with Appium, I found that it handled both shared and project-local setups well.

I can use a globally installed appium command for a shared setup. APPIUM_HOME points to the directory containing my drivers and plugins, so I can switch between sets by changing that environment variable. Configuration for a particular project can live in .appiumrc.json or package.json. This gives me a clear way to choose what stays with the project and what I share across projects.

Global, local, or both?

I no longer use one rule for every CLI. For a command I use only occasionally, I install it in the project and move on. There is little reason to spend time on a global shortcut I rarely use.

For commands I run often, I look up how the tool handles global and local installations. Does the global command run its own version, hand off to the project’s version, or offer a useful shared setup? Then I decide whether a global install saves enough typing or repeated setup across my projects to justify using it. Local remains my default.

Try it with another developer

Use history to pick a few commands and compare them with another developer. If you invoke the same tool differently, discuss why, even if one of you just thinks npm rum sounds more like a pirate.