Skip to content

1.1-plan.md

Latest commit

 

History

History
100 lines (74 loc) · 4.27 KB

1.1-plan.md

File metadata and controls

100 lines (74 loc) · 4.27 KB
title Generate Integration Plan
description Choose the correct SDK based on detected stack and generate a minimal integration plan

Generate Integration Plan

Based on what you detected in the previous step, choose the right SDK and plan the minimal set of changes needed.

Choose the Right SDK

Use the SDK Recipes reference to match the detected stack to an SDK. The key decision:

Project Type SDK Type Key Type
Backend API, server-rendered app, CLI tool Server-side SDK SDK Key
Browser SPA (React, Vue, Angular, vanilla JS) Client-side SDK Client-side ID
iOS or Android native app Mobile SDK Mobile Key
React Native, Flutter Mobile SDK Mobile Key
Electron desktop app Client-side SDK (Node.js) Client-side ID
Cloudflare Workers, Vercel Edge, AWS Lambda@Edge Edge SDK SDK Key
.NET client (MAUI, Xamarin, WPF, UWP) Client-side SDK (.NET) Mobile Key
C/C++ client application Client-side SDK (C/C++) Mobile Key
C/C++ server application Server-side SDK (C/C++) SDK Key
Haskell server Server-side SDK (Haskell) SDK Key
Lua server Server-side SDK (Lua) SDK Key
Roku (BrightScript) Client-side SDK (Roku) Mobile Key

For a complete list of SDKs, see:

Important distinctions:

  • Next.js: Use server-side SDK for API routes/server components, React client SDK for client components. Start with whichever matches the user's primary use case.
  • Node.js: If it's a backend service (Express, Fastify, etc.), use the server-side SDK. There is also a Node.js client SDK for desktop/Electron apps.
  • React: If it's a standalone SPA, use launchdarkly-react-client-sdk. If it's part of Next.js, see above.
  • .NET: Use the server SDK for ASP.NET/backend services. Use the client SDK for MAUI, Xamarin, WPF, or UWP apps.

Plan the Changes

Your integration plan should identify exactly:

1. Files to Modify

Use the information gathered during the Detect step — specifically the detected package manager, dependency file, and application entrypoint:

  • Dependency file: The file identified during detection (e.g., package.json, requirements.txt, go.mod) — use the detected package manager to add the SDK
  • Entrypoint file: The application entrypoint identified during detection — where SDK initialization code will go
  • Environment/config file: .env, .env.example, or equivalent (for the SDK key) — follow the project's existing configuration pattern

2. Code Changes

For each file, describe the specific change:

  1. Add SDK dependency — the install command from the SDK recipe
  2. Add SDK import — the import statement at the top of the entrypoint
  3. Add SDK initialization — the init code, placed early in the application startup
  4. Configure the SDK key — via environment variable, never hardcoded

3. Environment Variable Convention

Check how the project handles configuration:

  • Does it use .env files? Add LAUNCHDARKLY_SDK_KEY (or LAUNCHDARKLY_CLIENT_SIDE_ID for client SDKs)
  • Does it use a config module? Add the key there
  • Does it read from process.env directly? Follow that pattern

If a .env.example or .env.sample exists, plan to add the variable there too (with a placeholder value).

Present the Plan

Before making any changes, summarize the plan to the user:

Integration Plan:
- SDK: [SDK name] ([server/client/mobile]-side)
- Package: [package name]
- Install: [install command]
- Files to change:
  1. [dependency file] — add SDK dependency
  2. [entrypoint file] — add import and initialization
  3. [env file] — add SDK key variable

Wait for user confirmation before proceeding, especially if:

  • Multiple SDKs could apply (ask which one)
  • The entrypoint is ambiguous (ask which file)
  • The project structure is unusual

Status

[STATUS] Selecting SDK for detected stack
[STATUS] Identifying files to modify
[STATUS] Generating integration plan

Upon completion, continue with: Apply Code Changes