5.9.2

[5.9.2] - 2019-10-23

Changed:

• Event listeners for update events were receiving an entire flag configuration object as an argument. This was not useful for applications (since the SDK does not provide any way to use such an object directly), and was unsafe since the object was shared with internal code and was mutable. The argument for update events is now an object with only one property, key (the flag key).
• The CI build will now fail if npm audit detects any vulnerabilities in the runtime dependencies (not including devDependencies).
• The CI build now performs code linting.

Fixed:

• There were significant performance bottlenecks due to the use of setTimeout to defer callbacks. These have been replaced with setImmediate for callbacks into application code, or with direct undeferred callbacks in internal code paths where it is safe to do so. (Thanks, mdgbayly!)
• When initializing the client, if it gets an HTTP error or network error that is considered retryable (as opposed to for instance a 401 error, which will not be retried), it should not reject the waitForInitialization promise and should not emit an error event. (#155)
• Fixed some rule matching behavior for consistency with the other SDKs: string operators such as startsWith should only be able to match if both values are strings; numeric operators such as lessThan should only be able to match if both values are numbers; strings should only be usable as date/time values if they match RFC3339 format; and invalid regexes should simply cause a non-match, rather than an error.
• Previously, an update event would only be triggered for a flag if that flag's configuration were changed directly; it did not take into account indirect changes that could affect a flag's value, such as a change to one of its prerequisite flags or to a user segment that it references. This has been fixed so that any change potentially affecting a flag's value will produce an update event for that flag.
• The TypeScript declaration for LDFeatureStore.upsert() was wrong. (Thanks, JakeGinnivan!)
• Removed an unused dependency on the deprecated package hoek. (#158)
• Updated the dependency on semver. (Thanks, mmcgahan!)
• Fixed various dependency versions that were flagged as vulnerable by npm audit.

5.9.1

[5.9.1] - 2019-10-10

Fixed:

• For an evaluation reason of RULE_MATCH, the ruleIndex property was always being set to zero rather than to the actual rule index. Note that it is always best to look at ruleId rather than ruleIndex, since it will never change even if rules are added or deleted.

5.9.0

[5.9.0] - 2019-08-20

Added:

• Added support for upcoming LaunchDarkly experimentation features. See LDClient.track().

5.8.2

[5.8.2] - 2019-06-06

Fixed:

• Resolved a low-severity security vulnerability in an extend transitive dependency.

5.8.1

[5.8.1] - 2019-05-13

Changed:

• Changed the package name from ldclient-node to launchdarkly-node-server-sdk.

There are no other changes in this release. Substituting ldclient-node version 5.8.0 with launchdarkly-node-server-sdk version 5.8.1 (and updating any require or import lines that referred to the old package name) will not affect functionality.

5.8.0

[5.8.0] - 2019-04-26

Added:

• Generated TypeDoc documentation for all types, properties, and methods is now available online at https://launchdarkly.github.io/node-server-sdk/. Currently this will only be for the latest released version.
• It is now possible to specify any of the TLS configuration parameters supported by Node's https.request() in the client configuration, so that they will apply to all HTTPS requests made by the SDK. In your client options, add a property called tlsParams whose value is an object containing those parameters, e.g. tlsParams: { ca: 'my trusted CA certificate data' }.

Fixed:

• Running the SDK unit tests is now simpler in that the Redis integration can be skipped. See CONTRIBUTING.md.

Note on future releases

The LaunchDarkly SDK repositories are being renamed for consistency. This repository is now node-server-sdk rather than node-client. (Note that node-client-sdk also exists, which is the client-side Node SDK.)

The package name will also change. In the 5.8.0 release, it is still ldclient-node; in all future releases, it will be launchdarkly-node-server-sdk. No further updates to the ldclient-node package will be published after this release.

5.7.4

[5.7.4] - 2019-04-02

Fixed:

• Setting user attributes to non-string values when a string was expected would cause analytics events not to be processed. The SDK will now convert attribute values to strings as needed. (#147)
• If track or identify is called without a user, the SDK now logs a warning, and does not send an analytics event to LaunchDarkly (since it would not be processed without a user).

5.7.3

[5.7.3] - 2019-03-21

Changed:

• The default value for the configuration property capacity (maximum number of events that can be stored at once) is now 10000, consistent with the other SDKs, rather than 1000.

Fixed:

• A missing var keyword could cause an error in strict mode when evaluating a flag with rollouts. (Thanks, phillipb!)
• The user attribute secondary was not included in the TypeScript declarations and therefore could not be used from TypeScript code.

5.7.2

[5.7.2] - 2019-02-22

Fixed:

• Calling identify() or track() with no user object, or with a user that has no key, will now cause the SDK to log a warning (as the other SDKs do). The SDK no longer sends an analytics event in this case, since LaunchDarkly would discard the event as invalid anyway. Also, previously, calling identify() with no user object would throw an exception.
• FileDataSource, in auto-update mode, could sometimes reload files more than once when they were only modified once (due to a known issue with Node's fs.watch). This should no longer happen. (#138)
• Fixed dependency vulnerabilities flagged by npm audit. These were all for test-only dependencies, so would not affect production code.
• Previously, CI tests were only running on Linux. We have added a CI test suite that runs on Windows, using the latest stable version of Node.
• A supported user property, privateAttributeNames, was not usable from TypeScript because it was omitted from the TypeScript declarations.
• In TypeScript, asynchronous methods that can either take a callback or return a Promise were not usable in the Promise style, because the return types were declared incorrectly. (#141)
• Some TypeScript declarations that used type now use interface instead, 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.

5.7.1

[5.7.1] - 2019-01-16

Changes are only in test code used by other libraries. There is no need to upgrade to this release.