Skip to content

Releases: launchdarkly/js-client-sdk

2.10.1

23 Apr 19:44

Choose a tag to compare

[2.10.1] - 2019-04-23

Fixed:

  • The 2.10.0 release added a usage of the Promise.finally() method, which made it incompatible with some older browsers. This has been removed. (#151)

2.10.0

20 Apr 00:20

Choose a tag to compare

[2.10.0] - 2019-04-19

Added:

  • Generated TypeDoc documentation for all types, properties, and methods is now available online at https://launchdarkly.github.io/js-client-sdk/. Currently this will only be for the latest released version.
  • The SDK now allows you to specify an anonymous user without a key (i.e. the anonymous property is true, and there is no key property). In that case, the SDK will generate a UUID and send that as the user key. It will also cache this generated key in local storage (if local storage is available) so that anonymous users in the same browser will always get the same key.

Fixed:

  • Setting user attributes to non-string values when a string was expected would prevent evaluations and analytics events from working. The SDK will now convert attribute values to strings as needed.

2.9.7

17 Apr 00:59

Choose a tag to compare

[2.9.7] - 2019-04-16

Fixed:

  • If there are pending analytics events when the page is being closed, the SDK normally attempts to deliver them by making a synchronous HTTP request. Chrome, as of version 73, does not allow this and logs an error. An upcoming release will change how events are sent, but as a temporary measure to avoid these errors, the SDK will now simply discard any pending events when the page is being closed if the browser is Chrome version 73 or higher. In other browsers, there is no change. Note that this means that in Chrome 73, some events may be lost; that was already the case. The purpose of this patch is simply to avoid triggering errors. (#178)

(The 2.9.6 release was an error and has been removed.)

2.9.5

12 Mar 20:23
307c5a1

Choose a tag to compare

[2.9.5] - 2019-03-12

Fixed:

  • In React, when using the bootstrap property to preload the SDK client with flag values, the client will now become ready immediately and make the flags available to other components as soon as it is initialized; previously this did not happen until after componentDidMount.
  • The user attribute secondary was not included in the TypeScript declarations and therefore could not be used from TypeScript code.

2.9.4

23 Feb 01:09

Choose a tag to compare

[2.9.4] - 2019-02-22

Fixed:

  • Running inside an iframe on Chrome with third-party cookies disabled-- which also disables HTML5 local storage-- would cause a security exception (due to the SDK attempting to check whether window.localStorage exists). This was a long-standing problem, but became worse in the 2.9.0 release since the SDK now checks for browser capabilities like this regardless of whether you've attempted to use them yet. It should now simply log a warning if you try to use bootstrap: "localstorage" when local storage is disabled. (#138)
  • If the SDK received streaming updates out of order (rare, but possible) such that it received "flag X was deleted" prior to "flag X was created", an uncaught exception would be logged in the browser console (but would not otherwise affect anything).
  • A supported user property, privateAttributeNames, was not usable from TypeScript because it was omitted from the TypeScript declarations.
  • Several TypeScript declarations had been changed from interface to type. They all now use interface, except for LDFlagValue which is a type alias. This should not affect regular usage of the SDK in TypeScript, but it is easier to extend an interface than a type if desired.
  • Removed a window message listener that was previously used for integration with the LaunchDarkly dashboard, but is no longer used.

2.9.3

13 Feb 02:10

Choose a tag to compare

[2.9.3] - 2019-02-12

Fixed:

  • The React SDK was pulling in the entire lodash package. This has been improved to only require the much smaller camelcase tool from lodash.
  • The React SDK now lists React itself as a peer dependency rather than a regular dependency, so it will not included twice in an application that already requires React.
  • Corrected the TypeScript declaration for the identify method to indicate that its asynchronous result type is LDFlagSet, not void. (Thanks, impressiver!)
  • Corrected and expanded many documentation comments in the TypeScript declarations.

(The 2.9.2 release was broken and has been removed.)

2.9.1

13 Feb 02:10
6e9aa12

Choose a tag to compare

[2.9.1] - 2019-02-08

Fixed:

  • The previous release of ldclient-react was broken: the package did not contain the actual files. The packaging script has been fixed. There are no other changes.

2.9.0

08 Feb 21:58

Choose a tag to compare

[2.9.0] - 2019-02-01

Added:

  • The new ldclient-react package provides a convenient mechanism for using the LaunchDarkly SDK within the React framework.
  • The new getUser() method returns the current user object.
  • The client options can now have a logger property that defines a custom logging mechanism. The default is still to use console.warn and console.error; you could override this to send log messages to another destination or to suppress them. See LDLogger and createConsoleLogger in the TypeScript definitions.

Changed:

  • The SDK now uses an additional package, ldclient-js-common, consisting of code that is also used by other LaunchDarkly SDKs. This is automatically loaded as a dependency of ldclient-js so you should notice any difference. However, the source code has been reorganized so that this project is now a monorepo containing multiple packages.

2.8.0

03 Dec 23:34
ad5b5a1

Choose a tag to compare

[2.8.0] - 2018-12-03

Added:

  • The use of a streaming connection to LaunchDarkly for receiving live updates can now be controlled with the new client.setStreaming() method, or the equivalent boolean streaming property in the client configuration. If you set this to false, the client will not open a streaming connection even if you subscribe to change events (you might want to do this if, for instance, you just want to be notified when the client gets new flag values due to having switched users). If you set it to true, the client will open a streaming connection regardless of whether you subscribe to change events or not (the flag values will simply be updated in the background). If you don't set it either way then the default behavior still applies, i.e. the client opens a streaming connection if and only if you subscribe to change events.

Fixed:

  • If the client opened a streaming connection because you called on('change', ...) one or more times, it will not close the connection until you call off() for all of your event listeners. Previously, it was closing the connection whenever off('change') was called, even if you still had a listener for 'change:specific-flag-key'.
  • The client's logic for signaling a change event was using a regular Javascript === comparison, so it could incorrectly decide that a flag had changed if its value was a JSON object or an array. This has been fixed to use deep equality checking for object and array values.

2.7.5

22 Nov 01:44
56cd1e4

Choose a tag to compare

[2.7.5] - 2018-11-21

Fixed:

  • When using the event-source-polyfill package to allow streaming mode in browsers with no native EventSource support, the polyfill was using a default read timeout of 45 seconds, so if no updates arrived within 45 seconds it would log an error and reconnect the stream. The SDK now sets its own timeout (5 minutes) which will be used if this particular polyfill is active. LaunchDarkly normally sends a heartbeat every 3 minutes, so you should not see a timeout happen unless the connection has been lost.
  • The SDK's use of the "Base64" package caused problems for build tools that strictly enforce the lowercase package name rule. It now uses the "base64-js" package instead. (#124)