Best practices for using Gum in internal tooling (without adding friction to dev setup)

[emiliosheinz]

Hi there 👋

First off, thanks for building Gum — it’s an awesome tool that makes CLI menus and prompts feel so much more polished!

I recently tried to use Gum in an internal tool at work. The functionality works fine without Gum, but adding it makes the UX much nicer and friendlier. The main concern raised in code review, though, was that Gum adds an OS-dependent binary dependency. Some colleagues prefer avoiding that in order to keep the dev setup as simple as possible, especially for internal tools.

• How do people typically use Gum in team environments where you don’t want to force every developer to install extra binaries?

• Are there recommended approaches for packaging or distributing Gum along with tooling (e.g., via Docker, Nix, Homebrew, etc.)?

• Is “optional enhancement” a common pattern, where Gum makes the UX nicer but the tool falls back to a simpler menu if it’s not available?

Any advice or examples of how others handle this would be super helpful. Thanks again for creating Gum!

[meleu]

I'm also interested in this topic. And my initial motivation is slightly different than yours...

Turns out that I've created a powerful script bash CLI application that I would like to use in a pipeline. As the pipeline is non-interactive, it doesn't need all the 💅 glamour 🎀 provided by gum.

I'm still thinking on how to approach this issue. Let's see what others has to say...

(by the way: if you are interested in an easy way to create robust and professional looking bash programs, take a look at https://bashly.dev/)