Migrate off another flag vendor via OpenFeature

You're moving off another feature-flag vendor, and your codebase has hundreds of getBooleanValue("new_checkout", false, ctx) call sites scattered through it. Rewriting every one to a new SDK's API is a big, risky diff that touches files no one wants to touch. You want to swap the backend without touching the call sites.

If your app already speaks OpenFeature, that's exactly what the ShipeasyProvider is for: it's a pure adapter over an Engine, so you change one line — which provider is registered — and every existing OpenFeature call keeps working.

Swap the provider, keep the call sites

import { OpenFeature } from "@openfeature/server-sdk";
import { Engine } from "@shipeasy/sdk/server";
import { ShipeasyProvider } from "@shipeasy/sdk/openfeature-server";

const engine = new Engine({ apiKey: process.env.SHIPEASY_SERVER_KEY! });
await OpenFeature.setProviderAndWait(new ShipeasyProvider(engine));

// every existing call site is unchanged:
const ofClient = OpenFeature.getClient();
const on = await ofClient.getBooleanValue("new_checkout", false, { targetingKey: "u1" });

The OpenFeature targetingKey maps to the Shipeasy user_id; any other context fields become user attributes for targeting. The web SDK is the mirror image — register the provider from @shipeasy/sdk/openfeature-web over a browser Engine.

Reasons come along for free

getBooleanDetails(...) keeps returning a standard OpenFeature ResolutionDetails: the provider maps Shipeasy evaluation reasons onto StandardResolutionReasons and Shipeasy outcomes onto OpenFeature ErrorCodes (e.g. FLAG_NOT_FOUND). Any tooling you built around OpenFeature details still understands the output.

Rollout & measurement plan

Once you're stable, weigh dropping OpenFeature for the native SDK — it's simpler and gives you configs, experiments, and tracking directly. But the migration itself is the cheap part precisely because the provider is a drop-in.