feat(launchdarkly-client): add REST API support for feature flag management

[absarasw]

Summary

• Adds LaunchDarkly REST API support alongside the existing Server SDK, enabling feature flag management (get config, update variations) in addition to flag evaluation
• Introduces apiToken and apiBaseUrl configuration options (backward compatible — existing sdkKey usage is unaffected)
• Adds three new methods: getFeatureFlag, updateFallthroughVariation, and updateVariationValue

New Methods

Method	Description
getFeatureFlag(projectKey, flagKey, environmentKey?)	Fetches flag configuration including variations, targeting rules, and environment-specific settings via REST API
updateFallthroughVariation(projectKey, flagKey, environmentKey, variationId, comment?)	Changes which variation is served as the default (fallthrough) using LaunchDarkly semantic patch
updateVariationValue(projectKey, flagKey, variationIndex, newValue, comment?)	Updates the actual value of a specific variation using JSON Patch

Details

• The client now accepts sdkKey (for flag evaluation via SDK) and/or apiToken (for flag management via REST API) — at least one must be provided
• REST API comments are sent via X-LaunchDarkly-Comment header
• createFrom(context) also reads LD_API_TOKEN and LD_API_BASE_URL from context.env
• URL path parameters are properly encoded via encodeURIComponent
  Please ensure your pull request adheres to the following guidelines:
• make sure to link the related issues in this description
• when merging / squashing, make sure the fixed issue references are visible in the commits, for easy compilation of release notes

Related Issues

Thanks for contributing!

[github-actions]

This PR will trigger a minor release when merged.

[ravverma]

PR #1502 Review — feat(launchdarkly-client): add REST API support

---

Backward Compatibility — ✅ No runtime regressions, 2 type-level breaks

1. LAUNCHDARKLY_SDK_KEY → LD_SDK_KEY in index.d.ts
The old type declared LAUNCHDARKLY_SDK_KEY: string in UniversalContext.env, but the JS on main was already reading LD_SDK_KEY. The type was stale before this PR. This PR corrects it — so the runtime was already "broken" for anyone using the old env var name. Any TypeScript consumer referencing context.env.LAUNCHDARKLY_SDK_KEY by name will now get a type error, but [key: string]: any means it still compiles. Low actual risk — type correction, not regression.

2. sdkKey: string → sdkKey?: string in LaunchDarklyConfig
Expected and intentional. Any TS consumer typed as LaunchDarklyConfig sees a loosened contract but no breakage. No risk.

3. Constructor error message changed
'LaunchDarkly SDK key is required' → 'LaunchDarkly SDK key or API token is required'. Any test or code asserting on the exact string needs updating. Minor.

4. init() guard is better, not a regression
Previously, passing only apiToken (no sdkKey) and calling init() would fail inside the LD SDK in an opaque way. Now it throws a clear Error immediately. Improvement.

---

Burst Request Risk to LaunchDarkly — ⚠️ Medium risk

The three new methods (getFeatureFlag, updateFallthroughVariation, updateVariationValue) make raw fetch() calls with no rate limiting, no caching, no retry/backoff, and no request queuing:

Risk	Detail
getFeatureFlag in hot path	If callers use this for per-request flag reads instead of the SDK, every Lambda invocation fires a REST call to LD. At scale this easily bursts LD's rate limit (100–1000 req/min depending on plan). The SDK has a streaming cache; this has none.
Batch write loops	updateFallthroughVariation/updateVariationValue called in a loop (e.g. a migration script over many flags) will generate a burst of write requests with no throttling.
No 429 handling	LD rate-limit errors are thrown immediately and lost — no backoff/retry. Callers get a raw error with no guidance.

However, the intended use case is flag management (admin/script operations), not per-request evaluation. Burst risk is low if used as intended, medium if getFeatureFlag gets used in request handlers.

Missing safeguard: A JSDoc warning on getFeatureFlag against using it in hot paths (use the SDK variation() instead).

---

Verdict — ✅ Approvable with one recommendation

No runtime breaking changes. The backward compatibility concerns are type-definition corrections aligning types with existing runtime behavior. The burst risk is real but acceptable for the intended use case of admin flag management.

Recommended before merge:
Add a @remarks or @warning note to getFeatureFlag's JSDoc explicitly stating it should not be called per-request — callers should use variation() (SDK) for flag evaluation. This prevents the most likely misuse that would cause LD rate-limit bursts.

[solaris007]

🎉 This PR is included in version @adobe/spacecat-shared-launchdarkly-client-v1.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀