JavaScript SDK 3.x to 4.0 migration guide | LaunchDarkly

Overview

This topic explains the changes in the JavaScript SDK 4.0 release and how to adapt code that uses a 3.x version of the JavaScript SDK to use version 4.0 or later.

Version 4.0 includes several breaking changes. Before you migrate to version 4.0, update to the latest 3.x version. If you update to the latest 3.x version, deprecation warnings appear in areas of your code that need to be changed for 4.0. You can update them at your own pace while still using 3.x, rather than migrating everything simultaneously. To learn more about updating to the latest 3.x version, visit the SDK’s GitHub repository.

Package name and location changes

In v4.0 of the SDK, the node module is now named @launchdarkly/js-client-sdk. To begin the migration, install the new package and swap all references from launchdarkly-js-client-sdk to @launchdarkly/js-client-sdk.

Client initialization

In v4.0 of the SDK, client initialization has changed in the following ways:

The initialize method was removed.
Initialization is now split into two parts: createClient and start.
LDOptions, which was formerly passed into the initialize() function, is now split into two types: LDStartOptions and LDOptions. To learn more, read Changes to LDOptions.

This two-step process ensures that you can register all event listeners and perform any necessary setup before the client begins connecting to LaunchDarkly. This eliminates race conditions where events might be missed if listeners were registered after the client had already started initializing.

Here is the new client initialization method:

1   import { createClient } from '@launchdarkly/js-client-sdk';
2 
3   // Create client
4   const client = createClient('example-client-side-id', context, options);
5 
6   // Then start the client
7   client.start();

Client initialization flow

In v4.0 of the SDK, client initialization flow has changed in the following ways:

In v4.0 the waitForInitialization() method returns a result object instead of rejecting promises. The v3.x waitUntilReady() method has been removed.
waitForInitialization() now always resolves, never rejects, and returns a result object with a status field.
timeout is now specified as an option object, { timeout: 5 }, instead of a direct parameter
The result object allows you to handle all cases, including success, failure, and timeout, without try/catch.

Here is the new client initialization flow:

1   // Recommended: Using waitForInitialization (always resolves with status)
2   const result = await client.waitForInitialization({ timeout: 5 });
3 
4   if (result.status === 'complete') {
5   // Client initialized successfully
6   } else if (result.status === 'failed') {
7   // Client failed to initialize
8   console.error('Initialization failed:', result.error);
9   } else if (result.status === 'timeout') {
10   // Initialization timed out
11   console.error('Initialization timed out');
12   }
13 
14   // Note: Events still work if you prefer that approach
15   client.on('ready', () => {
16   // Client is ready (success or failure)
17   });
18   client.on('initialized', () => {
19   // Client initialized successfully
20   });
21   client.on('failed', (err) => {
22   // Client failed to initialize
23   });

Changes to LDOptions

In v4.0 of the SDK, LDOptions has changed in the following ways:

The bootstrap option moved from LDOptions to LDStartOptions and identify. Bootstrapping data is now part of the initialization of a client instance. identify is a key part of the client initialization process required to associate the instance with an initial context.
The SDK now defaults to using local storage-based caching. Previously, to enable local storage caching, you needed to set this as a special value for the bootstrap property.
Version 3.x of the SDK used the streamUrl, baseUrl, and eventsUrl properties to specify the base URIs for alternative service endpoints. Version 4.0 of the JavaScript SDK uses the streamUri, baseUri, and eventsUri properties to specify the base URIs for alternative service endpoints.

To learn more, read the following SDK documentation:

Report changes

In the JavaScript SDK v3.x and earlier, if you used REPORT, enabled the useReport configuration option, and wanted to use streaming, then you had to use use the LaunchDarkly EventSource polyfill.

The JavaScript SDK v4.0 supports REPORT directly. If you enable the useReport configuration option, no polyfill or additional configuration is required.

Flag evaluation now has typed methods

The variation method lets you evaluate a feature flag. The variationDetail method lets you evaluate a feature flag while providing more information about how the value was calculated.

In v4.0 of the SDK, you can also use typed methods. These methods include:

boolVariationDetail for boolean flags.
numberVariationDetail for number flags.
stringVariationDetail for string flags.
jsonVariationDetail for JSON flags.

To learn more about the *variationDetail methods, read LDEvaluationDetail. To learn more about the configuration option, read evaluationReasons.

Analytics events changes

In v4.0 of the SDK, the allFlags() method no longer sends analytics events by default.

To learn more, read Getting all flags.

Flag listener changes

In v4.0 of the SDK, flag listeners have changed in the following ways:

The change event listener now receives (context, changedFlagKeys), where changedFlagKeys is an array of strings. The SDK no longer returns the flag value object along with this event.
The event does not include flag values. You must call variation() to get the current value.
change:<flag-key> event listener now only receives (context).

Here is the new flag listener method:

1 // General change event - fires when any flags change
2 client.on('change', (context, changedFlagKeys) => {
3   // context: The LDContext for which flags changed
4   // changedFlagKeys: Array of flag keys that changed
5 
6   // Still need to call variation() to get current values
7   changedFlagKeys.forEach(flagKey => {
8     const flagValue = client.variation(flagKey, defaultValue);
9   });
10 });
11 
12 // Specific flag change event - fires when a specific flag changes
13 client.on('change:my-flag', (context) => {
14   // Only fires when 'my-flag' changes
15   const flagValue = client.variation('my-flag', false);
16 });

Error event handling changes

The new SDK has changed how errors are logged when error event listeners are present.

In v3.x of the SDK, the maybeReportError function would check if there was an error listener:

If an error listener was registered, the error event was emitted but not logged to the console
If no error listener was registered, the error was logged to the console

This meant that if you wanted to handle errors yourself, you wouldn’t get duplicate error logs.

In v4.0 of the SDK, the client always registers a default error listener that logs errors via the logger. This means:

Errors are always logged using the logger, even if you have your own error listeners
Your error listeners will still receive the error events
You may see duplicate error logs if you’re also logging errors in your error handler

The new error handling process allows for more robust control over what errors are ignored. This avoids not logging or informing end users when an unhandled error happens. Our recommendation is to implement LDLogger for your client to suppress handled errors.

Addition of data sources

Version 4.0 of the SDK adds the change, error, and dataSourceStatus methods to subscribe to events. When you subscribe to dataSourceStatus events, the state returned may be one of Initializing, Valid, Interrupted, SetOffline, Closed.

To learn more, read Monitoring SDK status.

Understanding what was deprecated

All types and methods that were marked as deprecated in the last 3.x release have been removed from the 4.0 release. If you were using a recent 3.x version, you should already have received compile-time deprecation warnings with suggestions for their recommended replacements.

For a full list of deprecated types and methods, read the release notes in GitHub.