Migrate a Node.js application from LaunchDarkly SDK to OpenFeature SDK
node-server-sdk
across your project. Ignore search results in package.json and package manager lock files. What you’re looking for are usages in import or require statements inside your .js and .ts files, such as this:
LaunchDarkly
import inside every file where this import is present. You’re looking for a statement that creates a LaunchDarkly client:
ldClient
. This will give you the list of all LaunchDarkly client API calls that are responsible for getting values of specific feature flags. For example, this is what you’d see if you invoke JetBrains WebStorm’s Show Usages command on ldClient
:
ldClient
:
key
property in the context object, you need to use targetingKey
with the OpenFeature SDK.
LaunchDarkly SDK:
waitForInitialization()
call:
boolVariation()
call using a then()
call:
boolVariation()
, there are two more LaunchDarkly client functions that you may be using with boolean flags: variation()
and boolVariationDetail()
.
variation()
is just a more generic function that you can use to get flag values of any type:
boolVariationDetail()
is a function that returns an object that contains both the flag value and additional metadata: the reason of the flag being in a particular value and the variation index:
getBooleanValue()
and getBooleanDetails()
. Note that it doesn’t provide the equivalent of LaunchDarkly SDKs general-purpose variation()
function. This means that when migrating, you’ll need to choose a function corresponding to the specific type of flag you’re using.
To sum it up, below are code snippets representing the usage of the three LaunchDarkly SDKs functions that you can use to get boolean flag values, along with the OpenFeature SDK code that you’d end up with after migration.
When migrating a boolVariation()
call,
variation()
call,
boolVariationDetail()
call,
FlagEvaluationOptions
, but it’s optional and for the purposes of migration, you should just omit it.variation()
function, or fetch string flags along with their associated details using stringVariationDetail()
.
When migrating a stringVariation()
call,
variation()
call,
stringVariationDetail()
call,
variation()
function is also available for fetching number flags, as well as the numberVariationDetail()
function for fetching number flag details.
When migrating a numberVariation()
call,
variation()
call,
numberVariationDetail()
call,
jsonVariation()
, a specialized function for fetching JSON flags.variation()
, a general-purpose function that can be used to fetch all types of flags, including JSON flags.jsonVariationDetail()
, a function that fetches JSON flags along with their associated metadata.jsonVariation()
call to the OpenFeature SDK,
variation()
call,
jsonVariationDetail()
call,
on()
method that you call on the client instance, like this:
ready
, failed
, error
, update
, and update:key
.
ready
and failed
events are only fired once, as a result of the client initialization. You can wrap the await ldClient.waitForInitialization()
call in a try/catch block instead of listening to these two events. However, if you are listening to them explicitly, then your ready
listener when using the LaunchDarkly SDK looks like this:
addHandler()
function for event listening, don’t forget to extend your OpenFeature SDK import statement to include the ProviderEvents
enum:
failed
event listener:
failed
event, so if you want to handle a permanent client error in connecting to LaunchDarkly, you should do it in the catch clause of the try/catch block around the OpenFeature client initialization call:
error
event that signals an abnormal condition when the client is working:
update
and update:key
. The former enables listening to configuration changes affecting any flag:
update:key
listener is more specific and serves to receive configuration updates affecting a single flag that you identify by its key:
update:key
. You can only listen to configuration changes affecting any flags, and here’s how you do it:
client.getStringValue()
, client.getBooleanValue()
, etc. This doesn’t play well with the fact that OpenFeature SDK only provides a generic event update listener. When you receive an updated configuration event, you need to look up its type by key, and depending on the result, call a type-specific function. Here’s what this may look like in practice:
@launchdarkly/node-server-sdk
—by removing it from package.json and running your package manager’s install command.