Add envs to ldcli config, replacing flags-usage's static env fallback#743
Add envs to ldcli config, replacing flags-usage's static env fallback#743davidbrackbill wants to merge 1 commit into
Conversation
Adds `envs` as a real config field (Config.Envs, cliflags.EnvsFlag), following the exact pattern already used for project/environment/ access-token: settable via `ldcli config --set envs=a,b,c`, and resolved through the standard flag -> LD_ENVS env var -> config file precedence via viper.BindPFlag (the --envs flag on `flags usage` wasn't wired through viper before this). When none of flag/env/config set anything, `flags usage` now falls back to live-discovering the project's critical environments via the LD API (ported from flagpls's `setup` wizard) instead of a hardcoded generic env list — the hardcoded list didn't match most projects' real critical envs, which is what caused the nvim/vscode plugin swap to render blank tables when they omit -envs (matching flagpls's own default behavior).
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 82aa923. Configure here.
| fmt.Fprintf(cmd.ErrOrStderr(), "warning: couldn't auto-discover critical environments (%v); pass --envs explicitly\n", err) | ||
| } | ||
| envs = discovered | ||
| } |
There was a problem hiding this comment.
Silent default env resolution change
Medium Severity
Omitting --envs now live-discovers critical environments via the API instead of relying on the prior implicit DefaultCriticalEnvs behavior, changing which environments appear in flags usage output. The command only prints a stderr notice when discovery fails, not when the default resolution path changes on success.
Triggered by learned rule: Breaking CLI default changes require transitional stderr warnings
Reviewed by Cursor Bugbot for commit 82aa923. Configure here.


Summary
envsas a real ldcli config field (Config.Envs,cliflags.EnvsFlag), following the exact pattern already used forproject/environment/access-token: settable vialdcli config --set envs=a,b,c, resolved through the standard flag →LD_ENVSenv var → config file precedence viaviper.BindPFlag(the--envsflag onflags usagewasn't wired through viper before this).flags usagenow falls back to live-discovering the project's critical environments via the LD API (ported from flagpls'ssetupwizard) instead of a hardcoded generic env list — the hardcoded list didn't match most projects' real critical envs, which caused blank tables when omitting-envs(matching flagpls's own default behavior, used by its nvim/vscode plugin integrations).Stacked on top of #742.
Test plan
go build ./...andgo test ./...pass (including a golden-file update forldcli config --help)-envs) now live-discovers critical envs instead of returning a blank tableldcli config --set envs=...persists as a real YAML list, and is picked up byflags usageldcli config --unset envscleans up correctlyClaude claude@anthropic.com
Note
Medium Risk
Changes default behavior for
flags usagewhen--envsis omitted (now an API call and different env set), and adds outbound REST calls using the user's access token.Overview
Adds a first-class
envsconfig key (persisted as a YAML list vialdcli config --set envs=a,b,c) and wiresflags usageto resolve environments through--envs→LD_ENVS→ config via viper, replacing the local-only--envsstring flag.When nothing is configured,
flags usagenow auto-discovers the project’s critical environments by calling the LaunchDarkly REST API (fetchCriticalEnvs) instead of relying on a static default—so editor/plugin flows that omit--envsget meaningful per-env columns. Discovery failures emit a warning and the command can continue with an empty env list.Config help/golden text is updated to document
envs.Reviewed by Cursor Bugbot for commit 82aa923. Bugbot is set up for automated code reviews on this repo. Configure here.