feat: Add wrapper information to the LaunchDarkly client-side provider.

[kinyoklion]

This PR

Adds wrapper information to the LaunchDarkly client-side provider.
Wrappers of the LaunchDarkly SDK are intended to implement wrapper information. Wrapper information is included in headers when the SDK publishes analytics events.

Example from our node provider: https://github.com/launchdarkly/openfeature-node-server/blob/d6f0227aaacca270f65dfc687090959e6561f731/src/LaunchDarklyProvider.ts#L70

Related Issues

Notes

Follow-up Tasks

How to test

[gemini-code-assist]

Summary of Changes

Hello @kinyoklion, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the LaunchDarkly client-side provider by incorporating wrapper information, specifically "wrapperName" and "wrapperVersion", into its configuration. This addition is crucial for analytics events, allowing LaunchDarkly to identify the source of SDK usage, such as the OpenFeature community JavaScript client. Furthermore, the PR updates the release-please configuration to ensure the version string in the provider file is automatically managed during releases, maintaining consistency and automation.

Highlights

• LaunchDarkly Provider Configuration: Added "wrapperName" and "wrapperVersion" fields to the "ldOptions" object within the "LaunchDarklyClientProvider" constructor. This identifies the OpenFeature community JavaScript client as the wrapper.
• Release Management Configuration: Updated "release-please-config.json" to include "src/lib/launchdarkly-client-provider.ts" in the "extra-files" list for the "libs/providers/launchdarkly-client" package. This ensures the "wrapperVersion" placeholder is correctly updated during the release process.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds wrapper information to the LaunchDarkly client-side provider, which is useful for analytics. The implementation correctly adds wrapperName and wrapperVersion to the LaunchDarkly options.

My review includes suggestions to improve maintainability. Specifically, I recommend importing the version from package.json instead of hardcoding it, which would make package.json the single source of truth for the version. I also suggest defining the wrapper name as a constant to avoid magic strings. These changes would also simplify the release-please configuration by making the extra-files entry unnecessary.

[gemini-code-assist]

A couple of suggestions to improve maintainability here:

1. Avoid magic strings: The wrapperName could be defined as a constant at the top of the file for better readability and easier maintenance.
2. Single source of truth for version: Instead of hardcoding wrapperVersion and relying on release-please to update it, you could import it from package.json. This would make package.json the single source of truth and you could remove the extra-files config from release-please-config.json.

Here's how you could implement these changes:

At the top of the file, add:

import { version } from '../../package.json';

const WRAPPER_NAME = 'open-feature-community-js-client';

Then update this block to:

Suggested change

	this.ldOptions = {
	...ldOptions,
	logger: this.logger,
	wrapperName: 'open-feature-community-js-client',
	wrapperVersion: '0.3.2', // {{ x-release-please-version }}
	};
	this.ldOptions = {
	...ldOptions,
	logger: this.logger,
	wrapperName: WRAPPER_NAME,
	wrapperVersion: version,
	};

[gemini-code-assist]

This extra-files configuration may not be necessary. If the provider version is imported from package.json directly in the source code (as suggested in my other comment), release-please will not need to patch this file, and this configuration can be removed. This simplifies the release setup.

[kinyoklion]

I know gemini will be a bit grumpy about this, but generally I find this to be much better than attempting to import the package.json. As it sounds nice, but importing the package.json, and also allowing the package to be easily exported in multiple forms (esm, cjs, iife) is much harder.

The single source of truth is release-please.