launchdarkly-js-client-sdk - npm Package Versions

[2.24.2] - 2022-10-20

Changed:

• Updated to js-sdk-common 3.8.2 which includes jitter and backoff for re-connection attempts for streaming connections.

[2.24.0] - 2022-10-18

Changed:

• Upgrade to js-sdk-common 3.8.1 which added support for Inspectors that can be used for collecting information for monitoring, analytics, and debugging.

[2.23.0] - 2022-10-05

Changed:

• Updated js-sdk-common version which removed event de-duplication functionality which was made redundant by support of summary events. This will improve the default event behavior when using experimentation.

• Updated escape-string-regexp to version 4.

• Updated development dependencies to recent versions.

Deprecated:

• Deprecated the allowFrequentDuplicateEvents configuration option. Setting the option will no longer have any effect, and it will be removed in a future version.

[2.22.1] - 2022-04-27

This release is functionally identical to the 2.22.0 release. Due to an oversight the release process re-introduced the package-lock.json.

Removed:

• The package-lock.json file is no longer in source control. As this is a library project, the lockfile never affected application code that used the SDK, but only affected the SDK's CI build. It is preferable for the CI build to refer only to package.json so that it resolves dependencies the same way an application using the SDK would, rather than using pinned dependencies that an application would not use.

[2.22.0] - 2022-04-26

Added:

• LDOptions.application, for configuration of application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.

Fixed:

• The baseUrl, streamUrl, and eventsUrl properties now work properly regardless of whether the URL string has a trailing slash. Previously, a trailing slash would cause request URL paths to have double slashes.

Removed:

• The package-lock.json file is no longer in source control. As this is a library project, the lockfile never affected application code that used the SDK, but only affected the SDK's CI build. It is preferable for the CI build to refer only to package.json so that it resolves dependencies the same way an application using the SDK would, rather than using pinned dependencies that an application would not use.