DEV Community: Krishan Sharma

Why LaunchDarkly OpenFeature Migrations Break in Production

Krishan Sharma — Sun, 28 Jun 2026 20:40:51 +0000

LaunchDarkly and OpenFeature both evaluate flags with three arguments, but the
fallback and context positions are reversed. A naive codemod can produce
valid-looking code that silently changes runtime behavior.

This article shows the argument-order trap and why FlagLint uses AST analysis
before rewriting any call site.

The Agreement That Takes 30 Minutes

Teams agree on OpenFeature quickly. It makes sense — vendor-neutral,
CNCF-backed, clean abstraction. The decision is easy.

The migration is not.

Halfway through, most teams hit a bug that looks like this in production:
a subset of users sees the wrong feature state. The flag evaluation
is returning unexpected values. Everything looked correct in code review.

The cause is almost always the same thing.

The Argument-Order Trap

LaunchDarkly and OpenFeature share method names but differ in argument order:

// LaunchDarkly
ldClient.boolVariation(flagKey, context, fallback)

// OpenFeature  
openFeatureClient.getBooleanValue(flagKey, fallback, context)

context and fallback are swapped.

A search-and-replace migration silently puts context where fallback
should be, and fallback where context should be — across every call
site in your codebase.

In production: users in your evaluation context see the fallback value.
In code review: the signature looks correct because the argument count matches.
In the post-mortem: nobody can identify when it was introduced.

Why Grep Misses It

The typical manual approach:

Search for launchdarkly-node-server-sdk imports
Find all ldClient references
Search-and-replace method names

This finds the calls. It does not understand argument semantics.

A grep-based migration will correctly rename boolVariation to
getBooleanValue and miss the argument order entirely. The test suite
often misses it too because the values are both valid types — context
and fallback are both objects.

What AST Analysis Catches

Abstract Syntax Tree (AST) analysis parses your code the same way a
compiler does. It doesn't match text — it understands structure.

For a call like:

const result = await ldClient.boolVariation('checkout-v2', ctx, false);

AST analysis identifies:

The import binding (ldClient → launchdarkly-node-server-sdk)
The method name (boolVariation)
The argument at position 0: flag key ('checkout-v2' — string literal)
The argument at position 1: context (ctx — object reference)
The argument at position 2: fallback (false — boolean literal)

When generating the OpenFeature equivalent, it knows to produce:

const result = await openFeatureClient.getBooleanValue('checkout-v2', false, ctx);

Argument 2 goes to position 1. Argument 1 goes to position 2.
Argument order corrected. Type preserved. Await preserved.

When AST Analysis Refuses to Rewrite

Not every call can be safely automated. FlagLint identifies these
and routes them to manual review instead of silently rewriting them:

Dynamic flag keys:

const flagKey = `feature-${featureName}`;
await ldClient.boolVariation(flagKey, ctx, false);

The key is not statically knowable. Automated rewrite could produce
incorrect OpenFeature client binding.

Detail methods:

await ldClient.boolVariationDetail('checkout-v2', ctx, false);

boolVariationDetail returns metadata not directly equivalent in
OpenFeature. Requires a different migration pattern.

Bulk state calls:

await ldClient.allFlagsState(ctx);

No direct OpenFeature equivalent. Architecture decision required.

For all of these, FlagLint reports the location and reason —
it never silently rewrites them.

The CI Gate

Generating diffs is only half the problem. Migration rot is the other half.

After a phased migration, new engineers joining the codebase don't
know the rule. They reach for ldClient because that's what they know.
Six months later, you have new direct LD calls and the migration has
partially reversed.

flaglint validate --no-direct-launchdarkly exits 1 if any direct
LaunchDarkly evaluation call appears outside the bootstrap file.

Add it to your GitHub Actions workflow:

- name: Enforce OpenFeature boundary
  run: npx flaglint@latest validate ./src --no-direct-launchdarkly

Any new ldClient.boolVariation() call fails the build. The boundary holds.

Try It Now

npx flaglint audit ./src

Runs locally, no SDK key needed, nothing changes. Gives you a risk-ranked
inventory of every direct LaunchDarkly SDK call in your codebase —
dynamic keys, detail methods, and bulk state calls included — with a
migration readiness score.

npx flaglint migrate ./src --dry-run

Shows the before/after diff for every safely automatable call site.
Dynamic keys and detail methods are reported separately for manual review.

FlagLint is free, open source, MIT licensed.

→ GitHub

→ npm

→ Quickstart

Originally published at flaglint.dev

Five LaunchDarkly SDK Patterns That Block Automatic Migration to OpenFeature

Krishan Sharma — Sun, 28 Jun 2026 20:40:27 +0000

Run flaglint migrate ./src --dry-run and you will see two kinds of results: call
sites with a generated diff and call sites marked skip — manual review required.
The skipped calls are not bugs in the tool. They are patterns where a mechanical
rewrite would change runtime behavior in ways the tool cannot prove are safe.

This article covers the five patterns that produce skips and what you need to do for each.

What makes a call automatable

FlagLint rewrites a call automatically only when it can prove three things:

The flag key is a static string literal.
The fallback value type is known (boolean, string, number, or json).
A verified OpenFeature client binding is present in scope.

If any proof fails, the call is left unchanged and flagged for manual review. The
conservative stance is intentional: a wrong rewrite is worse than no rewrite.

Pattern 1 — Dynamic flag keys

What it looks like:

// key comes from a variable
const key = user.experimentGroup === 'A' ? 'checkout-v2' : 'checkout-v1';
const enabled = await ldClient.boolVariation(key, ctx, false);

// key comes from a function call
const discount = await ldClient.numberVariation(getFlagKey(user.tier), ctx, 0);

// key is assembled at runtime
const variant = await ldClient.stringVariation(`feature-${region}-rollout`, ctx, 'control');

Why it blocks migration:

OpenFeature's evaluation methods are structurally identical to LaunchDarkly's for
this case — both take (key, defaultValue, context). But if the key is dynamic,
FlagLint cannot know which flag is being evaluated, which means it cannot verify
that the OpenFeature provider has that flag configured, cannot determine the correct
return type, and cannot guarantee the fallback default is the right type for that
specific flag.

How to resolve:

Extract the dynamic selection into an explicit switch or map, then call evaluation
with a known static key per branch:

// Before
const discount = await ldClient.numberVariation(getFlagKey(user.tier), ctx, 0);

// After
const FLAG_BY_TIER: Record<string, string> = {
  free: 'discount-free-tier',
  pro: 'discount-pro-tier',
  enterprise: 'discount-enterprise-tier',
};
const flagKey = FLAG_BY_TIER[user.tier] ?? 'discount-free-tier';
const discount = await openFeatureClient.getNumberValue(flagKey, 0, ctx);

Once the key is static in each branch, the surrounding calls become automatable in
the next migrate run.

Pattern 2 — Detail evaluations

What it looks like:

const detail = await ldClient.boolVariationDetail('show-banner', ctx, false);
// detail.value — the evaluated value
// detail.reason — WHY it was that value (RULE_MATCH, FALLTHROUGH, etc.)
// detail.variationIndex — index into the flag's variation list

const result = await ldClient.variationDetail('checkout-experiment', ctx, 'control');

Why it blocks migration:

OpenFeature has an equivalent — getBooleanDetails() returns a { value, reason, errorCode } object. But the reason structure is different. LaunchDarkly's
EvaluationReason includes ruleId, ruleIndex, bigSegmentsStatus, and
prerequisiteKey. OpenFeature's ResolutionDetails uses a smaller vocabulary
(CACHED, DEFAULT, ERROR, SPLIT, STATIC, TARGETING_MATCH, UNKNOWN).

Code that consumes detail.reason.kind === 'RULE_MATCH' or detail.reason.ruleId
will need to be updated alongside the evaluation call. FlagLint cannot safely
generate that transformation because the consuming code varies too much.

How to resolve:

Migrate these calls manually. For each variationDetail call:

Replace the evaluation with getBooleanDetails() / getStringDetails() etc.
Update any consumers of reason.kind, reason.ruleId, or variationIndex to use OpenFeature's reason vocabulary.
Add tests that cover the specific reason codes your business logic depends on.

// Before
const detail = await ldClient.boolVariationDetail('show-banner', ctx, false);
if (detail.reason.kind === 'RULE_MATCH') { track('rule-matched'); }

// After
const detail = await openFeatureClient.getBooleanDetails('show-banner', false, ctx);
if (detail.reason === 'TARGETING_MATCH') { track('rule-matched'); }

Pattern 3 — Bulk state calls

What it looks like:

// Server-side bootstrap — sends all flag values to the client
const allFlags = ldClient.allFlags(ctx);
const state = await ldClient.allFlagsState(ctx);

// Common in SSR: inject all flags into the page for client-side hydration
res.locals.flags = ldClient.allFlags(ctx);

Why it blocks migration:

OpenFeature has no equivalent to allFlags() or allFlagsState(). The OpenFeature
specification deliberately does not include bulk evaluation — providers are expected
to surface individual flags, and bulk retrieval is a vendor-specific concern.

The LaunchDarkly OpenFeature provider does not expose allFlags through the
OpenFeature client interface. If your code relies on bulk evaluation to bootstrap a
client-side SDK or build a flag snapshot, that architecture requires rethinking, not
just rewriting.

How to resolve:

Option A — Enumerate the flags explicitly. If you know which flags are needed
at the injection point, evaluate them individually and bundle the results:

const FLAGS_TO_BOOTSTRAP = ['show-banner', 'checkout-v2', 'new-pricing'] as const;

const flagSnapshot = Object.fromEntries(
  await Promise.all(
    FLAGS_TO_BOOTSTRAP.map(async (key) => [
      key,
      await openFeatureClient.getBooleanValue(key, false, ctx),
    ])
  )
);

Option B — Use the LaunchDarkly provider directly for bootstrapping. The
OpenFeature provider wraps the LD Node.js SDK. You can access the underlying client
for the specific bootstrap call while migrating all other evaluation calls to
OpenFeature:

import { LaunchDarklyProvider } from '@launchdarkly/openfeature-node-server';

const provider = new LaunchDarklyProvider(process.env.LD_SDK_KEY!);
await OpenFeature.setProviderAndWait(provider);

// Access the underlying LD client only for bulk bootstrap
const ldClient = (provider as any).getClient(); // type-cast needed; provider internals are not public API
const allFlags = ldClient.allFlags(ctx);

Option B is a transitional pattern. The goal is to eliminate it once you've
enumerated the flags that actually need bootstrapping.

Pattern 4 — Configured wrappers

What it looks like:

// A shared evaluation helper used across services
export function isFeatureEnabled(flagKey: string, ctx: LDContext): Promise<boolean> {
  return ldClient.boolVariation(flagKey, ctx, false);
}

// Custom wrapper that adds logging and metrics
export async function evaluateFlag<T>(key: string, ctx: LDContext, fallback: T): Promise<T> {
  const result = await ldClient.variation(key, ctx, fallback);
  metrics.record('flag.evaluation', { key, result });
  return result as T;
}

Why it blocks migration:

FlagLint detects wrappers configured in .flaglintrc under the wrappers key.
When a wrapper is detected, the call is surfaced in the audit and scan output but
never auto-rewritten — because rewriting the call site does not solve the problem.
The wrapper itself contains the direct LD SDK call that needs to change.

How to resolve:

Migrate the wrapper implementation, not the call sites. The call sites stay the same;
only the internals of the wrapper change:

// Before
export function isFeatureEnabled(flagKey: string, ctx: LDContext): Promise<boolean> {
  return ldClient.boolVariation(flagKey, ctx, false);
}

// After — wrapper now delegates to OpenFeature
export function isFeatureEnabled(flagKey: string, ctx: EvaluationContext): Promise<boolean> {
  return openFeatureClient.getBooleanValue(flagKey, false, ctx);
}

After the wrapper implementation is migrated, configure FlagLint to recognise the
wrapper's result type so downstream scan output is accurate:

{
  "wrappers": ["isFeatureEnabled", "evaluateFlag"]
}

Wrappers that accept a dynamic flagKey parameter will still appear in reports —
that is correct behaviour. The scanner surfaces them for the same reason it surfaces
dynamic keys: it cannot prove which flag is being evaluated.

Pattern 5 — Unknown fallback types (`jsonVariation`)

What it looks like:

// Untyped JSON — fallback type is object but the shape is unknown
const config = await ldClient.jsonVariation('pricing-config', ctx, {});

// Typed JSON with a complex or union shape
const rules = await ldClient.jsonVariation('routing-rules', ctx, { routes: [] });

Why it blocks migration:

OpenFeature's equivalent is getObjectValue(), which returns JsonValue — a union
of string | number | boolean | null | JsonValue[] | { [key: string]: JsonValue }.
When the fallback is {} or another untyped object, FlagLint cannot determine the
correct generic type to use, and it cannot verify that the calling code handles the
JsonValue type correctly rather than a narrower application-specific type.

How to resolve:

Add explicit type annotations to the fallback and the result, then migrate manually:

// Define the expected shape
interface PricingConfig {
  basePrice: number;
  currency: string;
  tiers: { name: string; discount: number }[];
}

const DEFAULT_CONFIG: PricingConfig = { basePrice: 0, currency: 'USD', tiers: [] };

// Before
const config = await ldClient.jsonVariation('pricing-config', ctx, DEFAULT_CONFIG);

// After
const config = await openFeatureClient.getObjectValue(
  'pricing-config',
  DEFAULT_CONFIG,
  ctx
) as PricingConfig;

The explicit cast is safe because the provider returns whatever LaunchDarkly sends,
and the schema is defined in the LaunchDarkly dashboard. If the shape might not
match, add a runtime validator (Zod works well here) at the call site.

Seeing the full breakdown before you start

Before migrating, run flaglint audit ./src to see how many calls fall into each
category and why:

✓ Audit complete: 18 flags — 5 high risk, 13 medium risk

| Flag Key              | Risk   | Usages | Reasons                           |
|-----------------------|--------|--------|-----------------------------------|
| <dynamic key>         | High   | 9      | key cannot be resolved statically |
| checkout-experiment   | High   | 1      | detail evaluation                 |
| *                     | High   | 1      | bulk call                         |
| <wrappers>            | High   | 4      | configured wrapper                |
| pricing-config        | Medium | 1      | json — unknown shape              |
| checkout-v2           | Medium | 1      | safely automatable                |

The five patterns above account for every high-risk category. Resolving them
one at a time — starting with wrappers, then dynamic keys — progressively reduces
the manual review surface until migrate --apply can handle the rest automatically.

Originally published at flaglint.dev

Feature Flag Technical Debt in TypeScript: Find, Measure, and Clear It

Krishan Sharma — Sun, 28 Jun 2026 20:40:16 +0000

TypeScript's type system enforces interface contracts and catches argument-type mismatches at compile time — but it cannot see which of your modules still depend on the LaunchDarkly SDK, which of those call sites can be automatically rewritten, or how many engineer-hours the migration backlog represents.

Feature flag technical debt in TypeScript codebases compounds quietly. A team ships a boolean flag behind ldClient.boolVariation, the rollout succeeds, and the code moves on. Six months later the flag is still evaluated on every request. The surrounding code has grown around it. The LaunchDarkly SDK is a locked-in transitive dependency for the entire module that contains it. And no one has a reliable count of how many of these exist, because the only tool most teams reach for is a grep that conflates static flag keys, wrapper functions, and bulk calls into one undifferentiated list.

FlagLint is a free open-source CLI that parses TypeScript source files using an AST scanner to enumerate every LaunchDarkly SDK call site, classify each one by call type and risk, compute a readiness score, and output a migration plan to OpenFeature. No LaunchDarkly API key required.

Why grep misses TypeScript feature flag technical debt

Running grep -r "ldClient" ./src gives you a count. It does not give you a classification. Every result looks equivalent in grep output, but three structurally different situations hide behind the same pattern:

Static flag key, direct call — the flag key is a string literal; the call type is boolVariation, stringVariation, or numberVariation; the return type is known. FlagLint can generate a safe rewrite for this automatically.
Wrapper function with a dynamic key — the function accepts a flagKey parameter and calls the LaunchDarkly SDK internally. FlagLint cannot statically determine which flag is being evaluated, verify the call type, or confirm the return type. This is a high-risk call type.
Detail evaluation or bulk call — boolVariationDetail and allFlagsState have no direct OpenFeature provider equivalent and cannot be safely transformed by a static rewriter.

All three groups require completely different migration approaches — but grep cannot distinguish them.

Run flaglint scan against your source directory to get the AST-based inventory:

npx flaglint scan ./src

Real output from the enterprise checkout service included with FlagLint (5 source files):

- Scanning examples/enterprise-checkout-service/src/...
✓ 19 flag usages found across 11 unique flags (65ms)
ℹ  1 dynamic flag key(s) require manual review
# FlagLint Scan Report

**Scanned:** 5 files in 65ms
**Flag usages:** 19 across 11 unique flags
**Stale candidates:** 0 flags flagged for review

## Flag Inventory
| Flag Key              | Usages | Files | Call Types                                                 | Status   |
|-----------------------|--------|-------|------------------------------------------------------------|----------|
| (dynamic key)         | 7      | 3     | variationDetail, boolVariation, stringVariation, ...       | ✓ Active |
| checkout-experiment   | 1      | 1     | boolVariationDetail                                        | ✓ Active |
| (dynamic key)         | 1      | 1     | allFlagsState                                              | ✓ Active |
| checkout-v2           | 1      | 1     | boolVariation                                              | ✓ Active |
| payment-provider      | 1      | 1     | stringVariation                                            | ✓ Active |
| one-click-checkout    | 1      | 1     | boolVariation                                              | ✓ Active |
| checkout-currency     | 1      | 1     | stringVariation                                            | ✓ Active |
| discount-percentage   | 1      | 1     | numberVariation                                            | ✓ Active |
| max-discount-amount   | 1      | 1     | numberVariation                                            | ✓ Active |
| discount-config       | 1      | 1     | jsonVariation                                              | ✓ Active |
| pricing-tier-config   | 1      | 1     | jsonVariation                                              | ✓ Active |
| recommendations-variant | 1    | 1     | stringVariation                                            | ✓ Active |
| bulk-discount-enabled | 1      | 1     | boolVariation                                              | ✓ Active |

Seven of the nineteen usages resolve to a dynamic flag key. All seven originate from flags-wrapper.ts, which accepts flagKey as a parameter and proxies calls to the LaunchDarkly SDK. Grep would list those seven as equivalent entries alongside the statically-keyed calls in checkout.ts and pricing.ts. The AST scanner surfaces the wrapper boundary.

Measuring the flag debt

flaglint scan gives you the inventory. flaglint audit adds risk classification, a readiness score, and an optional effort estimate in engineer-hours:

npx flaglint audit examples/enterprise-checkout-service/

Real output:

- Auditing examples/enterprise-checkout-service/...
# FlagLint Audit Report

**Files scanned:** 16
**Duration:** 97ms

## Summary

| Total Flags | High Risk | Medium Risk | Total Usages |
|-------------|-----------|-------------|--------------|
| 13          | 3         | 10          | 27           |

| Dynamic Keys | Detail Evals | Bulk Calls | Stale Signals | Safely Automatable | Manual Review |
|--------------|--------------|------------|---------------|--------------------|---------------|
| 7            | 1            | 1          | 0             | 18                 | 9             |

> **Staleness:** No staleness signals detected. Heuristics checked: keyword match
> (flag key contains old/deprecated/legacy/temp/tmp/test/demo), path pattern
> (test/spec/mock files, deprecated/old/legacy directories), and minFileCount threshold.
> Git-history-based staleness (last evaluation date) requires git metadata and is not
> available in a pure static scan.

## Migration Readiness

Migration readiness: **67/100** · moderate

[█████████████████░░░░░░░░] 67%

18 safely automatable  ·  9 require manual review

The readiness score is the fraction of direct LaunchDarkly SDK call sites that FlagLint can rewrite automatically. A score of 67 means 18 of the 27 call sites are safely transformable. The remaining 9 require a human to resolve before an automated pass can run on those files.

The staleness signal column surfaces flag keys whose names carry heuristic staleness signal — keywords like old, deprecated, legacy, or tmp in the flag key itself. Zero here means no staleness signal at the source level. Staleness detection does not require a LaunchDarkly API key or runtime data.

Add --effort-estimate to convert the count into a planning number:

npx flaglint audit ./src --effort-estimate

This appends a three-phase estimate: automatable call sites at approximately 0.25 engineer-hours each, manual review call sites at 1.5–3 hours each, plus 30% overhead for validation and testing. Supplying --hourly-rate 150 appends a dollar range to the summary. The estimate is a planning heuristic calibrated to call-site complexity, not a billing projection.

The three risk tiers in the flag debt inventory

Every flag key in the audit report lands in one of three tiers:

High risk — cannot be automated:

<dynamic key> (7 usages across 3 files) — the flag key is a runtime variable, not a string literal. FlagLint marks every dynamic flag key as high risk because it cannot statically determine which flag is being evaluated, verify the call type, or confirm the return type. The resolution is to trace back to the call sites that supply the key parameter, then extract each unique flag key to a named constant. Re-running flaglint audit after that change will reclassify the previously-dynamic entries as automatable.

checkout-experiment (1 usage) — boolVariationDetail is a detail evaluation call type. OpenFeature has a getBooleanDetails equivalent, but the reason vocabulary differs: the LaunchDarkly SDK returns TARGETING_MATCH and RULE_MATCH; OpenFeature uses its own reason strings. Code that inspects reason.kind or reason.ruleId must be updated by hand alongside the call site.

* (1 usage) — allFlagsState is a bulk call with no OpenFeature provider equivalent. The resolution is to enumerate the specific flag keys the bulk call feeds and replace them with individual named-key calls. If full flag state at application startup is genuinely required, retain the LaunchDarkly SDK client for that bootstrap path while migrating all other call sites.

Medium risk — automatable with review:

discount-config and pricing-tier-config are jsonVariation call types. They are safely automatable, but OpenFeature's object value API returns unknown. After the rewrite, confirm that any code that casts or destructures the return value still compiles and behaves correctly.

Automatable — safe to transform:

Eight flag keys — checkout-v2, payment-provider, one-click-checkout, checkout-currency, discount-percentage, max-discount-amount, recommendations-variant, and bulk-discount-enabled — are called with boolVariation, stringVariation, or numberVariation using static string literal flag keys. FlagLint can rewrite all of these.

The argument order inversion

The automatable rewrite is not a text substitution. The LaunchDarkly SDK and OpenFeature provider place the fallback value and evaluation context in different argument positions:

// LaunchDarkly SDK — (flagKey, context, fallback)
const enabled = await ldClient.boolVariation("checkout-v2", ctx, false);

// OpenFeature provider — (flagKey, fallback, context)
const enabled = await openFeatureClient.getBooleanValue("checkout-v2", false, ctx);

The flag key is identical. The fallback value and evaluation context swap positions. A naive find-and-replace migration that does not track argument order evaluates every flag with the wrong context on the first request and returns the wrong result silently. FlagLint's AST rewriter moves all three arguments to the correct positions for each automatable call type.

Preview every transformation before any file is touched:

npx flaglint migrate --dry-run ./src

The dry-run output shows a reviewable diff for each automatable call site alongside the OpenFeature provider setup steps. No files are modified.

Applying the migration plan and enforcing the boundary

Once you have reviewed the dry-run output and set up the OpenFeature provider:

npx flaglint migrate --apply ./src

This applies all safe rewrites in-place. Run your test suite after the apply. Then lock the boundary in CI:

npx flaglint validate --no-direct-launchdarkly ./src

flaglint validate exits non-zero when any direct LaunchDarkly SDK call is detected. Add it to your GitHub Actions workflow and direct LaunchDarkly SDK calls become a build failure from that point forward, blocking regressions as the migration lands across multiple PRs.

Clearing the manual review backlog incrementally

Work through the high-risk items in batches. After each batch, re-run flaglint audit to watch the readiness score climb. At 80 or above, the remaining feature flag technical debt in TypeScript can be handled in a single automated pass — flaglint migrate --apply clears it and flaglint validate --no-direct-launchdarkly confirms the boundary is clean.

The audit plus the CI gate is a closed loop: audit measures what exists, migrate rewrites what is safe, validate blocks regressions, audit confirms progress. You can run the full cycle on a large codebase before writing a single line of migration code. The readiness score tells you up front whether you are looking at a two-sprint effort or a six-month program, and the migration plan tells you exactly which call sites require which kind of attention.

Next steps

LaunchDarkly to OpenFeature Node.js migration guide — the six-step workflow: audit, provider setup, dry-run, apply, validate
Manual review patterns — resolving dynamic flag keys, detail evaluations, and bulk calls before running migrate
flaglint audit CLI reference — all options, output formats (JSON, Markdown, HTML), and exit codes
Migration readiness concept — grade thresholds and the formula behind the readiness score
Enforce in GitHub Actions — CI workflow to block direct LaunchDarkly SDK regressions

Originally published at flaglint.dev

Enforcing Your LaunchDarkly to OpenFeature Migration in GitHub Actions

Krishan Sharma — Sun, 28 Jun 2026 20:39:50 +0000

You started your LaunchDarkly to OpenFeature migration three weeks ago. The first sprint went well—five files converted, OpenFeature provider wired in, existing tests green. Then a teammate opened a PR for a new service. Inside it: two fresh ldClient.boolVariation() calls. Not malicious. They just forgot. You merge it anyway because it is not worth blocking the PR over. Two weeks later there are six more.

This is migration drift. It is the most common reason LaunchDarkly to OpenFeature migration projects stall: there is no gate on new direct LaunchDarkly SDK calls landing in main. Without a CI check that fails on any new call site, every PR can quietly add to the flag debt you are actively paying down.

FlagLint addresses this with two commands—audit to measure the existing flag debt and validate to enforce the boundary—and a one-step GitHub Actions integration that adds the gate with two lines of YAML.

Step 1: Baseline your flag debt before you gate

Before you block anything in CI, run flaglint audit against your source directory. This produces a readiness score and a per-flag-key inventory—the snapshot you will measure progress against, and the list you need when deciding what to exclude during the transition period.

npx flaglint audit ./src

Real output from the src/ directory of the enterprise checkout service shipped with FlagLint examples:

- Auditing examples/enterprise-checkout-service/src/...
# FlagLint Audit Report

**Scanned at:** 2026-06-24T03:20:27.050Z
**Scan root:** /home/user/flaglint/examples/enterprise-checkout-service/src
**Files scanned:** 5
**Duration:** 63ms

## Summary

| Total Flags | High Risk | Medium Risk | Total Usages |
|-------------|-----------|-------------|--------------|
| 13 | 3 | 10 | 19 |

| Dynamic Keys | Detail Evals | Bulk Calls | Stale Signals | Safely Automatable | Manual Review |
|--------------|--------------|------------|---------------|-------------------|---------------|
| 7 | 1 | 1 | 0 | 10 | 9 |

## Migration Readiness

Migration readiness: **53/100** · moderate

[█████████████░░░░░░░░░░░░] 53%

10 safely automatable  ·  9 require manual review

## Flag Debt Inventory

| Flag Key | Risk | Usages | Files | Call Types | Reasons |
|----------|------|--------|-------|------------|---------|
| `<dynamic key>` | 🔴 High | 7 | 3 | variationDetail, boolVariation, stringVariation, numberVariation, jsonVariation | dynamic key |
| `checkout-experiment` | 🔴 High | 1 | 1 | boolVariationDetail | detail evaluation |
| `*` | 🔴 High | 1 | 1 | allFlagsState | bulk call |
| `checkout-v2` | 🟢 Automatable | 1 | 1 | boolVariation | safely automatable |
| `payment-provider` | 🟢 Automatable | 1 | 1 | stringVariation | safely automatable |
| `one-click-checkout` | 🟢 Automatable | 1 | 1 | boolVariation | safely automatable |
| `checkout-currency` | 🟢 Automatable | 1 | 1 | stringVariation | safely automatable |
| `discount-percentage` | 🟢 Automatable | 1 | 1 | numberVariation | safely automatable |
| `max-discount-amount` | 🟢 Automatable | 1 | 1 | numberVariation | safely automatable |
| `discount-config` | 🟡 Medium | 1 | 1 | jsonVariation | safely automatable, json variation |
| `pricing-tier-config` | 🟡 Medium | 1 | 1 | jsonVariation | safely automatable, json variation |
| `recommendations-variant` | 🟢 Automatable | 1 | 1 | stringVariation | safely automatable |
| `bulk-discount-enabled` | 🟢 Automatable | 1 | 1 | boolVariation | safely automatable |

✓ Audit complete: 13 flags — 3 high risk, 10 medium risk

Migration readiness: 53/100  ·  moderate
[█████████████░░░░░░░░░░░░] 53%
10 safely automatable  ·  9 require manual review

The readiness score of 53 means 10 of the 19 direct LaunchDarkly SDK call sites can be automatically rewritten by flaglint migrate --apply. The remaining 9 require manual work: 7 use a dynamic flag key (a variable, not a string literal), 1 is a detail evaluation returning reason metadata, and 1 is a bulk allFlagsState call with no single-flag OpenFeature equivalent. The staleness signal count of zero means no flag keys carry source-level stale signal—no keys contain old, deprecated, legacy, or tmp.

Save this output as your progress baseline.

Step 2: Run the validate command locally

flaglint validate --no-direct-launchdarkly exits non-zero when any direct LaunchDarkly SDK call is found in the scanned directory. Before wiring it into CI, run it locally so you know exactly what the gate will report:

npx flaglint validate ./src --no-direct-launchdarkly

Real output from the same src/ directory:

- Scanning examples/enterprise-checkout-service/src/...
✗ validate --no-direct-launchdarkly: 19 direct LaunchDarkly evaluation call(s) found.

  analytics.ts:51:43 — variationDetail("(dynamic key)")
  analytics.ts:76:23 — boolVariationDetail("checkout-experiment")
  analytics.ts:104:22 — allFlagsState(bulk inventory)
  checkout.ts:40:9 — boolVariation("checkout-v2")
  checkout.ts:49:9 — stringVariation("payment-provider")
  checkout.ts:58:9 — boolVariation("one-click-checkout")
  checkout.ts:67:9 — stringVariation("checkout-currency")
  flags-wrapper.ts:48:9 — boolVariation("(dynamic key)")
  flags-wrapper.ts:67:11 — boolVariation("(dynamic key)")
  flags-wrapper.ts:70:11 — stringVariation("(dynamic key)")
  flags-wrapper.ts:73:11 — numberVariation("(dynamic key)")
  flags-wrapper.ts:75:9 — jsonVariation("(dynamic key)")
  pricing.ts:46:9 — numberVariation("discount-percentage")
  pricing.ts:55:9 — numberVariation("max-discount-amount")
  pricing.ts:69:9 — jsonVariation("discount-config")
  pricing.ts:83:9 — jsonVariation("pricing-tier-config")
  product.ts:52:9 — boolVariation("(dynamic key)")
  product.ts:61:9 — stringVariation("recommendations-variant")
  product.ts:70:9 — boolVariation("bulk-discount-enabled")

These files must migrate to OpenFeature before this rule passes.
Run `flaglint migrate --dry-run` to review the migration plan.

Each finding shows file path, line number, column, call type, and flag key. All call types are tracked: boolVariation, stringVariation, numberVariation, jsonVariation, variationDetail, boolVariationDetail, and allFlagsState. Dynamic flag keys appear as (dynamic key).

The gate exits non-zero the moment any direct LaunchDarkly SDK call is detected, blocking any new flag from bypassing the OpenFeature provider. When validate finds zero violations, it exits cleanly:

✓ validate --no-direct-launchdarkly: no direct LaunchDarkly evaluation calls found.

That line is what you are working toward.

Step 3: Add the GitHub Actions gate

FlagLint ships a composite GitHub Actions action. The minimum setup is two lines:

name: FlagLint

on: [pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: flaglint/flaglint@main
        with:
          directory: ./src

The action runs flaglint validate ./src --no-direct-launchdarkly and exits 1 when any direct call is found. Do not set continue-on-error: true on the FlagLint step. The job failing is the mechanism—that is what blocks the PR.

Excluding the bootstrap file

Your OpenFeature provider setup module legitimately imports from the LaunchDarkly SDK to instantiate the provider. Exclude it with --bootstrap-exclude so the gate does not fire on it:

- uses: flaglint/flaglint@main
  with:
    directory: ./src
    extra-args: '--bootstrap-exclude "src/provider/setup.ts"'

You can pass multiple exclusion patterns:

extra-args: >-
  --bootstrap-exclude "src/provider/setup.ts"
  --bootstrap-exclude "src/bootstrap/**"

The excluded files can call the LaunchDarkly SDK directly. Everything else cannot. The --bootstrap-exclude flag accepts glob patterns, so a single "src/provider/**" covers a provider directory with multiple files.

Step 4: Add SARIF annotations for inline PR diff visibility

Job-level failure tells engineers something is wrong. SARIF annotations tell them exactly which line is wrong, directly in the PR diff. Add the SARIF upload step alongside the gate:

name: FlagLint Policy

on: [pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4

      - name: Validate no direct LaunchDarkly calls
        id: flaglint
        uses: flaglint/flaglint@main
        with:
          directory: ./src
          extra-args: >-
            --bootstrap-exclude "src/provider/setup.ts"
            --format sarif
            --output flaglint-validation.sarif

      - name: Upload validation SARIF
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: flaglint-validation.sarif

SARIF findings use rule id flaglint.direct-launchdarkly. With security-events: write, GitHub annotates each violation inline on the relevant PR diff line as a code scanning alert. Set if: always() on the upload step—not on the validate step—so GitHub receives the SARIF file even after the job fails, and annotations appear regardless of whether the PR passes.

Managing the transition period

If your service already has 19 direct LaunchDarkly SDK calls when you add the gate, CI will immediately fail. Two approaches handle the transition:

Start with SARIF-only, then harden. Set continue-on-error: true temporarily on the validate step so violations surface as code scanning alerts without blocking merges. Remove continue-on-error once you have migrated the bulk of existing call sites.

Exclude directories that are mid-migration. Use --bootstrap-exclude patterns to allow files already in the migration queue through the gate while blocking any new file from adding a direct LaunchDarkly SDK call. Remove each exclusion as you migrate that directory.

Re-run the audit after each sprint to track how the readiness score moves. The goal is a validate run that exits cleanly:

✓ validate --no-direct-launchdarkly: no direct LaunchDarkly evaluation calls found.

When that is the consistent CI result, the LaunchDarkly to OpenFeature migration is structurally complete. No new direct call sites can land, and the codebase no longer carries flag debt pointing at the LaunchDarkly SDK.

Next steps

LaunchDarkly to OpenFeature Node.js migration guide — the full end-to-end workflow: audit, provider setup, dry-run, apply, validate
Manual Review Patterns — how to resolve dynamic flag keys, detail evaluations, and bulk calls before migrate --apply can handle them automatically
flaglint audit CLI reference — all options, output formats (JSON, Markdown, HTML), and exit behavior
Migration Readiness concept — how the readiness score is calculated and what the grade thresholds mean
GitHub Actions integration reference — full option table for the composite action, SARIF configuration, and rule id reference

Originally published at flaglint.dev

A provider outage can expose how deeply application code depends on a single feature-flag SDK.

Krishan Sharma — Sun, 28 Jun 2026 20:36:52 +0000

A provider outage can expose how deeply application code depends on a single
feature-flag SDK. OpenFeature creates a neutral application boundary without
forcing teams to abandon LaunchDarkly.

This article walks through the local audit, migration preview, and CI enforcement
path that lets teams add that boundary incrementally.

The Vendor Lock-In Problem

Direct SDK calls look like this:

import LaunchDarkly from 'launchdarkly-node-server-sdk';
const ldClient = LaunchDarkly.init(process.env.LD_SDK_KEY);

const enabled = await ldClient.boolVariation('checkout-v2', ctx, false);

Your application code is coupled to LaunchDarkly's API surface.
Switching providers means rewriting every evaluation call.

OpenFeature decouples this. Your application calls the OpenFeature API.
The provider (LaunchDarkly, or anything else) is a configuration detail.

The Migration That Stalls

Most teams agree to add OpenFeature. Most migrations take 6+ weeks
and nearly break production at least once.

The reasons:

No inventory of where direct SDK calls live
Argument-order differences cause subtle production bugs
Phased migrations partially reverse when new engineers join
No CI enforcement to prevent new direct calls

One of those reasons is an API difference that breaks even careful rewrites — the argument-order trap between LaunchDarkly and OpenFeature →

What FlagLint Does

Before you can migrate, you need to know what you're migrating.

npx flaglint scan ./src

AST-based inventory of every direct LaunchDarkly SDK call.
File, line, call type, flag key, whether it's safely automatable.

Then:

```bash frame="none"
flaglint migrate ./src --dry-run




Reviewable diffs for safe call sites. Argument order corrected.
Dynamic keys, detail methods, and bulk calls reported for manual review.

Then:



```bash frame="none"
flaglint validate ./src --no-direct-launchdarkly

CI gate. Fails the build if any new direct LD call appears.
The migration doesn't rot.

LaunchDarkly Stays As Your Provider

This is not a migration away from LaunchDarkly.

LaunchDarkly offers an official OpenFeature provider. After the migration,
LaunchDarkly still evaluates your flags — you're just calling the
OpenFeature API instead of the LaunchDarkly SDK directly.

The difference: if you need to switch providers, you change the provider
configuration. Your application code doesn't change.

→ Start with the scan

→ GitHub

Originally published at flaglint.dev

Your Node.js Codebase Has Flag Debt. Here's How to Find It in 30 Seconds.

Krishan Sharma — Tue, 02 Jun 2026 15:54:10 +0000

Most teams don't know how many feature flags are in their codebase.

They know they have some. They think they cleaned up most. They're not sure about the rest.

One command changes that:

npx flaglint audit ./src

No API key. No credentials. No dashboard to sign up for. Just your source code and an honest answer.

The Problem Nobody Talks About

According to LaunchDarkly's best practices, most release flags should live for only days to weeks — yet many remain in codebases for months or years.

That's not a LaunchDarkly problem. It's a universal one.

Flags accumulate because adding one is fast and removing one is work. You ship the feature, move on, and the flag stays. Six months later a new engineer asks "is this safe to delete?" and nobody knows. So it stays another six months.

Stale flags make code "more complex and harder to maintain," as developers spend extra time navigating obsolete conditionals. Unused toggles may degrade performance or even inadvertently expose features or data.

And here's the part that stings: developers spend 33–42% of their time dealing with technical debt and maintenance. Feature flag debt is a quiet contributor to that number.

What "Flag Debt" Actually Looks Like

Here's a real checkout service. Nothing exotic — a Node.js backend with LaunchDarkly calls spread across five files.

// checkout.ts
export async function isCheckoutV2Enabled(user: User): Promise<boolean> {
  const ctx = { targetingKey: user.id, email: user.email, plan: user.plan };
  return ldClient.boolVariation("checkout-v2", ctx, false);
}

// discounts.ts
const flagKey = `discount-${experimentName}`;
const enabled = await ldClient.boolVariation(flagKey, ctx, false);

// analytics.ts
const state = await ldClient.allFlagsState(ctx);

Three different patterns. Three very different levels of risk.

The first one is fine — static key, known type, safely removable.

The second one is a problem — the key is a template literal. You can't statically know which flag it evaluates at runtime.

The third one is a migration blocker — allFlagsState has no OpenFeature equivalent. It requires an architecture decision before you touch it.

Most teams treat all three the same. They shouldn't.

The Audit Command

FlagLint v0.6.0 ships with a new command: flaglint audit.

It scans your codebase, classifies every flag call by risk level, and tells you exactly what you're dealing with — before you touch anything.

npx flaglint@latest audit ./src

Running it against the enterprise checkout service above produces:

✓ Audit complete: 13 flags — 3 high risk, 10 medium risk, 0 low risk

With the full table:

Flag Key	Risk	Usages	Reasons
`dynamic`	🔴 High	7	dynamic key
`checkout-experiment`	🔴 High	1	detail evaluation
`*`	🔴 High	1	bulk call
`checkout-v2`	🟡 Medium	1	safely automatable
`payment-provider`	🟡 Medium	1	safely automatable
`discount-config`	🟡 Medium	1	safely automatable, json variation
...

High risk means the call needs manual review before anything happens:

Dynamic key — the flag key is a variable or template literal. FlagLint can't tell which flag you're evaluating.
Detail evaluation — boolVariationDetail returns metadata with no direct OpenFeature equivalent.
Bulk call — allFlagsState is an architecture decision, not a line-by-line migration.

Medium risk means FlagLint can automate the migration safely, but the flag is still a direct vendor call that will need to move eventually.

Low risk means the flag is already migrated or has no debt signals.

Three Output Formats

# Markdown — good for PRs and docs
npx flaglint audit ./src --format markdown

# JSON — good for CI pipelines and dashboards
npx flaglint audit ./src --format json --output audit.json

# HTML — shareable report for engineering reviews
npx flaglint audit ./src --format html --output flag-debt.html

The HTML report is the one worth sharing with your team or your manager. It's a single self-contained file — no server needed, just open it in a browser. Drop it in a PR, a Jira ticket, or an email. It shows exactly which flags need attention and why.

From Audit to Action

The audit is informational. It doesn't touch your code.

Once you've seen your report, FlagLint has two more commands for when you're ready to act:

Preview the migration:

npx flaglint migrate ./src --dry-run

This shows before/after diffs for every safely automatable call — the Medium risk flags from your audit. Nothing is written to disk.

--- checkout.ts
+++ checkout.ts
-  return ldClient.boolVariation("checkout-v2", ctx, false);
+  return openFeatureClient.getBooleanValue("checkout-v2", false, ctx);

Note the argument order. LaunchDarkly is (flagKey, context, fallback). OpenFeature is (flagKey, fallback, context). A manual find-and-replace migration silently swaps them — that's a production bug waiting to happen. FlagLint gets it right because it uses AST analysis, not text matching.

Apply the migration:

npx flaglint migrate ./src --apply

Rewrites only the calls that are proven safe. Dynamic keys, detail methods, and bulk calls are skipped and reported for manual review. Won't run on a dirty git tree. Idempotent — safe to run twice.

Lock the boundary in CI:

npx flaglint validate ./src --no-direct-launchdarkly

Exits 1 if any direct LaunchDarkly evaluation call appears in your codebase. Add this to your GitHub Actions workflow and the migration can't silently reverse.

Why No API Key?

Every major feature flag platform has a tool that connects to their API to show you flag health. Those tools are useful, but they only see flags that exist in their own system. They won't show you a LaunchDarkly flag if you're asking a Statsig dashboard.

More importantly — they're built to keep you in their platform. No vendor builds the exit ramp for their own tool.

FlagLint only looks at your source code. It doesn't know what's in your LaunchDarkly dashboard. It doesn't need to. The question it answers is: what is your code actually doing right now?

That's a different question, and it has a different answer.

The Full Workflow

# Step 1: Understand what you have
npx flaglint audit ./src --format html --output flag-debt.html

# Step 2: Preview safe migrations
npx flaglint migrate ./src --dry-run

# Step 3: Apply the safe ones
npx flaglint migrate ./src --apply

# Step 4: Lock it in CI
npx flaglint validate ./src --no-direct-launchdarkly

Four commands. Covers the full lifecycle from "what do we have?" to "this can never regress."

Try It

npx flaglint@latest audit ./src

No install required. Works on any Node.js 20+ project using the LaunchDarkly Node.js server SDK (both launchdarkly-node-server-sdk and @launchdarkly/node-server-sdk).

→ GitHub — MIT licensed, open source

→ npm

→ Docs

FlagLint is a vendor-neutral CLI for LaunchDarkly → OpenFeature migrations. v0.6.0 adds flag debt auditing. Read the changelog →

Tags: node devops javascript typescript openfeature launchdarkly featureflags technicaldebt opensource featureflags

Standardizing Feature Flags Is Easy to Agree On. Migrating Safely Is the Hard Part.

Krishan Sharma — Thu, 28 May 2026 12:02:08 +0000

Why I built FlagLint, an open-source CLI for moving direct LaunchDarkly Node.js usage behind an OpenFeature boundary

Feature flags usually begin as a simple engineering decision.

A team needs to release gradually. A developer adds a flag. The application evaluates it through the provider SDK. The rollout succeeds.

Then the pattern repeats.

One feature becomes ten. One service becomes dozens. Over time, application code starts to accumulate direct calls to a provider-specific API:

const enabled = await ldClient.boolVariation(
  "checkout-v2",
  context,
  false
);

There is nothing wrong with that call by itself. LaunchDarkly is doing exactly what it is supposed to do: providing feature-flag management and evaluation.

The problem appears later, when a platform team wants a consistent application-facing abstraction across services.

Maybe the organization wants to standardize on OpenFeature, the CNCF-incubating, vendor-agnostic feature-flag API. Maybe teams want feature-flag instrumentation, governance, or shared patterns implemented once at a platform boundary instead of separately inside each service.

At that point, the difficult question is no longer:

Should we standardize feature-flag evaluation?

The difficult questions are:

Where are all the direct SDK calls? Which ones can be migrated safely? Which ones require human review? And how do we stop new direct calls from returning after migration?

That is the problem I built FlagLint to solve.

OpenFeature Does Not Mean Replacing LaunchDarkly

A common misconception in migration conversations is that introducing OpenFeature means replacing the current feature-flag provider.

It does not.

OpenFeature standardizes the evaluation API that application code uses. A provider still performs the actual evaluation. LaunchDarkly offers an official OpenFeature provider for its Node.js server-side SDK, so a Node.js service can continue using LaunchDarkly as its feature-flag provider while application code evaluates flags through OpenFeature.

Conceptually, the change looks like this:

// Direct provider-specific application usage
await ldClient.boolVariation("checkout-v2", context, false);

becoming:

// Standard application-facing evaluation API
await openFeatureClient.getBooleanValue("checkout-v2", false, context);

LaunchDarkly remains behind the provider boundary. The application code moves toward a standard interface.

That distinction matters. Platform standardization should not require an unnecessary provider replacement project.

Why This Migration Is More Dangerous Than It Looks

At first glance, this appears to be a simple codemod problem: find a method call and rename it.

But feature-flag migrations carry runtime behavior. An incorrect transformation can change what users see in production.

For example, the LaunchDarkly and OpenFeature method signatures differ in argument order:

// LaunchDarkly
ldClient.boolVariation(key, context, fallback)

// OpenFeature
openFeatureClient.getBooleanValue(key, fallback, context)

A careless rewrite can silently swap the fallback value and context.

There are additional complications:

a flag key may be a dynamic expression rather than a static string;
a call may request evaluation details rather than only a flag value;
code may use bulk flag-state APIs;
a fallback type may not be statically clear;
a service may import a shared platform-owned OpenFeature client using a local alias;
the provider bootstrap file may legitimately reference LaunchDarkly directly;
asynchronous behavior must be preserved exactly.

In a migration involving feature flags, “we rewrote most of it automatically” is not enough. The important question is whether the automation knows when not to rewrite code.

The Design Principle Behind FlagLint: Conservative Automation

FlagLint is an open-source CLI focused on a specific workflow:

Help Node.js teams inventory direct LaunchDarkly server SDK evaluations, migrate only provably safe call sites to OpenFeature, and enforce the new boundary in CI.

Its scope is deliberately narrow today. FlagLint supports JavaScript and TypeScript code using the LaunchDarkly Node.js server-side SDK package forms:

@launchdarkly/node-server-sdk
launchdarkly-node-server-sdk

It is not trying to claim every language, every SDK, or every feature-flag lifecycle problem.

FlagLint uses AST-based analysis to identify direct LaunchDarkly Node.js evaluation calls. It can automatically transform typed static evaluations only when the important parts are explicit:

the flag key;
the fallback value and type;
the evaluation context;
a proven OpenFeature client binding.

For example:

// Before
return await ldClient.boolVariation("checkout-v2", ctx, false);

can safely become:

// After
return await openFeatureClient.getBooleanValue("checkout-v2", false, ctx);

But FlagLint does not automatically rewrite uncertain patterns. Dynamic keys, detail evaluation methods, bulk calls, unknown fallbacks, browser or React SDK usage, and ambiguous bindings remain visible for human review.

This is not a limitation to hide. It is the safety model.

A migration tool should automate the obvious cases and make uncertainty impossible to ignore.

The Workflow: Scan, Migrate, Enforce

FlagLint is designed around three steps.

1. Inventory direct SDK coupling

Before a migration starts, teams need to understand what exists in the codebase:

npx flaglint scan ./src

The scan identifies direct LaunchDarkly Node.js server SDK evaluation calls, their files, flag keys, call types, and patterns that need manual review. Reports can be emitted in formats including Markdown, JSON, HTML, and SARIF.

This is useful for both developers and platform teams. Before changing code, you can see whether a service is mostly straightforward or full of patterns that require careful migration planning.

2. Preview and apply safe transformations

Next, teams can generate a migration plan and inspect diffs before touching source code:

npx flaglint migrate ./src --dry-run

FlagLint generates reviewable before/after diffs. When a file already contains a proven OpenFeature client binding, including an approved imported shared client binding, the preview uses that exact binding.

For example, a service may already import a platform-owned client with an alias:

import { openFeatureClient as flags } from "../platform/feature-flags.js";

FlagLint preserves that architecture and previews the migration using flags.getBooleanValue(...) rather than inventing a new local client.

When ready, safe transformations can be applied:

npx flaglint migrate ./src --apply

The apply mode is guarded. It requires a proven OpenFeature client binding, refuses to write into a dirty Git working tree unless explicitly overridden, does not insert provider bootstrap setup automatically, and does not rewrite uncertain patterns.

3. Prevent the migration from reversing

Migration is not complete if new direct provider SDK calls can quietly appear in future pull requests.

Once a service has completed the boundary migration, FlagLint can enforce it in CI:

npx flaglint validate ./src --no-direct-launchdarkly

Validation can emit SARIF findings so direct LaunchDarkly policy violations can appear as annotations in code scanning and pull-request review flows.

This turns a one-time refactor into an enforceable engineering standard.

An Important Boundary: FlagLint Is Not a Stale-Flag Platform

There is a broader category of feature-flag debt: flags that are fully rolled out, inactive, unused at runtime, or ready for deletion in the provider platform.

That is an important problem, but it requires lifecycle and runtime information that source code alone cannot prove.

FlagLint does not currently claim to delete stale flags, inspect production evaluations, replace LaunchDarkly lifecycle tooling, or reduce feature-flag billing.

Its current problem is more precise:

Where is application code directly coupled to the LaunchDarkly Node.js SDK, what can move safely behind OpenFeature, and can we enforce that boundary afterward?

That focus is intentional. Tools earn trust by being accurate about what they know and what they do not know.

What I Learned Building the First Release

The technical work was only one part of the project. The harder part was defining safe behavior.

A migration CLI for application infrastructure cannot be aggressive by default. It needs to be explainable. Every automated rewrite should be reviewable. Every skipped pattern should make sense to the engineer reading the report.

During post-release validation of FlagLint v0.5.0, I found a good example of why that matters. A dry-run using a proven aliased OpenFeature client binding correctly previewed a safe transformation, but the CLI still printed global guidance implying provider setup was required. The transformation itself was correct, but the message was contradictory.

That mattered because trust in migration tools is not only about whether they edit code correctly. It is also about whether their explanations match their behavior.

In v0.5.1, I fixed that messaging so proven bindings are described accurately, missing bindings still receive setup guidance, and mixed cases clearly scope guidance only to diffs that need it.

No safety boundary was weakened to make the tool appear more capable.

That is the standard I want FlagLint to maintain as it grows.

What Comes Next

The next challenge is not just transforming code. It is helping real teams adopt the boundary incrementally.

In a small service, a team may be able to migrate all direct SDK calls and enable strict CI enforcement immediately.

In an established codebase, that may not be realistic. A platform team may find hundreds of existing direct evaluations spread across services. They still need a way to prevent new vendor-coupled access while reducing existing usage over time.

That leads to the next direction for FlagLint: team adoption and governance workflows, including the ability to measure migration readiness across services and support gradual CI rollout without requiring a big-bang refactor.

The goal remains simple:

Make the safer architecture easier to adopt than the shortcut.

Try FlagLint

FlagLint is open source and available today as v0.5.1.

Run it against a Node.js service using the LaunchDarkly server-side SDK:

npx flaglint scan .

Then explore a reviewable migration preview:

npx flaglint migrate --dry-run

Resources:

Website: flaglint.dev
GitHub: github.com/flaglint/flaglint
npm: npmjs.com/package/flaglint
OpenFeature: openfeature.dev
LaunchDarkly OpenFeature Node.js provider documentation: LaunchDarkly docs

I would especially value feedback from Node.js backend engineers and platform teams already using LaunchDarkly:

What direct SDK patterns exist in your repositories?
Do you use internal wrappers or shared feature-flag clients?
What would make an OpenFeature migration safe enough to evaluate in a real service?

The best developer tools are shaped by the real codebases they have to survive.

devops #typescript #javascript #opensource #featureflags

DEV Community: Krishan Sharma

Why LaunchDarkly OpenFeature Migrations Break in Production

The Agreement That Takes 30 Minutes

The Argument-Order Trap

Why Grep Misses It

What AST Analysis Catches

When AST Analysis Refuses to Rewrite

The CI Gate

Try It Now

Five LaunchDarkly SDK Patterns That Block Automatic Migration to OpenFeature

What makes a call automatable

Pattern 1 — Dynamic flag keys

Pattern 2 — Detail evaluations

Pattern 3 — Bulk state calls

Pattern 4 — Configured wrappers

Pattern 5 — Unknown fallback types (jsonVariation)

Seeing the full breakdown before you start

Feature Flag Technical Debt in TypeScript: Find, Measure, and Clear It

Why grep misses TypeScript feature flag technical debt

Measuring the flag debt

The three risk tiers in the flag debt inventory

The argument order inversion

Applying the migration plan and enforcing the boundary

Clearing the manual review backlog incrementally

Next steps

Enforcing Your LaunchDarkly to OpenFeature Migration in GitHub Actions

Step 1: Baseline your flag debt before you gate

Step 2: Run the validate command locally

Step 3: Add the GitHub Actions gate

Excluding the bootstrap file

Step 4: Add SARIF annotations for inline PR diff visibility

Managing the transition period

Next steps

A provider outage can expose how deeply application code depends on a single feature-flag SDK.

The Vendor Lock-In Problem

The Migration That Stalls

What FlagLint Does

LaunchDarkly Stays As Your Provider

Your Node.js Codebase Has Flag Debt. Here's How to Find It in 30 Seconds.

The Problem Nobody Talks About

What "Flag Debt" Actually Looks Like

The Audit Command

Three Output Formats

From Audit to Action

Why No API Key?

The Full Workflow

Try It

Standardizing Feature Flags Is Easy to Agree On. Migrating Safely Is the Hard Part.

Why I built FlagLint, an open-source CLI for moving direct LaunchDarkly Node.js usage behind an OpenFeature boundary

OpenFeature Does Not Mean Replacing LaunchDarkly

Why This Migration Is More Dangerous Than It Looks

The Design Principle Behind FlagLint: Conservative Automation

The Workflow: Scan, Migrate, Enforce

1. Inventory direct SDK coupling

2. Preview and apply safe transformations

3. Prevent the migration from reversing

An Important Boundary: FlagLint Is Not a Stale-Flag Platform

What I Learned Building the First Release

What Comes Next

Try FlagLint

devops #typescript #javascript #opensource #featureflags

Pattern 5 — Unknown fallback types (`jsonVariation`)