[FEATURE] Expose JS SDK/framework identity on ClientMetadata

[jonathannorris]

Context

We have run into an issue as a vendor where we don't know what OpenFeature JS SDK type our clients are running.

Because that information is not exposed by the SDK, we were forced to create simple wrapper providers such as @devcycle/openfeature-react-provider so we could attach that metadata to our internal telemetry and systems.

It would be better if the OpenFeature JS SDKs exposed this information directly to providers and hooks, so vendors do not need framework-specific wrapper packages purely to identify client usage.

The Problem

Today ClientMetadata does not provide enough information to answer:

• is this client using the web or server SDK?
• is this call coming through react, angular, or nest?

Expected behavior:

• the JS SDK should expose stable metadata for SDK family and framework
• that metadata should be available anywhere clientMetadata is already surfaced, including hook contexts
• downstream providers should not need framework-specific wrapper packages just to infer usage

Suggested Fix

Extend ClientMetadata with JS-specific identity fields:

interface ClientMetadata {
  domain?: string;
  sdk?: 'web' | 'server';
  framework?: 'react' | 'angular' | 'nest';
  version?: string;
  providerMetadata: ProviderMetadata;
}

Examples:

• @openfeature/web-sdk -> { sdk: 'web', version, providerMetadata }
• @openfeature/react-sdk -> { sdk: 'web', framework: 'react', version, providerMetadata }
• @openfeature/angular-sdk -> { sdk: 'web', framework: 'angular', version, providerMetadata }
• @openfeature/nestjs-sdk -> { sdk: 'server', framework: 'nest', version, providerMetadata }

Notes

providerMetadata answers a different question than sdk/framework. It identifies the provider bound to the client, while sdk and framework identify the OpenFeature JS layer the application is using.

This does not require a spec change. The current spec only requires client metadata to expose domain, and SDKs can already expose additional metadata.