5.3.0

[5.3.0] - 2018-08-27

Added:

• The new LDClient method allFlagsState() should be used instead of allFlags() if you are passing flag data to the front end for use with the JavaScript SDK. It preserves some flag metadata that the front end requires in order to send analytics events correctly. Versions 2.5.0 and above of the JavaScript SDK are able to use this metadata, but the output of allFlagsState() will still work with older versions.
• The allFlagsState() method also allows you to select only client-side-enabled flags to pass to the front end, by using the option clientSideOnly: true.

Deprecated:

• LDClient.allFlags()

5.2.1

[5.2.1] - 2018-08-22

Fixed:

• Problematic dependencies flagged by npm audit have been fixed. Note that these were all development-only dependencies, so should not have affected any production code. (#108)
• Type definitions for LDFeatureStore are now correct.
• Fixed an accidental global variable reference in event_summarizer.js. (Thanks, jwenzler!)

5.2.0

[5.2.0] - 2018-08-01

Changed:

• The promise from waitForInitialization(), if successful, now resolves with a value: the client. Previously, it resolved with no value. (Thanks, rmanalan!)

Fixed:

• Receiving an HTTP 400 error from LaunchDarkly should not make the client give up on sending any more requests to LaunchDarkly (unlike a 401 or 403).

5.1.2

[5.1.2] - 2018-07-26

Removed:

• Removed a dependency on the deprecated crypto module. (#92)

5.1.1

[5.1.1] - 2018-07-19

Fixed:

• Now outputs a more descriptive log message if allFlags is called with a null user object. (Thanks, jbatchelor-atlassian!)
• Added TypeScript definitions for some previously undefined types.
• Updated request package dependency to 2.87.0, to avoid a security vulnerability in a package used by request.

5.1.0

[5.1.0] - 2018-06-26

Added:

• The new event "failed" will fire if client initialization failed due to any of the unrecoverable errors described below. If you prefer to use Promises, there is a new method waitForInitialization(), which behaves exactly like waitUntilReady() except that its Promise will be rejected if the "failed" event fires. (For backward compatibility, the Promise returned by waitUntilReady() will never be rejected.) (#96)

Changed:

• The client now treats most HTTP 4xx errors as unrecoverable: that is, after receiving such an error, it will not make any more HTTP requests for the lifetime of the client instance, in effect taking the client offline. This is because 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, 429, or any 5xx error.

Fixed:

• Fixed a bug that would cause a null reference error if you called close() on an offline client. (Thanks, dylanlingelbach!)

Deprecated:

• The waitUntilReady() method is now deprecated in favor of waitForInitialization() (see above).

5.0.2

[5.0.2] - 2018-06-15

Fixed:

• Removed an indirect dependency on an old version of the querystringify module, which had a security flaw. (#97)
• Updated TypeScript definitions for client options. (Thanks, stepanataccolade!)

5.0.1

[5.0.1] - 2018-05-31

Fixed:

• Fixed a bug that caused summary events to combine two different counters: a) flag evaluations that produced the flag's first variation, and b) counts for flag evaluations that fell through to the default value.

Removed:

• Removed debug-level logging that was listing every analytics event.

5.0.0

[5.0.0] - 2018-05-10

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.
• Pending analytics events are now flushed if 1. the configured flush_interval elapses or 2. you explicitly call flush(). Previously, if the number of events exceeded the configured capacity it would also trigger a flush; now, the client will simply drop events until the next timed or explicit flush occurs. This makes the Node SDK consistent with the other SDKs, and prevents unbounded use of network resources if you are generating analytics events rapidly.
• 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.
• 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.

Fixed:

• Removed a dependency on hoek v4.2.0, which had a security flaw; now uses 4.2.1 instead.

Deprecated:

• All function and property names that used underscores are now deprecated; please use their camelCase equivalent instead (e.g. allFlags instead of all_flags). The deprecated names will still work for now, but will trigger a warning message in the log.

4.0.5

[4.0.5] - 2018-05-03

Fixed

• The waitUntilReady Promise will now resolve even after the ready event was emitted — thanks @dylanjha!

Changelog