1.4.6

[1.4.6] - 2020-09-14

Fixed:

• In streaming mode, when connecting to the Relay Proxy rather than directly to the LaunchDarkly streaming service, if the current user was changed twice within a short time it was possible for the SDK to revert to flag values from the previous user.

1.4.5

[1.4.5] - 2020-07-02

Changed:

• The default implementation of logging now uses Winston 3.x rather than Winston 2.x. This does not change the content of the log output, and if you have specified your own custom logger then the SDK still uses that. The only effect is that the SDK no longer has dependencies on Winston 2.x.

Fixed:

• Fixed a bug that could cause extra delays when receiving a large streaming update. The process will still be blocked for some amount of time as the JSON data is being parsed, which is unavoidable in the current architecture, but this bug made it block for longer than necessary.

1.4.4

[1.4.4] - 2020-05-13

Fixed:

• The TypeScript declaration for track() was missing the optional metricValue parameter.

1.4.3

[1.4.3] - 2020-05-04

Fixed:

• Some diagnostic event data was being sent twice, resulting in extra HTTP requests. This did not affect analytics events, so customer data on the dashboard and in data export would still be correct.

1.4.2

[1.4.2] - 2020-03-18

Fixed:

• Some users reported an error where the SDK said that the content type of a response was application/json, application/json; charset=utf8. It is invalid to have multiple Content-Type values in a response and the LaunchDarkly service does not do this, but an improperly configured proxy/gateway might add such a header. Now the SDK will tolerate a value like this as long as it starts with application/json.
• Fixed incorrect usage of Object.hasOwnProperty which could have caused an error if a feature flag had hasOwnProperty as its flag key.

1.4.1

[1.4.1] - 2020-03-06

Fixed:

• At client initialization time, if the initial flag polling request failed, it would cause an unhandled promise rejection unless the application had called waitForInitialization() and provided an error handler for the promise that was returned by that method. While that is correct behavior if the application did call waitForInitialization() (any promise that might be rejected should have an error handler attached), it is inappropriate if the application did not call waitForInitialization() at all-- which is not mandatory, since the application could use events instead, or waitUntilReady(), or might simply not care about waiting for initialization. This has been fixed so that no such promise is created until the first time the application calls waitForInitialization(); subsequent calls to the same method will return the same promise (since initialization can only happen once).
• A bug in the event emitter made its behavior unpredictable if an event handler called on or off while handling an event. This has been fixed so that all event handlers that were defined at the time the event was fired will be called; any changes made will not take effect until the next event.

1.4.0

[1.4.0] - 2020-02-14

Note: if you are using the LaunchDarkly Relay Proxy to forward events, update the Relay to version 5.10.0 or later before updating to this Node client-side SDK version.

Added:

• The SDK now periodically sends diagnostic data to LaunchDarkly, describing the version and configuration of the SDK, the architecture and version of the runtime platform, and performance statistics. No credentials, hostnames, or other identifiable values are included. This behavior can be disabled with the diagnosticOptOut option, or configured with diagnosticRecordingInterval.

Fixed:

• When using secure mode in conjunction with streaming mode, if an application specified a new hash parameter while changing the current user with identify(), the SDK was not using the new hash value when recomputing the stream URL, causing the stream to fail. (Thanks, andrao!)
• Changed some exact version dependencies to "highest compatible" dependencies, to avoid having modules that are also used by the host application loaded twice by NPM. The dependency on js-sdk-common is still an exact version dependency so that each release of node-client-sdk has well-defined behavior for that internal code.
• Updated comment on initialize to clarify the intended singleton usage pattern.

Removed:

• Removed an unused transitive dependency on @babel/polyfill.

1.3.1

[1.3.1] - 2020-01-15

Fixed:

• The SDK now specifies a uniquely identifiable request header when sending events to LaunchDarkly to ensure that events are only processed once, even if the SDK sends them two times due to a failed initial attempt.

1.3.0

[1.3.0] - 2019-12-16

Added:

• Configuration property eventCapacity: the maximum number of analytics events (not counting evaluation counters) that can be held at once, to prevent the SDK from consuming unexpected amounts of memory in case an application generates events unusually rapidly. In JavaScript code this would not normally be an issue, since the SDK flushes events every two seconds by default, but you may wish to increase this value if you will intentionally be generating a high volume of custom or identify events. The default value is 100.
• LDClient.version property reports the SDK version string programmatically.

Changed:

• The SDK now logs a warning if any configuration property has an inappropriate type, such as baseUri:3 or sendEvents:"no". For boolean properties, the SDK will still interpret the value in terms of truthiness, which was the previous behavior. For all other types, since there's no such commonly accepted way to coerce the type, it will fall back to the default setting for that property; previously, the behavior was undefined but most such mistakes would have caused the SDK to throw an exception at some later point.
• Removed or updated some development dependencies that were causing vulnerability warnings.

Deprecated:

• The samplingInterval configuration property was deprecated in the code in the previous minor version release, and in the changelog, but the deprecation notice was accidentally omitted from the documentation comments. It is hereby deprecated again.

1.2.1

[1.2.1] - 2019-11-06

Fixed:

• A runtime dependency on typedoc was mistakenly added in the 1.2.0 release. This has been removed.