Why FlagLint
FlagLint is for teams that already have LaunchDarkly Node.js server-side evaluation calls in application code and want to standardize new application code on OpenFeature without changing providers on day one.
The Problem
Section titled “The Problem”Direct SDK evaluation calls spread vendor-specific access patterns across services:
return ldClient.boolVariation("checkout-v2", ctx, false);That makes standardization hard because each service needs an inventory, a reviewed migration plan, a guarded rewrite path, and CI enforcement so direct SDK usage does not return.
What FlagLint Provides
Section titled “What FlagLint Provides”- AST-based inventory of supported LaunchDarkly Node.js server SDK evaluations.
- Migration plans that separate proven rewrites from manual-review cases.
- Guarded
migrate --applyfor call sites with static keys, known fallback types, context, and a proven OpenFeature client binding. validate --no-direct-launchdarklyfor CI policy enforcement and SARIF annotations.
What FlagLint Does Not Claim
Section titled “What FlagLint Does Not Claim”FlagLint does not identify production-stale flags. It does not query LaunchDarkly for age, ownership, evaluation history, environment configuration, or production usage. Local review signals are source-level hints, not proof that a production flag is stale.
FlagLint also does not detect browser SDKs, React SDKs, non-Node SDKs, or non-LaunchDarkly providers.
Provider Architecture
Section titled “Provider Architecture”Application code -> OpenFeature client -> LaunchDarkly OpenFeature provider -> LaunchDarklyLaunchDarkly remains the provider. OpenFeature becomes the application-facing evaluation API.
Ready to try it? Run your first audit in 2 minutes → Quickstart