FlagLint Blog

OpenFeature React: Audit and Migrate Your LaunchDarkly React App

Aug 20, 2026 - 6 min read

OpenFeature React: Audit and Migrate Your LaunchDarkly React App

Your React app is probably riddled with ldClient.variation() calls and useFlags() hooks spread across 30–50 components. They work, they’ve always worked, and nobody remembers which flags are still live. Then LaunchDarkly’s bill arrives — or your platform team announces an OpenFeature mandate — and you realise you have no idea how many flag keys exist across your component tree.

That’s the core problem with LaunchDarkly SDK usage in long-lived React codebases: the calls accumulate invisibly. You can’t migrate what you haven’t measured.

This guide walks through auditing a React project with FlagLint, reading the results, and doing the actual LaunchDarkly SDK → OpenFeature React swap, component by component.

Why flag debt builds up faster in React

In a Node.js service, flag evaluations tend to live close together — middleware, handlers, config loaders. In React, they scatter. A flag that controls a header renders in AppShell.tsx. The same flag shows up in MobileNav.tsx, DesktopNav.tsx, and NavAnalytics.tsx. One flag key, four call sites, none of them talking to each other.

Three years in, you have 80 flags in LaunchDarkly, 140 call sites in React, and no map. Flags that shipped are still evaluated on every render. That’s flag debt — stale signals running up cost and making every component harder to understand.

The migration plan cannot start with “pick a component and swap the hook.” It has to start with: what flag keys exist, what call type each uses, which ones have a high staleness signal, and what the current readiness score is. FlagLint produces that map.

Step 1: Run the FlagLint audit

FlagLint targets TypeScript and JavaScript source files. Running it against a directory that contains only documentation shows the baseline case:

npx flaglint@latest audit ./src/content/docs/

Output:

- Auditing ./src/content/docs/...
No matching files found. Check your .flaglintrc include patterns.

Correct — that directory holds only Markdown. For a React project, point the audit at src/:

npx flaglint@latest audit ./src/

FlagLint walks every .ts and .tsx file, extracts every flag key, classifies each call type, assigns staleness signals, and prints the overall readiness score.

Step 2: Configure .flaglintrc for React

Out of the box, FlagLint looks for calls from launchdarkly-node-server-sdk. To catch React-specific patterns — the useFlags() hook, the withLDConsumer() HOC, and the useLDClient() hook — add a .flaglintrc at the repo root:

{
  "include": ["src/**/*.ts", "src/**/*.tsx"],
  "exclude": ["src/**/*.test.tsx", "src/**/*.spec.ts"],
  "sdks": ["launchdarkly-js-client-sdk", "launchdarkly-react-client-sdk"]
}

The launchdarkly-react-client-sdk entry tells FlagLint to recognise the React SDK’s call types. Without it, hook-based flag evaluations are invisible to the audit and won’t appear in the flag debt count or the readiness score.

Re-run after saving .flaglintrc and you’ll see each flag key, its call type, and whether the staleness signal is high, medium, or low.

Step 3: Understand the readiness score

The readiness score runs from 0 to 100. Zero means every flag evaluation in your codebase goes through the LaunchDarkly SDK. One hundred means every evaluation goes through an OpenFeature provider.

FlagLint computes it by comparing LaunchDarkly SDK call sites to total flag call sites. A repo at score 40 has moved 40% of its flag evaluations to OpenFeature. The remaining 60% still carry LaunchDarkly SDK imports.

The readiness score tells you at a glance how far through the migration plan you are, and gives you a concrete number to track PR-by-PR. See LaunchDarkly Flag Debt: Audit, Estimate, and Prioritize Your Migration for a deeper breakdown of how to read the score alongside flag debt estimates.

Step 4: Before and after — LaunchDarkly SDK to OpenFeature React

Hooks (the common case)

Before — LaunchDarkly React SDK:

import { useFlags } from 'launchdarkly-react-client-sdk';

function BillingPage() {
  const { billingV2Rollout } = useFlags();
  return billingV2Rollout ? <BillingV2 /> : <BillingV1 />;
}

After — OpenFeature React:

import { useBooleanFlagValue } from '@openfeature/react-sdk';

function BillingPage() {
  const billingV2Rollout = useBooleanFlagValue('billing-v2-rollout', false);
  return billingV2Rollout ? <BillingV2 /> : <BillingV1 />;
}

Two things change. First, the import: launchdarkly-react-client-sdk → @openfeature/react-sdk. Second, the call type: useFlags() returns all flags at once as a camelCase object, so you destructure billingV2Rollout. The OpenFeature useBooleanFlagValue() evaluates a single flag key and takes the raw kebab-case key 'billing-v2-rollout' as a string.

FlagLint’s audit marks the camelCase-to-kebab-case normalisation as a staleness signal to watch for. If a flag key was committed as billingV2Rollout in one component and billing-v2-rollout in another, the audit surfaces both call sites so you can consolidate before migrating.

HOC pattern

Older React codebases use withLDConsumer instead of hooks:

Before:

import { withLDConsumer } from 'launchdarkly-react-client-sdk';

function FeatureNav({ flags }) {
  return flags.showNewNav ? <NewNav /> : <OldNav />;
}

export default withLDConsumer()(FeatureNav);

After:

import { useBooleanFlagValue } from '@openfeature/react-sdk';

function FeatureNav() {
  const showNewNav = useBooleanFlagValue('show-new-nav', false);
  return showNewNav ? <NewNav /> : <OldNav />;
}

export default FeatureNav;

The HOC disappears entirely. OpenFeature React hooks pull from context without a wrapper. FlagLint classifies withLDConsumer wraps as their own call type during the audit, so the migration plan counts them separately from hook-based evaluations.

Wiring the OpenFeature provider at app root

Before any hook resolves, set the OpenFeature provider once at the top of your tree. The LaunchDarkly OpenFeature provider is the easiest starting point — it keeps your existing flags working during migration:

import { OpenFeatureProvider, OpenFeature } from '@openfeature/react-sdk';
import { LaunchDarklyClientProvider } from '@launchdarkly/openfeature-js-client-sdk';

const ldClient = LaunchDarklyClientProvider.createClient('your-client-side-id');
OpenFeature.setProvider(new LaunchDarklyClientProvider(ldClient));

function App() {
  return (
    <OpenFeatureProvider>
      <Router />
    </OpenFeatureProvider>
  );
}

Once this is in place, every component that calls useBooleanFlagValue() evaluates against the LaunchDarkly OpenFeature provider automatically. You can swap the provider to Flipt, Unleash, or any other OpenFeature-compatible system later without touching component code. That’s the architectural value: the migration plan stops being locked to one vendor.

Step 5: Clear stale flags before migrating

Not every flag needs an OpenFeature equivalent. Some flags are done — the rollout shipped, the old branch is deleted, but the LaunchDarkly SDK call is still in the component tree because removing it never made the sprint.

FlagLint assigns a staleness signal based on source history and call frequency. A flag key with a high staleness signal, a single call site, and a boolean call type is a strong candidate for outright deletion: remove the LaunchDarkly SDK call, remove the conditional branch, archive the flag in LaunchDarkly. That drops flag debt and improves the readiness score without writing any OpenFeature code.

Kill high-staleness-signal flags first. Then migrate the rest. The LaunchDarkly Feature Flag Cleanup guide covers the removal workflow in detail for TypeScript codebases.

Step 6: Enforce in CI

Once you start migrating, new LaunchDarkly SDK calls introduced in PRs will quietly undo your progress. FlagLint has a CI mode that fails the build when the readiness score drops below a threshold you set. Wire it into your pipeline so that every PR that adds a new LaunchDarkly SDK call type is blocked until the author migrates it to an OpenFeature React hook instead. See Enforcing Your LaunchDarkly to OpenFeature Migration in GitHub Actions for the exact workflow and YAML.

Next steps

1. Run npx flaglint@latest audit ./src/ against your actual React source. Get the real flag key count and readiness score before estimating effort.
2. Add .flaglintrc with launchdarkly-react-client-sdk in the sdks list so hooks and HOCs appear in the flag debt count.
3. Delete high-staleness-signal flags first. Reducing the LaunchDarkly SDK call count before migrating keeps each PR focused.
4. Wire the OpenFeature provider at app root. Flags keep working via the LaunchDarkly OpenFeature provider while you migrate component by component.
5. Track the readiness score per PR. FlagLint in CI gives you a number that goes up. When it hits 100, the LaunchDarkly SDK import can come out of package.json.

OpenFeature React is a hook-for-hook replacement at the component level. The migration plan is mechanical once you have the audit. FlagLint gives you that map.

flaglint-go: We Field-Tested It Against Real Repos and Found Zero Recall

Jul 6, 2026 - 5 min read

Krishan Sharma

Founder and maintainer of FlagLint

flaglint-go is a native Go binary for auditing LaunchDarkly Go server SDK usage — no Node.js required.

brew install flaglint/tap/flaglint-go
flaglint-go audit ./services

It’s the Go-native counterpart to flaglint-js, and it shares the same non-negotiable rule: a variable is only ever treated as a LaunchDarkly client when its identity can be proven — never by matching a method name in isolation. That rule is why flaglint-js earned trust in the first place, and flaglint-go inherited it from day one.

The problem we didn’t expect

Before shipping, we validated flaglint-go the way you’d hope any static analysis tool gets validated: not just against synthetic fixtures we wrote ourselves, but against real, unmodified, open-source Go repositories known to use the LaunchDarkly SDK — including the official launchdarkly-labs/ld-sample-app-go, plus weaviate/weaviate, CMS-Enterprise/mint-app, and e2b-dev/infra.

The result: zero false positives, but also zero recall on every single repo with genuine usage.

That’s a striking failure. Not “missed a few edge cases” — missed all of it, on the official sample app included. The scanner wasn’t broken; it was doing exactly what it was designed to do (prove identity syntactically, never guess by name) — it just turned out real Go code almost never wires up the LaunchDarkly client the simple way our synthetic fixtures assumed.

What real code actually does

Three different repos, three different indirection patterns, none of them exotic:

The official sample app wires the client through a package-level singleton getter, called from a different package entirely:

// package ldclient
func GetLdClient() *ld.LDClient { /* ... */ }

// package api, a different file, a different package
client := ldclient.GetLdClient()
client.BoolVariation("test-flag", ctx, false)

weaviate stores the client into a wrapper struct via composite literal, then reaches it through a two-level field chain — on a generic struct:

type LDIntegration struct {
    ldClient *ld.LDClient
}

type FeatureFlag[T SupportedTypes] struct {
    ldInteg *LDIntegration
}

// inside one of FeatureFlag[T]'s methods:
flag, err := f.ldInteg.ldClient.StringVariation(f.key, f.ldInteg.ldContext, v)

mint-app passes an already-constructed client into a struct’s constructor as a plain function parameter — there’s no assignment to trace at all; the parameter’s declared type is the only place identity is ever established.

None of these require real type-checking to resolve. In every case, the proof of identity is available directly from the AST — a struct’s declared field type, a function’s declared parameter or return type — the same “trust the syntax, no build required” spirit as the rest of the scanner. What they do require is looking at more than one file at a time, since the code that constructs the client and the code that uses it are routinely in a different file, sometimes a different package, from wherever the binding was first established.

Rebuilding around a whole-scan pass

We rearchitected the scanner from a per-file model (read, parse, detect, discard — one file at a time) into a whole-scan pass: parse every file up front, then resolve identity across the entire scan before any detection runs. That closed all three gaps:

• Composite-literal struct-field binding — &LDIntegration{ldClient: client} binds the field when client is itself already bound.
• Multi-level field-selector chains, including through generics — a struct’s fields can be declared in a different file than where they’re used.
• Cross-package factory/getter functions, resolved via real go.mod-derived import paths — never a name-based guess. (We explicitly considered and rejected matching by “last segment of the import path” as a shortcut — that’s a name heuristic wearing an import-path costume, exactly the kind of thing our non-negotiable identity rule exists to prevent.)
• Parameter-typed client bindings — a parameter declared *ld.LDClient is bound from its type alone, no assignment to trace.

We also found and fixed a bug that had nothing to do with the original plan: Go generics. weaviate’s FeatureFlag[T] broke a piece of code that had only ever been tested against non-generic structs — a method receiver on a generic type has a different AST shape (*ast.IndexExpr) than a plain one, and the scanner silently failed to resolve it at all. Found only by testing against real code that happened to use generics.

The bug our own review process caught

Before merging any of this, we ran an independent review pass — a fresh reviewer with no context on the implementation, adversarially checking the diff. It found something real: two of the new whole-scan indices (struct field types, and package-level/struct-field bindings) were keyed by bare name across the entire scan, not scoped to a package. Go allows two completely unrelated packages to each declare their own Service struct with their own Client field — and a genuinely-bound client in one package would have incorrectly matched a same-named, unconnected field in a totally different package.

That’s exactly the class of false positive our whole identity model exists to prevent, and it slipped through the first pass. We fixed it by partitioning every whole-scan index by package — matching how an unqualified identifier is only ever visible within its own package in real Go anyway — added regression fixtures reproducing the exact collision, and re-verified against all three real repos to confirm detection was unaffected by the fix.

Verifying against the real repos, again

After the fix, we re-cloned and re-scanned the same repos:

$ flaglint-go audit ./ld-sample-app-go
Scan complete — 1 unique flag(s) across 1 call site(s) (3 file(s))
Migration readiness: 100/100 · ready
  1 low risk · 0 medium risk · 0 high risk

$ flaglint-go audit ./weaviate
Scan complete — 0 unique flag(s) across 4 call site(s) (4512 file(s))
Migration readiness: 0/100 · complex
  0 low risk · 0 medium risk · 4 high risk

weaviate’s four call sites all show as high-risk dynamic keys — correctly so, since the flag key there (f.key) is a runtime struct field, not a string literal. That’s the honest answer, not a false claim of full static resolution.

What’s still not covered

We’re not going to pretend this closes every gap. e2b-dev/infra’s usage is still undetected — it takes a bound client’s method value and passes it through a generic helper function, which is a genuinely harder problem (interprocedural data-flow, not just “look at more files”). That, along with a handful of narrower gaps found along the way, is filed as tracked, public issues rather than silently swept under the rug — see the Supported Scope and Limitations pages for the full, honest list.

Get started

brew install flaglint/tap/flaglint-go
flaglint-go audit ./services

• Quickstart
• Identity Model — the full design behind all of the above
• Enforce in CI

Tags:

• golang
• launchdarkly
• cli
• static-analysis
• open-source

LaunchDarkly Feature Flag Cleanup: Audit, Rewrite, and Enforce in TypeScript

Jul 6, 2026 - 5 min read

Your codebase has been accumulating direct LaunchDarkly SDK calls for years. The team knows a cleanup is overdue, but nobody has a clear picture of how many flag keys exist, which ones are safely automatable, and which ones will bite you if touched carelessly. LaunchDarkly’s built-in cleanup tooling — Vega — requires an Enterprise subscription. Grep finds string literals but misses dynamic keys, detail evaluations, and bulk calls. You end up either doing nothing or hand-editing files one at a time and hoping the argument order is correct.

FlagLint is a free, open-source CLI that automates LaunchDarkly feature flag cleanup in TypeScript and JavaScript codebases using AST-based static analysis — not regex — to classify every direct LaunchDarkly SDK call by risk, generate a readable flag debt inventory, rewrite safe call sites to the OpenFeature standard, and enforce the resulting boundary in CI. No LaunchDarkly API key required.

This guide walks through a complete cleanup cycle: audit → rewrite → enforce.

Step 1: Audit your flag debt

The first step of any LaunchDarkly feature flag cleanup is understanding what you are dealing with. Run flaglint audit against your source directory:

npx flaglint audit ./src

Here is the real output for a two-file Node.js service with seven flag evaluations across checkout and pricing modules:

- Auditing ./src...
# FlagLint Audit Report

**Scanned at:** 2026-07-06T04:47:44.977Z
**Scan root:** ./src
**Files scanned:** 2
**Duration:** 35ms

## Summary

| Total Flags | High Risk | Medium Risk | Total Usages |
|-------------|-----------|-------------|--------------|
| 7 | 2 | 5 | 7 |

| Dynamic Keys | Detail Evals | Bulk Calls | Stale Signals | Safely Automatable | Manual Review |
|--------------|--------------|------------|---------------|-------------------|---------------|
| 1 | 1 | 0 | 0 | 5 | 2 |

> **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: **71/100** · moderate

[██████████████████░░░░░░░] 71%

5 safely automatable  ·  2 require manual review

## Flag Debt Inventory

| Flag Key | Risk | Usages | Files | Call Types | Reasons |
|----------|------|--------|-------|------------|---------|
| `<dynamic key>` | 🔴 High | 1 | 1 | numberVariation | dynamic key |
| `beta-pricing` | 🔴 High | 1 | 1 | boolVariationDetail | detail evaluation |
| `checkout-v2` | 🟢 Automatable | 1 | 1 | boolVariation | safely automatable |
| `discount-percentage` | 🟢 Automatable | 1 | 1 | numberVariation | safely automatable |
| `ui-theme` | 🟢 Automatable | 1 | 1 | stringVariation | safely automatable |
| `checkout-config` | 🟡 Medium | 1 | 1 | jsonVariation | safely automatable, json variation |
| `promo-banner` | 🟢 Automatable | 1 | 1 | boolVariation | safely automatable |

## Next Steps

- Run `flaglint migrate --dry-run` to preview safe OpenFeature rewrites
- Run `flaglint validate --no-direct-launchdarkly` to enforce OF boundary in CI
- Review HIGH risk flags manually before any automated migration

✓ Audit complete: 7 flags — 2 high risk, 5 medium risk (35ms, 2 files)

Migration readiness: 71/100  ·  moderate
[██████████████████░░░░░░░] 71%
5 safely automatable  ·  2 require manual review

The readiness score of 71/100 means 5 of 7 call sites can be rewritten automatically. The two high-risk entries need manual attention before anything else moves.

Add --format html --output flag-debt.html to produce a shareable report to attach to a migration planning ticket. The flag debt blog post covers the full range of audit options including effort estimates.

What the flag debt inventory is telling you

Two call types are classified as high risk:

Dynamic key (<dynamic key>) — the flag key is constructed at runtime from a variable or template literal (e.g., const key = `pricing-${plan}`). FlagLint cannot resolve which flag is actually evaluated at any given call site. Any automated rewrite here would silently touch the wrong call. These require a human decision: extract the dynamic key into a lookup table, split into separate static flag keys, or handle manually per call type.

Detail evaluation (beta-pricing via boolVariationDetail) — variationDetail returns a reason object with no direct OpenFeature equivalent. FlagLint skips these by design. You need to decide whether that reason metadata is still needed after migration, and if so, which OpenFeature detail API maps to your use case.

The five remaining call sites — boolVariation, numberVariation, stringVariation, jsonVariation, and a second boolVariation — are all safely automatable. FlagLint can rewrite every one of them without you touching a line.

Step 2: Preview the safe rewrites

Run flaglint migrate with --dry-run to see exactly what changes before any file is modified:

npx flaglint migrate ./src --dry-run

Real output (provider setup guidance section omitted; covered in Step 3 below):

- Scanning ./src...
LaunchDarkly usages found: 7
Safely automatable: 5 · Manual review: 2

Reviewable diffs: 5
Diffs requiring provider setup: 5
Skipped usages: 2

## Diffs
diff --git a/checkout.ts b/checkout.ts
--- a/checkout.ts
+++ b/checkout.ts
@@ -8,1 +8,1 @@
-  const newCheckoutEnabled = await ldClient.boolVariation("checkout-v2", ctx, false);
+  const newCheckoutEnabled = await openFeatureClient.getBooleanValue("checkout-v2", false, ctx);
@@ -9,1 +9,1 @@
-  const discountPct = await ldClient.numberVariation("discount-percentage", ctx, 0);
+  const discountPct = await openFeatureClient.getNumberValue("discount-percentage", 0, ctx);
@@ -10,1 +10,1 @@
-  const theme = await ldClient.stringVariation("ui-theme", ctx, "default");
+  const theme = await openFeatureClient.getStringValue("ui-theme", "default", ctx);
@@ -11,1 +11,1 @@
-  const config = await ldClient.jsonVariation("checkout-config", ctx, {});
+  const config = await openFeatureClient.getObjectValue("checkout-config", {}, ctx);

diff --git a/pricing.ts b/pricing.ts
--- a/pricing.ts
+++ b/pricing.ts
@@ -10,1 +10,1 @@
-  const promoEnabled = await ldClient.boolVariation("promo-banner", ctx, false);
+  const promoEnabled = await openFeatureClient.getBooleanValue("promo-banner", false, ctx);

## Skipped Usages
- pricing.ts:9:26 — `dynamicKey` via `numberVariation`: dynamic key requires manual review
- pricing.ts:11:23 — `beta-pricing` via `boolVariationDetail`: detail methods skipped:
  OpenFeature detail APIs exist, but LaunchDarkly/OpenFeature detail result parity requires
  manual review

Notice the argument order flip: boolVariation("checkout-v2", ctx, false) becomes getBooleanValue("checkout-v2", false, ctx). The LaunchDarkly SDK puts context second and default last; OpenFeature reverses that. This reversed argument order is the most common source of silent production bugs in manual migrations — FlagLint handles it correctly for every safe call type.

The jsonVariation → getObjectValue rewrite is flagged json variation in the audit because OpenFeature’s JSON type is object. If your LaunchDarkly flag ever returns a primitive JSON value (number, string, boolean, null), call semantics differ. Review before applying.

The two skipped usages are left exactly as-is in source.

Step 3: Wire the OpenFeature provider

The dry-run output marks all five diffs as requiring provider setup. The LaunchDarkly SDK stays as your evaluation backend — you are changing the API your application code calls, not where flags are stored or evaluated.

Install once:

npm install @openfeature/server-sdk \
            @launchdarkly/node-server-sdk \
            @launchdarkly/openfeature-node-server

Add a bootstrap file at application startup. Do not remove existing LaunchDarkly packages — the OpenFeature provider depends on them at runtime:

import { OpenFeature } from "@openfeature/server-sdk";
import { LaunchDarklyProvider } from "@launchdarkly/openfeature-node-server";

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

export const openFeatureClient = OpenFeature.getClient();

Import openFeatureClient in every module that has call sites in the migration plan, or configure openFeatureClientBindings in your .flaglintrc so FlagLint locates the client binding automatically. The add OpenFeature provider tutorial covers both approaches with full examples.

Step 4: Apply the safe rewrites

Once the OpenFeature provider is wired:

npx flaglint migrate ./src --apply

FlagLint rewrites only the five safely automatable call sites and leaves the two high-risk ones untouched. What you get is an ordinary git diff: five function-call replacements across two files, reviewable like any other PR. The dynamic key and detail evaluation remain as direct LaunchDarkly SDK calls until you handle them manually.

Step 5: Enforce the boundary in CI

After --apply and manual resolution of the remaining two call sites, lock the boundary so no new direct LaunchDarkly SDK calls can reach main:

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

If you are mid-cleanup and cannot enforce a hard block yet, use baseline mode: it freezes existing flag debt and fails on any net-new addition.

# Write current findings as the accepted baseline
npx flaglint audit ./src --write-baseline .flaglint-baseline.json

# In CI: fail only on findings not present in the baseline
npx flaglint validate ./src \
  --no-direct-launchdarkly \
  --baseline .flaglint-baseline.json \
  --fail-on-new

Commit .flaglint-baseline.json to source control. Each time you resolve a flag through migrate --apply or a manual cleanup, re-run --write-baseline to shrink the accepted set. The GitHub Actions integration guide shows the full CI step configuration, including SARIF upload for GitHub Code Scanning annotations.

Doing this at monorepo scale

If your LaunchDarkly SDK calls are spread across multiple packages, run the three commands per package rather than at the repo root. Each package can have its own .flaglintrc pointing to its local OpenFeature client binding. The monorepo guide covers per-package configuration and how to sequence the cleanup when the same flag key is evaluated in shared libraries and consumer apps simultaneously.

Summary

LaunchDarkly feature flag cleanup at the code level breaks into four repeatable steps:

1. flaglint audit ./src — inventory your flag debt and get a readiness score
2. flaglint migrate ./src --dry-run — review the migration plan before touching files
3. flaglint migrate ./src --apply — apply safe rewrites; fix the remaining two manually
4. flaglint validate ./src --no-direct-launchdarkly — gate the boundary in CI

No Enterprise subscription, no API key, no manual grep. The complete six-step migration walkthrough picks up from here if you want to see the full picture across a production Node.js service.

FlagLint Is Now Installable via Homebrew

Jul 5, 2026 - 2 min read

Krishan Sharma

Founder and maintainer of FlagLint

Starting with v1.1.0, FlagLint is installable via Homebrew — no Node.js required.

brew tap flaglint/tap
brew install flaglint

That’s it. The full CLI is available immediately, including audit, scan, migrate, and validate.

Why this matters

Until now, the only install paths were npm install -g flaglint or npx flaglint@latest. Both work fine — but both require Node.js 20 or newer. That’s a reasonable assumption for application developers, but it’s a friction point in a few common situations.

DevOps and platform engineers often run tooling audits across repos without a Node.js environment set up. Installing Node just to run one CLI is the kind of thing that gets a tool skipped in favour of whatever’s already available.

Docker-based CI is the bigger one. A lot of teams run their CI in minimal images — no Node, no npm. Adding a Node install step purely to run npx flaglint adds 30-60 seconds to every pipeline run and pulls in a dependency that has nothing to do with the actual application. With Homebrew, a Linux CI job can install FlagLint in a single brew install call with no Node dependency.

Mac developers who use Homebrew for CLI tools now get brew upgrade flaglint like any other tool, without thinking about npm.

How the tap works

The tap lives at github.com/flaglint/homebrew-tap. The formula fetches the published npm tarball directly from the npm registry and wires up the CLI binary.

The formula updates automatically on every release — a GitHub Actions job in the main repo runs after each npm publish, computes the new tarball SHA256, and commits an updated formula to the tap. So brew upgrade flaglint will always pull the current release without any manual intervention.

Getting started

brew tap flaglint/tap
brew install flaglint
flaglint --version

Or if you already have Node.js, npx flaglint@latest still works exactly as before. The Homebrew path is an addition, not a replacement.

Once installed, the quickstart walks through the full audit → preview → apply workflow.

Tags:

• homebrew
• cli
• install
• devops
• nodejs

FlagLint Is Now Listed on the OpenFeature Ecosystem

Jul 5, 2026 - 2 min read

Krishan Sharma

Founder and maintainer of FlagLint

FlagLint is now listed in the OpenFeature ecosystem directory as one of two integrations in the JavaScript/Server category.

I want to be straightforward about what that means — and what it doesn’t.

What the listing is

The OpenFeature ecosystem is a directory maintained by the OpenFeature project (a CNCF incubating standard) where providers, SDKs, hooks, and integrations can be listed. It is not an award or a certification. It is a discovery page. Teams that are already evaluating OpenFeature — researching providers, looking for tooling, trying to understand the ecosystem — land there.

Being listed means that those teams will now find FlagLint when they filter for integrations. That matters because the people who need FlagLint most are exactly the people who are actively thinking about OpenFeature.

Why I submitted

The OpenFeature standard is the reason FlagLint exists. The whole problem FlagLint solves — the argument-order inversion between LaunchDarkly’s boolVariation(key, ctx, default) and OpenFeature’s getBooleanValue(key, default, ctx) — only surfaces when you are trying to move to OpenFeature. If teams weren’t adopting OpenFeature, there would be no migration to get wrong.

So it made sense to be in the directory where those teams are looking. Not to market FlagLint as a product, but to be findable at the point in the journey where someone is asking “what tooling exists around OpenFeature for LaunchDarkly migration?”

What FlagLint does in the context of OpenFeature

FlagLint is not an OpenFeature SDK or provider. It doesn’t evaluate flags. What it does is sit at the boundary between your existing LaunchDarkly codebase and the OpenFeature world you’re moving toward.

Specifically:

• Audit — inventory every direct LaunchDarkly SDK call, classify each one by migration risk, produce a readiness score
• Migrate — preview and apply proven-safe call-site rewrites that transpose arguments correctly and rename methods atomically
• Validate — enforce in CI that no new direct LaunchDarkly calls land once you’ve drawn the boundary

None of that requires a network connection, an API key, or access to your LaunchDarkly environment. It’s all static analysis on your source code, running locally.

Where to start

If you’re in the process of moving to OpenFeature and want to understand your current exposure before touching any code, the audit command is the right starting point.

npx flaglint@latest audit ./src

It runs in under a minute on most codebases and doesn’t touch any files.

Tags:

• openfeature
• launchdarkly
• ecosystem
• cncf
• migration

Older posts