5.7.0

[5.7.0] - 2019-01-11

Added:

• It is now possible to inject feature flags into the client from local JSON or YAML files, replacing the normal LaunchDarkly connection. This would typically be for testing purposes. See FileDataSource in the TypeScript API documentation, and "Reading flags from a file".

Fixed:

• Fixed a potential race condition that could happen when using a DynamoDB or Consul feature store. The Redis feature store was not affected.

5.6.2

[5.6.2] - 2018-11-15

Fixed:

• Creating multiple clients with the default in-memory feature store (i.e. leaving config.featureStore unset) was causing all of the clients to share the same feature store instance. This has been fixed so they will now each get their own in-memory store. (Thanks, seanparmelee!)

5.6.1

[5.6.1] - 2018-11-15

Fixed:

• Fixed a bug introduced in v5.6.0 that could cause an unhandled promise rejection if a Redis error occurred while trying to query all flags from Redis.
• Fixed a bug introduced in v5.6.0 that could cause an exception when calling close() on a client that was using a Redis feature store without in-memory caching.

5.6.0

[5.6.0] - 2018-11-14

Added:

• To make it easier to build feature store integrations for databases other than Redis, some of the feature store support logic has been made into a reusable component in caching_store_wrapper.js.

Changed:

• For proxy support, the SDK now uses the published version of the tunnel package from NPM, rather than a Git reference to a fork.

5.5.0

[5.5.0] - 2018-10-08

Added:

• The allFlagsState method now accepts a new option, detailsOnlyForTrackedFlags, which reduces the size of the JSON representation of the flag state by omitting some metadata. Specifically, it omits any data that is normally used for generating detailed evaluation events if a flag does not have event tracking or debugging turned on.

Fixed:

• Fixed an error that would occur in two cases where the client should return a default value: evaluating a flag when the client and the feature store are not yet initialized, and evaluating with no flag key. (Thanks, SharkofMirkwood!)
• JSON data from allFlagsState is now slightly smaller even if you do not use the new option described above, because it completely omits the flag property for event tracking unless that property is true.

5.4.2

[5.4.2] - 2018-09-05

Fixed:

• Fixed a bug that would sometimes cause an unhandled promise rejection warning-- and, depending on your Node configuration, a crash-- if there was an HTTP error during an automatic event flush. This was a partial regression of #85 which was introduced in v5.0.0, although unlike the earlier bug, it happened nondeterministically rather than for all errors.

5.4.1

[5.4.1] - 2018-09-05

Fixed:

• Fixed a ReferenceError that occurred if a feature flag had invalid properties, e.g. a rule referred to a nonexistent variation index. Instead, an error will be written to the log and the flag will return the default value. (#119)

5.4.0

[5.4.0] - 2018-08-30

Added:

• The new LDClient method variationDetail allows you to evaluate a feature flag (using the same parameters as you would for variation) and receive more information about how the value was calculated. This information is returned in an object that contains both the result value and a "reason" object which will tell you, for instance, if the user was individually targeted for the flag or was matched by one of the flag's rules, or if the flag returned the default value due to an error.

Fixed:

• Evaluating a prerequisite feature flag did not produce an analytics event if the prerequisite flag was off.

5.3.2

[5.3.2] - 2018-08-29

Fixed:

• Fixed TypeScript syntax errors in index.d.ts. We are now running the TypeScript compiler in our automated builds to avoid such problems. (Thanks, PsychicCat!)

5.3.1

[5.3.1] - 2018-08-27

Fixed:

• Calling allFlagsState() did not work if you omitted the optional second parameter, options, but did provide a callback. (#114)