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)
npm audit. These were all for test-only dependencies, so would not affect production code.
privateAttributeNames, was not usable from TypeScript because it was omitted from the TypeScript declarations.
interfaceinstead, except for
LDFlagValuewhich is a type alias. This should not affect regular usage of the SDK in TypeScript, but it is easier to extend an
Changes are only in test code used by other libraries. There is no need to upgrade to this release.
FileDataSourcein the TypeScript API documentation, and "Reading flags from a file".
config.featureStoreunset) 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!)
close()on a client that was using a Redis feature store without in-memory caching.
tunnelpackage from NPM, rather than a Git reference to a fork.
allFlagsStatemethod 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.
allFlagsStateis 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.
variationDetailallows 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.
index.d.ts. We are now running the TypeScript compiler in our automated builds to avoid such problems. (Thanks, PsychicCat!)
allFlagsState()did not work if you omitted the optional second parameter,
options, but did provide a
allFlagsState()should be used instead of
allFlagsState()will still work with older versions.
allFlagsState()method also allows you to select only client-side-enabled flags to pass to the front end, by using the option
npm audithave been fixed. Note that these were all development-only dependencies, so should not have affected any production code. (#108)
LDFeatureStoreare now correct.
event_summarizer.js. (Thanks, jwenzler!)
waitForInitialization(), if successful, now resolves with a value: the client. Previously, it resolved with no value. (Thanks, rmanalan!)
"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)
close()on an offline client. (Thanks, dylanlingelbach!)
waitUntilReady()method is now deprecated in favor of
inlineUsersInEvents. For more details, see Analytics Data Stream Reference.
flush_intervalelapses 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.
hoekv4.2.0, which had a security flaw; now uses 4.2.1 instead.
all_flags). The deprecated names will still work for now, but will trigger a warning message in the log.
all_flagswith a very large number of flags, or evaluating a flag with a very large number of rules. This should no longer happen no matter how many flags or rules there are.
RedisFeatureStore), or otherwise the default value.
RedisFeatureStoreshould work as before, but custom feature store implementations will need to be updated.
LDFeatureStoreis now correct — #77
Promiseinterface now properly return the resolution or rejection value to the caller. #75
send_eventsoption to control whether the SDK should send events back to LaunchDarkly or not. Defaults to
Promise; the SDK now supports both the Node.js error callback interface and the
errorevent. If no
errorevent handler exists, errors will be logged using the configured logger. (https://github.com/launchdarkly/node-client/issues/55)
updateevent is available on the client to be notified whenever the SDK receives feature flag updates from LaunchDarkly.
RedisFeatureStorenow takes an optional prefix parameter
readyevent now gets properly emitted in offline mode.
all_flagsmethod returns all flag values for a specified user.
initializedfunction returns whether or not the client has finished initialization.
togglecall has been deprecated in favor of