LaunchDarkly OpenFeature Provider for the Node.js Server-Side SDK

This package provides an OpenFeature provider that wraps the LaunchDarkly Server-Side SDK for Node.js.

This provider is designed primarily for use in multi-user systems such as web servers and applications. It is not intended for use in desktop and embedded systems applications.

Supported Node versions

This version of the LaunchDarkly OpenFeature provider is compatible with Node.js versions 20 and above.

Feature matrix

This matrix mirrors the feature matrix of the OpenFeature SDK for JavaScript and describes what this provider supports. Rows which are not supported state whether the limitation comes from the OpenFeature JavaScript SDK or from the provider.

| Status | Feature | Notes | | ------ | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ✅ | Providers | Evaluates boolean, string, number, and object flags through the LaunchDarkly Node.js SDK. | | ✅ | Targeting | The EvaluationContext is converted to a LaunchDarkly single or multi-context. See OpenFeature Specific Considerations. | | ✅ | Hooks | Hooks are registered on the OpenFeature API and client; the provider requires no additional support and its results are visible to hooks, including flag metadata. | | ✅ | Logging | The provider logs through the logging configuration of the LDOptions it is given. | | ✅ | Domains | Domains bind clients to providers in the OpenFeature SDK; a separate provider instance may be registered per domain. The provider is not domain-scoped, so one instance may also be shared by several domains. | | ⚠️ | Eventing | Only ConfigurationChanged is emitted; this provider never emits Error or Stale because the underlying LaunchDarkly Node.js SDK has no data source status API. This is a limitation of the provider's underlying SDK, not the OpenFeature SDK: #1886. | | ✅ | Transaction Context Propagation | Provided by the OpenFeature SDK, which merges the transaction context into the evaluation context before the provider is called; no provider support is required. | | ✅ | Tracking | track sends a LaunchDarkly custom event for the evaluation context, with the tracking event value and remaining details attached. | | ✅ | Initialization | initialize waits for the LaunchDarkly client with the initTimeoutSeconds constructor parameter, which defaults to 10 seconds. Zero does not wait, so readiness is reported through provider events, and 'forever' waits indefinitely. | | ✅ | Shutdown | onClose flushes and closes the LaunchDarkly client. A closed client cannot be restarted, so a new provider instance is required afterward. | | ✅ | Extending | The underlying LaunchDarkly client is available through getClient() for functionality with no OpenFeature equivalent. | | ✅ | Multi-Provider | Provided by the OpenFeature SDK; no provider support is required. | | ✅ | Flag metadata | LaunchDarkly evaluation reason details are returned as OpenFeature flag metadata. See Flag Metadata. |

Supported: ✅ | Partially supported: ⚠️ | Not supported: ❌

Installation

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

Usage

import { OpenFeature, ProviderEvents } from '@openfeature/server-sdk';
import { LaunchDarklyProvider } from '@launchdarkly/openfeature-node-server';

// The optional third parameter controls how long to wait for initialization (default: 10 seconds).
const provider = new LaunchDarklyProvider('your-sdk-key', {/* LDOptions here */});

// setProviderAndWait throws if initialization fails; catch as needed.
await OpenFeature.setProviderAndWait(provider);

// Access the underlying LDClient directly if needed.
const ldClient = provider.getClient();

const client = OpenFeature.getClient();
const flagValue = await client.getBooleanValue('flag-key', false, {
  targetingKey: 'user-key',
});

// The provider emits ConfigurationChanged for each flag key that may have changed.
// Each event contains a single key in the flagsChanged array.
OpenFeature.addHandler(ProviderEvents.ConfigurationChanged, (eventDetails) => {
  console.log(`Changed: ${eventDetails.flagsChanged}`);
});

// Calling close() flushes SDK events - useful for short-lived processes.
await OpenFeature.close();

Provider Events

The provider emits ConfigurationChanged when flag data changes.

It does not report the state of the connection to LaunchDarkly, so it never emits ProviderEvents.Error or ProviderEvents.Stale, and its status remains READY after a successful start even if the connection is later lost. Applications which need to react to connection problems can listen to the events of the LaunchDarkly Node.js SDK client returned by getClient().

Reporting connection state requires a data source status API in the LaunchDarkly Node.js SDK, which the other LaunchDarkly server-side SDKs provide and this one does not yet.

OpenFeature Specific Considerations

LaunchDarkly evaluates contexts, and it can either evaluate a single-context or a multi-context. When using OpenFeature, both single and multi-contexts must be encoded into a single EvaluationContext. This is accomplished by looking for an attribute named kind in the EvaluationContext.

There are 4 different scenarios related to the kind:

1. There is no kind attribute. The provider will treat the context as a single context of kind "user".
2. There is a kind attribute with the value "multi". The provider will treat the context as a multi-context.
3. There is a kind attribute with a string value other than "multi". The provider will treat it as a single context of the specified kind.
4. There is a kind attribute, but its value is not a string. The value will be discarded, the context will be treated as kind "user", and a warning will be logged.

The kind attribute should be a string containing only ASCII letters, numbers, ., _, or -.

The OpenFeature specification allows for an optional targeting key, but LaunchDarkly requires a key for evaluation. A targeting key must be specified for each context being evaluated. It may be specified using either targetingKey, as defined in the OpenFeature specification, or key, which is the typical LaunchDarkly identifier. If both are specified, targetingKey takes precedence.

There are several attributes with special handling within a single or multi-context:

• privateAttributes - Must be an array of strings. Equivalent to _meta.privateAttributes in the SDK.
• anonymous - Must be a boolean. Equivalent to anonymous in the SDK.
• name - Must be a string. Equivalent to name in the SDK.

Flag Metadata

Evaluation results include LaunchDarkly specific information in the OpenFeature flag metadata. A key is only present when it applies to the evaluation.

| Key | Type | Description | | ------------------- | ------- | ------------------------------------------------------------------------------ | | variationIndex | number | The index of the served variation. Absent when the default value was returned. | | inExperiment | boolean | Present, and true, when the evaluation was part of an experiment. | | ruleIndex | number | The index of the matched rule, for a RULE_MATCH reason. | | ruleId | string | The identifier of the matched rule, for a RULE_MATCH reason. | | prerequisiteKey | string | The key of the failed prerequisite flag, for a PREREQUISITE_FAILED reason. | | bigSegmentsStatus | string | The status of the Big Segment query, when the evaluation required one. |

const details = await client.getBooleanDetails('my-boolean-flag', false);
const inExperiment = details.flagMetadata.inExperiment === true;

Examples

A single user context

const evaluationContext = {
  targetingKey: 'my-user-key',
};

A single context of kind "organization"

const evaluationContext = {
  kind: 'organization',
  targetingKey: 'my-org-key',
};

A multi-context containing a "user" and an "organization"

const evaluationContext = {
  kind: 'multi',
  organization: {
    targetingKey: 'my-org-key',
    myCustomAttribute: 'myAttributeValue',
  },
  user: {
    targetingKey: 'my-user-key',
  },
};

Setting private attributes in a single context

const evaluationContext = {
  kind: 'organization',
  name: 'the-org-name',
  targetingKey: 'my-org-key',
  myCustomAttribute: 'myCustomValue',
  privateAttributes: ['myCustomAttribute'],
};

Setting private attributes in a multi-context

const evaluationContext = {
  kind: 'multi',
  organization: {
    targetingKey: 'my-org-key',
    name: 'the-org-name',
    // privateAttributes only applies to the "organization" context.
    privateAttributes: ['myCustomAttribute'],
    // This attribute will be private.
    myCustomAttribute: 'myAttributeValue',
  },
  user: {
    targetingKey: 'my-user-key',
    anonymous: true,
    // This attribute will not be private.
    myCustomAttribute: 'myAttributeValue',
  },
};

Contributing

See Contributing.

Verifying SDK build provenance with the SLSA framework

LaunchDarkly uses the SLSA framework (Supply-chain Levels for Software Artifacts) to help developers make their supply chain more secure by ensuring the authenticity and build integrity of our published SDK packages. To learn more, see the provenance guide.

About LaunchDarkly

• LaunchDarkly is a continuous delivery platform that provides feature flags as a service and allows developers to iterate quickly and safely. We allow you to easily flag your features and manage them from the LaunchDarkly dashboard. With LaunchDarkly, you can:
  • Roll out a new feature to a subset of your users (like a group of users who opt-in to a beta tester group), gathering feedback and bug reports from real-world use cases.
  • Gradually roll out a feature to an increasing percentage of users, and track the effect that the feature has on key metrics (for instance, how likely is a user to complete a purchase if they have feature A versus feature B?).
  • Turn off a feature that you realize is causing performance problems in production, without needing to re-deploy, or even restart the application with a changed configuration file.
  • Grant access to certain features based on user attributes, like payment plan (eg: users on the 'gold' plan get access to more features than users in the 'silver' plan).
  • Disable parts of your application to facilitate maintenance, without taking everything offline.
• LaunchDarkly provides feature flag SDKs for a wide variety of languages and technologies. Check out our documentation for a complete list.
• Explore LaunchDarkly
  • launchdarkly.com for more information
  • docs.launchdarkly.com for our documentation and SDK reference guides
  • apidocs.launchdarkly.com for our API documentation
  • blog.launchdarkly.com for the latest product updates