Announcing OpenFeature providers for Featurevisor

Featurevisor now has OpenFeature providers for JavaScript, Go, Swift, Java, Ruby, Python, and PHP.

You can keep managing feature flags, variations, variables, targeting rules, and gradual rollouts with Featurevisor, while applications evaluate them through the standard OpenFeature API.

Note: This doesn't change anything for existing consumers of Featurevisor SDKs.

Supported platforms#

Providers are available for:

Each provider follows the conventions of its language and the official OpenFeature SDK for that platform. The behaviour remains aligned across providers, including context mapping, resolution reasons, errors, metadata, lifecycle, and tracking.

The providers are optional. Applications using only the regular Featurevisor SDK do not need to adopt OpenFeature or include its runtime dependencies.

Getting started in Node.js#

Install the Featurevisor provider and the official OpenFeature server SDK:

$ npm install --save \
    @featurevisor/openfeature-provider-node \
    @openfeature/server-sdk

Create the provider with a Featurevisor datafile and register it with OpenFeature:

import { OpenFeature } from '@openfeature/server-sdk'
import { FeaturevisorOpenFeatureProvider } from '@featurevisor/openfeature-provider-node'
const provider = new FeaturevisorOpenFeatureProvider({
  datafile,
})
await OpenFeature.setProviderAndWait(provider)
const client = OpenFeature.getClient()
const enabled = await client.getBooleanValue(
  'checkout',
  false,
  { targetingKey: 'user-123' },
)

The browser provider follows the same shape using @featurevisor/openfeature-provider-web and @openfeature/web-sdk.

Flags, variations, and variables#

OpenFeature evaluates one flag key at a time. Featurevisor also has variations and variables, so the providers use a small key convention:

OpenFeature key	Featurevisor evaluation
`checkout`	Flag value for `checkout`
`checkout:variation`	Variation value for `checkout`
`checkout:title`	Value of the `title` variable belonging to `checkout`

Use the OpenFeature resolver matching the expected value. For example, use the boolean resolver for flags and boolean variables, the string resolver for variations and string variables, and the object resolver for structured values.

The separator and reserved variation selector can be configured if they conflict with your project keys.

Evaluation context#

The OpenFeature targeting key maps to userId in Featurevisor by default:

{
  targetingKey: 'user-123',
  country: 'nl',
  plan: 'premium',
}

This works naturally for projects that bucket users by userId. If your project uses another attribute, configure the provider's targeting key field.

The full OpenFeature evaluation context is copied into Featurevisor without mutating the original context. OpenFeature handles its context merging and hooks, while Featurevisor modules continue to run inside the Featurevisor evaluation pipeline.

Resolution details#

The providers translate Featurevisor evaluation details into standard OpenFeature results:

Featurevisor result	OpenFeature result
Required, forced, sticky, or rule match	`TARGETING_MATCH`
Traffic allocation	`SPLIT`
Disabled result	`DISABLED`
Default value or no match	`DEFAULT`
Missing feature or variable	`ERROR` with `FLAG_NOT_FOUND`
Wrong resolver type	`ERROR` with `TYPE_MISMATCH`
Invalid datafile	`ERROR` with `PARSE_ERROR`

Where supported by the platform, metadata includes the Featurevisor reason, revision, schema version, feature and variable keys, matching rule, bucket information, and other evaluation details.

Bring your own Featurevisor instance#

A provider can create and own its Featurevisor instance:

const provider = new FeaturevisorOpenFeatureProvider({
  datafile,
  modules: [trackingModule],
  onDiagnostic(diagnostic) {
    // forward to your observability system
  },
})

It can also reuse an instance already owned by the application:

import { createFeaturevisor } from '@featurevisor/sdk'
const featurevisor = createFeaturevisor({
  datafile,
  modules: [trackingModule],
})
const provider = new FeaturevisorOpenFeatureProvider({
  featurevisor,
})

This is useful when an application needs both APIs. Existing code can continue using Featurevisor directly while another part of the application uses OpenFeature.

When the provider creates the instance, it closes that instance during provider shutdown. When an existing instance is supplied, the application keeps ownership and closes it after every consumer is finished.

Why OpenFeature?#

Featurevisor remains focused on feature management through Git, deterministic datafile generation, local evaluation, and a consistent SDK model across platforms.

OpenFeature provides a vendor neutral application API around feature flag evaluation. Supporting it gives teams another way to adopt Featurevisor:

Existing OpenFeature applications can use Featurevisor without rewriting their evaluation layer.
Platform teams can offer one API across applications while keeping Featurevisor as the underlying implementation.
Applications can use OpenFeature hooks and context management together with Featurevisor modules, diagnostics, and datafiles.
Teams can adopt the provider gradually because the regular Featurevisor API remains available.

Get started#

Visit the OpenFeature provider guide for the shared conventions and links to every supported language.