[REL-13574] Implement SDK detection and installation by dakotasanchez · Pull Request #709 · launchdarkly/ldcli

dakotasanchez · 2026-05-12T22:26:27Z

Summary

Implements the Detector and Installer interfaces that were stubbed in the base branch, wiring up real filesystem-based SDK detection and package-manager-based installation into the ldcli setup wizard and hidden subcommands.

FileDetector — scans the working directory for project indicators and returns language, framework, package manager, recommended SDK ID, and entry point file
PackageInstaller — maps SDK IDs to their install commands and shells out to the appropriate package manager
APIClients gains Detector and Installer fields for test injection, with FileDetector/PackageInstaller as production defaults
Fixed install.go output: Package: pkg@version was printing a trailing @ when Version is empty
Fixed cmd/root.go import ordering (gofmt)
Manual-install SDKs (Java, Android, Swift) now return meaningful package identifiers (com.launchdarkly:launchdarkly-java-server-sdk etc.) rather than the raw SDK ID

How SDK Detection and Installation Work

Detection (`FileDetector`)

FileDetector.Detect(dir) runs four probes in priority order against the project directory:

Node.js / React / Next.js — reads package.json and inspects dependencies + devDependencies:
- Has next → node-server SDK, framework = "Next.js"
- Has react → react-client-sdk, framework = "React"
- Otherwise → node-server (plain Node)
- Package manager inferred from lock files: pnpm-lock.yaml → pnpm, yarn.lock → yarn, default → npm
Go — presence of go.mod → go-server-sdk
Python — presence of requirements.txt, pyproject.toml, or setup.py → python-server-sdk
Java — presence of pom.xml (→ mvn) or build.gradle/build.gradle.kts (→ gradle) → java-server-sdk

If nothing matches, returns an error; the wizard surfaces it and halts.

Entry point detection walks a prioritized candidate list per SDK (e.g. for React: src/App.tsx → src/App.jsx → src/index.tsx → ... → index.js) and returns the first path that exists on disk, or the last candidate as a suggested path if none do. The returned path is absolute and passed directly to Initializer.InjectIntoFile.

Installation (`PackageInstaller`)

PackageInstaller.Install(dir, detectResult) calls InstallArgs(sdkID, packageManager) which maps each SDK to its install command:

SDK	Command
`react-client-sdk`	`npm/yarn/pnpm install launchdarkly-react-client-sdk`
`node-server`	`npm/yarn/pnpm install @launchdarkly/node-server-sdk`
`python-server-sdk`	`pip install launchdarkly-server-sdk`
`go-server-sdk`	`go get github.com/launchdarkly/go-server-sdk/v7`
`ruby-server-sdk`	`gem install launchdarkly-server-sdk`
`dotnet-server-sdk`	`dotnet add package LaunchDarkly.ServerSdk`
Java / Android / Swift	no command — `Success: false`, no error

For SDKs with a command, it shells out via exec.Command in the project directory and captures combined output. A non-zero exit wraps the error and output into the returned error. For SDKs without a command, it returns Success: false with no error so the wizard proceeds (the user still needs to add the dependency manually, but flag creation and code injection remain valid).

Wizard Integration

selectProject → selectEnvironment → fetchEnvDetails
                                          │
                                          ▼
                                      stepDetect  ←── FileDetector.Detect(cwd)
                                          │              → SDKID, PackageManager, EntryPoint
                                          ▼
                                      stepInstall ←── PackageInstaller.Install(cwd, detectResult)
                                          │              → shells out: npm install / go get / pip install / ...
                                          ▼
                                      stepCreateFlag → stepInit → stepWaitForApp → stepVerify → stepDone

detectResult.SDKID flows into both the installer (command selection) and the initializer (template selection). detectResult.EntryPoint is passed directly to InjectIntoFile. All five SDKs the detector can return have init templates, so the stepWaitForApp file path display is always valid.

Test plan

Requirements

I have added test coverage for new or changed functionality
I have followed the repository's pull request submission guidelines
I have validated my changes against all supported platform versions

Note

Medium Risk
Adds real project detection and shells out to system package managers during ldcli setup, which can affect local environments and error handling. Wizard flow changes (manual SDK selection fallback) introduce new state transitions but are covered by tests.

Overview
ldcli setup now uses real implementations for SDK detection and installation: a new filesystem-based FileDetector infers language/framework/package manager/entry point from common project files, and PackageInstaller maps SDK IDs to install commands and runs them via the system package manager.

The setup wizard flow changes to always present an SDK selection step, prioritizing the detected SDK but allowing override (and falling back to manual selection when detection fails), and APIClients gains injectable Detector/Installer with production defaults wired in cmd/root.go. Output and template handling were tightened (avoid trailing @ when version is empty; align Android template ID to android-client-sdk; adjust Go template import guidance), with extensive new/updated tests for detection, install command selection/execution, and wizard transitions.

^{Reviewed by Cursor Bugbot for commit f60f9d1. Bugbot is set up for automated code reviews on this repo. Configure here.}

ari-launchdarkly

This is really great work. I've got questions around whether we can make this a little more deterministic around some of the edges if we're leaning away from an agent to determine some of the dependencies. If it's not abundantly obvious for us, we can also punt on that

ari-launchdarkly · 2026-05-13T11:41:43Z

+	if _, ok := allDeps["next"]; ok {
+		return &DetectResult{
+			Language:       "JavaScript",
+			Framework:      "Next.js",
+			PackageManager: pm,
+			SDKID:          "node-server",
+			EntryPoint: filepath.Join(dir, firstExistingIn(dir, []string{
+				"src/index.ts", "src/index.js",
+				"pages/index.tsx", "pages/index.ts", "pages/index.js",
+				"index.js",
+			})),
+		}
+	}
+
+	if _, ok := allDeps["react"]; ok {
+		return &DetectResult{
+			Language:       "JavaScript",
+			Framework:      "React",
+			PackageManager: pm,
+			SDKID:          "react-client-sdk",
+			EntryPoint: filepath.Join(dir, firstExistingIn(dir, []string{
+				"src/App.tsx", "src/App.jsx", "src/App.js",
+				"src/index.tsx", "src/index.jsx", "src/index.js",
+				"index.js",
+			})),
+		}
+	}


can we flesh these out to account for the:

https://launchdarkly.com/docs/sdk/client-side/javascript
https://launchdarkly.com/docs/sdk/client-side/react/react-native

It's pretty tough to detect just plain JS with no framework, so maybe the SDK selector can just take care of that case.

Maybe. I think we can try and detect some of those based on known active frameworks. I think I put in the suggestion downstream

Here's what we're doing now:

Has next dep → node-server

Has react-native dep → react-native

Has react dep → react-client-sdk

Has backbone/svelte/vue/angular/ember/preact dep → js-client-sdk

Fallback: anything else with a package.json → node-server

ari-launchdarkly · 2026-05-13T12:00:32Z

+	case "android", "android-client-sdk":
+		return nil, "com.launchdarkly:launchdarkly-android-client-sdk"


for this, the android SDK has a couple different ways of setting it depending on whether the user is using Kotlin or Groovy:

https://launchdarkly.com/docs/sdk/client-side/android#install-the-sdk

Is there a way for us to account for the package here?

We're accounting for Kotlin vs. Groovy, but we should surface to the user that they need to add the implementation 'com.launchdarkly:launchdarkly-android-client-sdk:5.+' to their build file. Unless we want to inject code here as well?

ari-launchdarkly · 2026-05-13T12:01:35Z

+	case "java-server-sdk":
+		return nil, "com.launchdarkly:launchdarkly-java-server-sdk"


for this, the docs point to us having a way to do this in XML and Gradle:

https://launchdarkly.com/docs/sdk/server-side/java#install-the-sdk

Is that something we'd want to be deterministic about?

We're deterministic about this detection, but we still are prompting the user to copy/paste a snippet for Gradle/Maven, since there's no shell command to import the LD SDK like with the other languages.

Co-authored-by: ari-launchdarkly <asalem@launchdarkly.com>

cursor

Cursor Bugbot has reviewed your changes using default mode 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 f60f9d1. Configure here.}

cursor · 2026-05-13T19:53:34Z

+		m.detectedEntryPoint = msg.result.EntryPoint
+		m.sdkList = m.buildSDKList(msg.result.SDKID)
+		m.step = stepSelectSDK
+		return m, nil


Detected package manager discarded during SDK selection

High Severity

The detectDoneMsg handler stores EntryPoint in m.detectedEntryPoint but discards PackageManager. When the user confirms SDK selection in handleEnter, the new DetectResult is constructed without PackageManager, leaving it as an empty string. This causes InstallArgs → resolveNodePM("") to always default to "npm", even when the detector correctly identified yarn, pnpm, or bun from lock files. The installer will run the wrong package manager command (e.g. npm install in a pnpm project).

Additional Locations (1)

cmd/setup/wizard.go#L288-L293

^{Reviewed by Cursor Bugbot for commit f60f9d1. Configure here.}

cursor Bot reviewed May 12, 2026

View reviewed changes

Comment thread internal/setup/detector.go Outdated

ari-launchdarkly requested changes May 13, 2026

View reviewed changes

cursor Bot reviewed May 13, 2026

View reviewed changes

Comment thread internal/setup/detector.go

Comment thread internal/setup/detector.go Outdated

Comment thread internal/setup/detector.go Outdated

dakotasanchez and others added 6 commits May 13, 2026 12:08

[REL-13574] sdk detection and installation

cfef17f

Update internal/setup/detector.go

ba12783

Co-authored-by: ari-launchdarkly <asalem@launchdarkly.com>

Update internal/setup/detector.go

4c9be74

Co-authored-by: ari-launchdarkly <asalem@launchdarkly.com>

Update internal/setup/installer.go

e5bcd58

Co-authored-by: ari-launchdarkly <asalem@launchdarkly.com>

Update internal/setup/installer.go

6499ab4

Co-authored-by: ari-launchdarkly <asalem@launchdarkly.com>

[REL-13574] feedback

2e055cf

dakotasanchez force-pushed the dsanchez/REL-13574/cli branch from 71c2501 to 2e055cf Compare May 13, 2026 19:09

cursor Bot reviewed May 13, 2026

View reviewed changes

Comment thread cmd/setup/wizard.go

Comment thread internal/setup/detector.go

dakotasanchez added 2 commits May 13, 2026 12:19

[REL-13574] change to always show (prioritized) SDK selector

2e896c6

[REL-13574] lingering bugs

f60f9d1

cursor Bot reviewed May 13, 2026

View reviewed changes

		case "android", "android-client-sdk":
		return nil, "com.launchdarkly:launchdarkly-android-client-sdk"

		case "java-server-sdk":
		return nil, "com.launchdarkly:launchdarkly-java-server-sdk"

Conversation

dakotasanchez commented May 12, 2026 • edited by cursor Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

How SDK Detection and Installation Work

Detection (FileDetector)

Installation (PackageInstaller)

Wizard Integration

Test plan

Uh oh!

Uh oh!

ari-launchdarkly left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cursor Bot May 13, 2026

Choose a reason for hiding this comment

Detected package manager discarded during SDK selection

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dakotasanchez commented May 12, 2026 •

edited by cursor Bot

Loading

Detection (`FileDetector`)

Installation (`PackageInstaller`)