chore(setup): add SDK/project detection library

[ffantl-ld]

Describe the solution you've provided

First layer of the guided setup command: the internal/setup detection library. Inspects a project directory and identifies the language/package manager and the most likely LaunchDarkly SDK (Detector interface, FileDetector, KnownSDKs).

Pure library with no consumer yet — the setup command wires it up later in this stack.

Related issues

Part of the setup-ld feature. Stacked PR — base is setup-ld.

Requirements

• I have added test coverage for new or changed functionality

---

Note

Low Risk
New library-only code with no CLI integration yet; heuristics may mis-detect polyglot repos but failures are overridable via --sdk-id.

Overview
Adds internal/setup, a filesystem-based project detector for the upcoming guided ldcli setup flow. FileDetector scans a directory and returns language, framework, package manager, recommended LaunchDarkly sdk_id, and an entry-point path, with EntryPointExists so callers only auto-edit files that actually exist.

Detection runs Go → Python → Ruby → Java → Swift → .NET → Node so backend manifests win over a root package.json used only for asset tooling. Node logic distinguishes Next.js (server SDK + instrumentation.ts), React Native, React, other browser frameworks, and generic Node; lockfiles drive npm/yarn/pnpm/bun. KnownSDKs lists manual override options when detection fails.

Heavy test coverage includes table-driven project shapes and edge cases (Next.js instrumentation vs pages, Android MainActivity search, ambiguous Go/Swift multi-binary layouts).

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

[ffantl-ld]

"could not detect project language from directory")

Should probably mean "Hey, here's a link to the docs and a blurb about how to do this install manually"

If we're doing a hybrid approach to setup, then we should definitely

[erangeles]

@ffantl-ld there is some valid bug bot issues flagged, wanted to make sure you were aware of them (either to fix now or punt on)

[erangeles]

suggestion: we should return whether the entry point actually exists so downstream steps can prompt the user instead

type DetectResult struct {
      // ...
      EntryPoint       string `json:"entry_point"`
      EntryPointExists bool   `json:"entry_point_exists"`
}

// firstExistingIn returns the first candidate that exists in dir and true,
// or the last candidate and false as a suggestion if none exist.
func firstExistingIn(dir string, candidates []string) (string, bool) {
      if len(candidates) == 0 {
              return "", false
      }
      for _, c := range candidates {
              if _, err := os.Stat(filepath.Join(dir, c)); err == nil {
                      return c, true
              }
      }
      return candidates[len(candidates)-1], false
}

Then the wizard can branch: exists → inject; doesn't → ask the user for the entry file (or show the snippet).

[ffantl-ld]

DetectResult now carries EntryPointExists. Good find. :)

[erangeles]

@ffantl-ld bump, just wanted to make sure you saw my earlier comments

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

^{❌ 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 0b61639. Configure here.}

[cursor]

Java entry search too narrow

Medium Severity

Java server entry detection only accepts exact Main.java, Application.java, or App.java under src/main/java. Typical Spring Boot apps use names like DemoApplication.java, and Kotlin JVM apps live under src/main/kotlin with .kt files. findFileUnder already supports suffix patterns (used for Swift), so these common entry points are missed and EntryPointExists stays false.

 

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