Add Zod Validation Hook

Reasoning

I want to add a hook which performs validation using Zod.

• Zod is a TypeScript-first schema based validator with static type inference
• Static types can be passed as generics to the OpenFeature resolves methods for additional type safety.

TODO:

• generate hook via tooling
• implement Hook interface
• add tests
• complete README

Keep in mind the CONTRIBUTING guidelines: https://github.com/open-feature/js-sdk-contrib/blob/main/CONTRIBUTING.md

We need to build an experimental flagd-web provider. This should work in accordance with the proposed spec enhancements for client side. It should feature:

• integration with the experimental-web-sdk
• bulk evaluation on context change
• synchronous evaluation

An implementation is already partially complete here.

The config cat provider doesn't implement status: https://github.com/open-feature/js-sdk-contrib/blob/main/libs/providers/config-cat/src/lib/config-cat-provider.ts

In order for it to stay functional after this is released, it needs to be updated to set its status field (it should start with it NOT_READY and update it to READY once it's handler is attached.

Flagd sends empty values in flag response payloads when the value is equivalent to the zero-value of the associated go type. We should test that this works as expected and still returns an equivalent zero-value (ie: false, 0).

DoD:

• manual test confirming zero values are returned from the flagd provider when they are missing from the gRPC message (boolean set to false or numeric set to 0 in flagd config)
• new tests that assert correct values for zero-value flags

see: open-feature/flagd#218

Currently the flagd provider doesn't default to unlimited retries, and doesn't throw immediately if it can't start.

See: https://github.com/open-feature/flagd/blob/main/docs/other_resources/creating_providers.md#environment-variables and https://github.com/open-feature/flagd/blob/main/docs/other_resources/creating_providers.md#provider-lifecycle-initialization-and-shutdown

Definition of done:

• update the flagd provider to default to 0 (infinite) retries
• verify other defaults
• reject immediately if the provider cannot connect, but continue to try to connect

The Go-Feature-Flag provider doesn't implement status: https://github.com/open-feature/js-sdk-contrib/blob/main/libs/providers/go-feature-flag/src/lib/go-feature-flag-provider.ts

In order for it to stay functional after this is released, it needs to be updated to set its status field (it should start with it NOT_READY and update it to READY once its bgScheduler interval is started.

Similar pattern to this pr

flagd changes

OFEP

Before we try to resolve flag values, we should see if the provider is READY. If not, we should throw the not-ready error. With the current implementation, we'd attempt a gRPC call and then get a "general error".

Please also add the appropriate tests.

• Ensure the linter is in sync with Prettier.
• Run linter when a PR is opened

Objects returned by flagd are not deserialized as expected:

http:

{
  "key": "val"
}

grpc

{
  "fields": {
    "key": {
      "kind": {
        "oneofKind": "stringValue",
        "stringValue": "val"
      }
    }
  }
}

An upcoming change to the OpenFeature node SDK will remove the context transformer. The Go Feature Flag provider currently uses the context transforming and will be affected by this change. You can see an example of how the provider could look in this PR.

We should support the ability to add custom attributes to traces, as we do with metrics.

We should allow users to supply a function that maps flag metadata to custom span attributes.

Add {my-system} provider

Reasoning

I want to add a provider which stores feature flags in {my-system}. This would be valuable because...

• everybody uses {my-system}!
• {my system} supports {these things}!
• other reasons!

TODO:

• generate provider via tooling
• implement Provider interface
• add tests
• complete README

Keep in mind the CONTRIBUTING guidelines: https://github.com/open-feature/js-sdk-contrib/blob/main/CONTRIBUTING.md

Add ConfigCat provider

Reasoning

I want to add an OpenFeature provider for ConfigCat.
This would be valuable because we are using that system in our projects and would like to be able to interface it with OpenFeature.
I would like to implement it and contribute the provider to this repo.

Requirements:

• generate provider via tooling
• implement Provider interface
• add tests
• complete README
• add the new provider to the OpenFeature docs

Resources

• ConfigCat

Keep in mind the CONTRIBUTING guidelines: https://github.com/open-feature/js-sdk-contrib/blob/main/CONTRIBUTING.md

We probably want to fire a configuration_changed event on reconnect, in case any events have been missed. To keep things from being too chatty, we can do this only if we're currently in a reconnecting state, so that we don't get a redundant event with the initial ready.

https://github.com/open-feature/js-sdk-contrib/blob/main/libs/providers/flagd-web/src/lib/flagd-web-provider.ts#L121-L124

• Remove experimental badges
• Add OpenFeature logo
• Update title to match repo name

We need to support the creation of web-components. This involves:

• adding nx templates for such components
• adding associated documentation
• one example already exists: #250

The flagd-web provider doesn't implement status: https://github.com/open-feature/js-sdk-contrib/blob/main/libs/providers/go-feature-flag/src/lib/go-feature-flag-provider.ts

In order for it to stay functional after this is released, it needs to be updated to set its status field (it should start with it NOT_READY and update it to READY once its connected.

The OTel hook should include the span attributes when starting the span. This is useful because OTel is able use this information for sampling purposes.

Quickly describe what a hook is and how it can be used. It should also contain a section on how to add a new hook.

Add LaunchDarkly (client-side JS) provider

Reasoning

I want to add a provider which stores feature flags in LaunchDarkly via client-side JavaScript. This would be valuable because...

• LaunchDarkly/OpenFeature Provider support is currently only server-side Node.js
• the LD SDK's have some distinctions between server-side and client-side
• not every feature flag implementation of LaunchDarkly is within a server
• LaunchDarkly is growing in popularity as a flag vendor, especially as a FedRAMP-approved vendor

TODO:

• generate provider via tooling
• [] implement Provider interface
• add tests
• complete README

Keep in mind the CONTRIBUTING guidelines: https://github.com/open-feature/js-sdk-contrib/blob/main/CONTRIBUTING.md

Once the js-sdk has events and init/shutdown support, we need to update the flagd-provider to emit events and do proper init/shutdown. We already have a stream implemented for cache-busing, so this should be pretty simple.

Definition of done:

• flagd does does startup logic (like initializing it's stream) in initialize function
• flagd shuts down stream in close/shutdown function
• flagd emits appropriate events on flag changes, and errors
• associated testing

Blocked by:

• js-sdk implementation: open-feature/js-sdk#424

Add OTel metrics hook

Reasoning

I want to add a hook which captures OTel metrics, similar to https://github.com/open-feature/go-sdk-contrib/blob/main/hooks/open-telemetry/pkg/metrics.go

Requirements:

• implement Hook interface
• add tests
• complete README

cc @Kavindu-Dodan

As we have seen in #428 we can introduce breaking changes for some version of NodeJS without noticing it in the CI.

We should be able to build/test in a matrix of versions, at least 16 and the latest version.

The Jest configuration has changed slightly. The repo should be updated accordingly. The OTel hook has already been updated. This approach should be done for the rest of the project (include the NX template).

Originally posted by @toddbaert in #179 (comment)

The flagd provider should start an OTel span that will be passed to flagd to get cross-service tracing for evaluation.

Adding a hook

As described in the documentation, hooks are a mechanism that allow for the addition of arbitrary behavior at well-defined points of the flag evaluation life-cycle. Use cases include validation of the resolved flag value, modifying or adding data to the evaluation context, logging, telemetry, and tracking.

This repository has built in tooling for adding hooks. If you have a creative idea for a hook, we welcome your contribution! To add a hook:

• read the CONTRIBUTING guide and the hooks documenation.
• open a new issue using the Add hook template found here.

We should make our options consistent, including the env vars. I think we want:

| Option name | Environment variable name | Type    | Default   |
| ----------- | ------------------------- | ------- | --------- |
| host        | FLAGD_HOST                | string  | localhost |
| port        | FLAGD_PORT                | number  | 8013      |
| tls         | FLAGD_TLS                 | boolean | false     |
| socketPath  | FLAGD_SOCKET_PATH         | string  | -         |
| certPath    | FLAGD_SERVER_CERT_PATH    | string  | -         |

We have all of these except FLAGD_SERVER_CERT_PATH.

The build process current adds external dependencies as peer dependencies. This is likely what we want but we'll need to make it clear what additional packages must be installed.

Add Backstage provider

Reasoning

I want to add an OpenFeature provider for Backstage. This would be valuable because...

• Backstage is a popular CNCF project that already supports feature flags.
• it would be a great way for developers to gain experience with OpenFeature.

Requirements:

• generate provider via tooling
• implement Provider interface
• add tests
• complete README
• add the new provider to the OpenFeature docs

Resources

• https://backstage.io/docs/plugins/feature-flags

Keep in mind the CONTRIBUTING guidelines: https://github.com/open-feature/js-sdk-contrib/blob/main/CONTRIBUTING.md

https://github.com/open-feature/js-sdk-contrib/actions/runs/4638669732/jobs/8208696142

Add a provider generator that makes it easy to start a new provider.

Requirements;

• New NX generator is added
  • Jest tests
  • Package command should generate a valid esm and cjs package
  • License and readme should be included in the package
• Script is added to package json
• Update main readme with a reference
• Add readme to /lib/providers

@thomaspoignant just a heads up that the most recent change to the the JS go-feature-flag-provider here used a feature (structuredClone()) that is only available in NodeJS 17 and above. This change will break builds for anyone who has the default value from npm install in their package.json (which is "@openfeature/go-feature-flag-provider": "^0.5.8") and using a NodeJS version either 16 or below.

This should probably be considered a breaking change if not a in the NodeJS world.

For anyone who uses this and finds their build is randomly failing, you can just remove the ^ from the version in package.json to pin the version so it works for older NodeJS versions.

"@openfeature/go-feature-flag-provider": "^0.5.8" -> "@openfeature/go-feature-flag-provider": "0.5.8"

Now that OTel 2529 is merged, we should update the (or create a new) Open Telemetry hook.

Basically, this would entail creating a hook which:

• in the after stage: gets the current span and adds an appropriately named event (feature_flag), with the attributes (feature_flag.key, feature_flag.provider_name, and feature_flag.variant)
• in the error stage, records the exception

In pseudocode, this looks something like:

class OTelHook implements Hook {
  after(context, details) {
    var currentTrace = trace.getActiveSpan();
    currentTrace.addEvent("feature_flag", { "feature_flag.key": details.key, /*  other props */ } );
  }

  error(err) {
    var currentTrace = trace.getActiveSpan();
    currentTrace.recordException(err);
  }
}

See: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/feature-flags.md

Note: For the this repo, we may want to deprecate the old hook.

Trying to import FlagdProvider in Typescript with ESM causes the following error:

node_modules/@openfeature/flagd-provider/src/index.d.ts:1:15 - error TS2834: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Consider adding an extension to the import path.

1 export * from './lib/flagd-provider';
                ~~~~~~~~~~~~~~~~~~~~~~

src/main.ts:2:10 - error TS2305: Module '"@openfeature/flagd-provider"' has no exported member 'FlagdProvider'.

2 import { FlagdProvider } from '@openfeature/flagd-provider';
           ~~~~~~~~~~~~~


Found 2 errors in 2 files.

Errors  Files
     1  node_modules/@openfeature/flagd-provider/src/index.d.ts:1
     1  src/main.ts:2

When I switch my project to CommonJS the problem is resolved.
I'm not sure if this is a bug or if I'm doing something wrong here.

Steps to reproduce

• Create Typescript ESM project.
• Import FlagdProvider like so: import { FlagdProvider } from '@openfeature/flagd-provider';.

I also created a simple example repo. Running npm run build shows the error.

Adding a provider

As described in the documentation, providers are responsible for performing flag evaluation. They provide an abstraction between the underlying flag management system and the OpenFeature SDK.

A flag management system could be a vendor solution, a custom feature flag system, or a thin wrapper around some other service, such as a cloud storage solution or an RDBMS.

This repository has built in tooling for adding providers. If you have a creative idea for a provider, we welcome your contribution! To add a provider:

• read the CONTRIBUTING guide and the provider FAQs.
• open a new issue using the Add provider template found here.

Implement the changes to support the new features of spec 0.6.0.
Initialization is not needed by ConfigCat.

Implement flagd caching.

Example in go: https://github.com/open-feature/go-sdk-contrib/blob/main/providers/flagd/pkg/provider.go

This should be similar to what's in the js-sdk now.

Definition of done:

• run e2e tests based on test-harness ghekin suite and flagd test image. A lot of the code can be taken from the client and server implementations in teh js-sdk.
• run in CI

To prepare for the client/server change, the following must be updated:

o Update the generator to support client, server, or both.
o Update badges for existing artifacts.

Fossa has identified license issues with this repo. The only requirement I can see is a requirement to include licenses.

It seems like we may be able to automate this using: https://www.npmjs.com/package/npm-license-crawler. We should do this within each module.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• chore(deps): update dependency @types/node to v20.14.11
• chore(deps): update dependency testcontainers to v10.10.4
• chore(deps): update dependency ts-jest to v29.2.3
• chore(deps): update dependency @grpc/grpc-js to ~1.8.0 || ~1.9.0 || ~1.10.0 || ~1.11.0
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dyladan/component-owners digest to 58bd86e
• chore(deps): update dependency flagsmith to v4.0.3
• fix(deps): update dependency @flipt-io/flipt-client-browser to ^0.0.18
• fix(deps): update dependency tslib to v2.6.3
• chore(deps): update bufbuild/buf-setup-action action to v1.34.0
• chore(deps): update swc monorepo (@swc/core, @swc/helpers)
• fix(deps): update dependency axios to v1.7.2
• chore(deps): update eslint (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser, eslint, eslint-config-prettier)
• fix(deps): update dependency copy-anything to v4
• fix(deps): update dependency lru-cache to v11
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency undici to v6
• chore(deps): update google-github-actions/release-please-action action to v4

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Hello everybody, don't really know if this is the correct process but we want to get launch darkly working for our frontend use case.

problem:

There is a provider but there are couple of issues:

• the initialization proposed is outside the Provider which makes it hard to integrate and error prone.
• The library includes imports from @openfeature/js-sdk for types, prefered in this case should be @openfeature/web-sdk
• The provider seems to now work due the external initialisation, it seem to never get ready.

I opened a PR #418 that handles this issues, it has been tested in one of our frontend applications, the motivation for this change is basically to get the ball rolling and use the provider.