chore: init shared openfeature server provider#1329
Conversation
|
@launchdarkly/js-sdk-common size report |
|
@launchdarkly/js-client-sdk size report |
|
@launchdarkly/browser size report |
|
@launchdarkly/js-client-sdk-common size report |
|
@cursor review |
a0956f5 to
a076b4f
Compare
a390a52 to
240dd82
Compare
SDK-2283
45279a8 to
da346b2
Compare
…rovider.ts Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit bf81b26. Configure here.
| (convertedContext as any)[key] = value; | ||
| } else { | ||
| logger.error(`The attribute '${key}' must be of type ${LDContextBuiltIns[key]}`); | ||
| } |
There was a problem hiding this comment.
Prototype property lookup causes incorrect attribute rejection
Low Severity
The key in LDContextBuiltIns check uses the in operator, which traverses the prototype chain. This means context attributes named after Object.prototype properties (e.g., constructor, toString, valueOf) will incorrectly match, enter the type-validation branch, and be rejected with a confusing error message. The check against LDContextBuiltIns[key] would then return a function (the inherited method) rather than a type string, guaranteeing the typeof value === comparison fails. Using Object.hasOwn(LDContextBuiltIns, key) or Object.prototype.hasOwnProperty.call(LDContextBuiltIns, key) would fix this.
Reviewed by Cursor Bugbot for commit bf81b26. Configure here.


This PR will initialize the migration of openfeature node server provider to js-core. Specifically, this PR will create a shared openfeature server provider base class.
REVIEWER: The logic in this should be a more generalized version of https://github.com/launchdarkly/openfeature-node-server/tree/main.
Theoretically, this would allow us to implement openfeature providers pretty easily (eg https://github.com/launchdarkly/js-core/blob/skz/sdk-2213/openfeature-migration/packages/sdk/openfeature-node-server/src/LaunchDarklyProvider.ts)
Note
Low Risk
Low risk because this PR only adds a new, pre-release shared package and wiring (workspace/tsc/release-please) without changing behavior of existing SDKs. Main risk is limited to build/release configuration and the correctness of the new translation/provider utilities for future adopters.
Overview
Introduces a new pre-release workspace package,
@launchdarkly/openfeature-js-server-common, exportingBaseOpenFeatureProviderplus utilities to translate OpenFeature evaluation contexts/results and tracking event details to LaunchDarkly equivalents.Adds full package scaffolding (tsup/tsconfig/jest config, README/LICENSE, and unit tests) and wires it into the monorepo via
package.jsonworkspaces, roottsconfigreferences, andrelease-pleasemanifest/config so it can be versioned and built independently.Reviewed by Cursor Bugbot for commit bf81b26. Bugbot is set up for automated code reviews on this repo. Configure here.