2.5.0

[2.5.0] - 2018-08-27

Changed:

• Starting in version 2.0.0, there was a problem where analytics events would not be generated correctly if you initialized the client with bootstrap data, because the bootstrap data did not include some flag metadata that the front end uses for events. The client now supports an extended format for bootstrap data that fixes this problem; this is generated by calling a new method that has been added to the server-side SDKs, allFlagsState/all_flags_state (previously allFlags/all_flags). Therefore, if you want analytics event data and you are using bootstrap data from the back end, you should upgrade both your JavaScript SDK and your server-side SDK, and use allFlagsState on the back end. This does not require any changes in your JavaScript code. If you use bootstrap data in the old format, the SDK will still be usable but events will not work correctly.
• When posting events to LaunchDarkly, if a request fails, it will be retried once.
• The TypeScript mappings for the SDK were omitted from the distribution in the previous release. They are now in the distribution again, in the root folder instead of in src, and have been renamed from index.d.ts to typings.d.ts.

2.4.1

[2.4.1] - 2018-08-14

Fixed:

• The result value of identify() (provided by either a promise or a callback, once the flag values for the new user have been retrieved) used to be a simple map of flag keys to values, until it was accidentally changed to an internal data structure in version 2.0.0. It is now a map of flag keys to values again, consistent with what is returned by allFlags().
• Added TypeScript definitions for the result values of identify(). (Thanks, 1999!)
• Documented all optional compatibility polyfills in README.md.

2.4.0

[2.4.0] - 2018-07-12

Added:

• Named exports for the initialize method and version number exports.

Deprecated:

• Default exports, use named exports instead.

Changed:

• Updated package.json to only export minified files.

2.3.1

[2.3.1] - 2018-06-29

Fixed:

• If a polling request has failed due to an invalid environment key, calling variation now returns the default value; previously, it sometimes caused a null reference error.

2.3.0

[2.3.0] - 2018-06-26

Changed:

The client will now stop trying to send analytics events if it receives almost any HTTP 4xx error from LaunchDarkly; such errors indicate either a configuration problem (invalid SDK key) or a bug, which is not likely to resolve without a restart or an upgrade. This does not apply if the error is 400, 408, or 429.

2.2.0

[2.2.0] - 2018-06-22

Added:

• New event goalsReady (and new method waitUntilGoalsReady, which returns a Promise based on that event) indicates when the client has loaded goals-- i.e. when it is possible for pageview events and click events to be triggered.

Fixed:

• Fixed a bug where calling variation would throw an error if the client was bootstrapped from local storage and there were no flags in local storage yet, and the initial HTTP request for flags from LaunchDarkly had not yet completed. (thanks, mpcowan!)

2.1.2

Fixed:

• Fix the TypeScript definitions to properly support the ES default export.

Changelog

2.1.1

[2.1.1] - 2018-06-05

Fixed:

• Removed two function calls that are not supported in Internet Explorer: string.startsWith() and Object.assign().

2.1.0

[2.1.0] - 2018-05-31

Added:

• The client now sends the current SDK version to LaunchDarkly in an HTTP header. This information will be visible in a future version of the LaunchDarkly UI.

Fixed:

• Fixed a bug that caused summary events to combine the counts for flag evaluations that produced the flag's first variation (variation index 0) with the counts for flag evaluations that fell through to the default value.

2.0.0

[2.0.0] - 2018-05-25

Changed

• To reduce the network bandwidth used for analytics events, feature request events are now sent as counters rather than individual events, and user details are now sent only at intervals rather than in each event. These behaviors can be modified through the LaunchDarkly UI and with the new configuration option inlineUsersInEvents. For more details, see Analytics Data Stream Reference.
• In every function that takes an optional callback parameter, if you provide a callback, the function will not return a promise; a promise will be returned only if you omit the callback. Previously, it would always return a promise which would be resolved/rejected at the same time that the callback (if any) was called; this caused problems if you had not registered an error handler for the promise.
• When sending analytics events, if there is a connection error or an HTTP 5xx response, the client will try to send the events again one more time after a one-second delay.
• Analytics are now sent with an HTTP POST request if the browser supports CORS, or via image loading if it does not. Previously, they were always sent via image loading.

Added

• The new configuration option sendEventsOnlyForVariation, if set to true, causes analytics events for feature flags to be sent only when you call variation. Otherwise, the default behavior is to also send events when you call allFlags, and whenever a changed flag value is detected in streaming mode.
• The new configuration option allowFrequentDuplicateEvents, if set to true, turns off throttling for feature flag events. Otherwise, the default behavior is to block the sending of an analytics event if another event with the same flag key, flag value, and user key was generated within the last five minutes.

Fixed

• If identify is called with a null user, or a user with no key, the function no longer tries to do an HTTP request to the server (which would always fail); instead, it just returns an error.

Deprecated

• The configuration options all_attributes_private and private_attribute_names are deprecated. Use allAttributesPrivate and privateAttributeNames instead.