Loading...
Inspect the work · synthetic examples
Real engine output, small enough to inspect. Follow the input, generated changes, and checks that still stand between a preview and a pull request.
No customer data. No network requests or PR publication. LaunchDarkly remains the runtime backend.
01 / Generated preview
This fixture starts with the LaunchDarkly Node SDK. The engine adds the OpenFeature SDK and LaunchDarkly provider, changes initialization, and maps the evaluation context. These are the generated changes, unchanged for this example.
Parse, manifest, and residual checks passed. Required typechecking and tests were unavailable in this offline run. The lockfile check was skipped. Static checks do not prove runtime equivalence.
--- a/package.json
+++ b/package.json
@@ -1,10 +1,12 @@
-{
- "name": "shop",
- "dependencies": {
- "@launchdarkly/node-server-sdk": "^9.8.1"
- },
- "scripts": {
- "test": "vitest",
- "typecheck": "tsc --noEmit"
- }
-}
+{
+ "name": "shop",
+ "dependencies": {
+ "@launchdarkly/node-server-sdk": "^9.8.1",
+ "@launchdarkly/openfeature-node-server": "^1.2.0",
+ "@openfeature/server-sdk": "^1.22.0"
+ },
+ "scripts": {
+ "test": "vitest",
+ "typecheck": "tsc --noEmit"
+ }
+}
--- a/src/flags.ts
+++ b/src/flags.ts
@@ -1,12 +1,10 @@
-import * as ld from '@launchdarkly/node-server-sdk'
-const FLAG_KEY = 'new-checkout'
-const client = ld.init(process.env.LD_SDK_KEY!)
-
-export async function enabled(): Promise<boolean> {
- await client.waitForInitialization()
- return client.variation(
- FLAG_KEY,
- { key: 'customer-1', custom: { plan: 'pro' } },
- false,
- )
-}
+import { OpenFeature } from '@openfeature/server-sdk'
+import { LaunchDarklyProvider } from '@launchdarkly/openfeature-node-server'
+const FLAG_KEY = 'new-checkout'
+const launchDarklyProvider = new LaunchDarklyProvider(process.env.LD_SDK_KEY!)
+const client = OpenFeature.getClient()
+
+export async function enabled(): Promise<boolean> {
+ await OpenFeature.setProviderAndWait(launchDarklyProvider)
+ return client.getBooleanValue(FLAG_KEY, false, { targetingKey: 'customer-1', plan: 'pro' })
+}
The homepage evidence script runs FlagShark’s deterministic preview planner on synthetic input adapted from its golden regression fixture. Input, output, and engine source hashes are included in the JSON download.
Source revision: 90600d7cf9c93f491f57ea19875402a08943ae78
Reproduce in an authorized FlagShark source checkout with dependencies installed:
bun scripts/generate-homepage-evidence.tsThe migration engine is proprietary and is not distributed with this sample. The public scanner is a separate open-source tool.
02 / Separate assessment fixture
This complete assessment comes from a different regression fixture: one typed evaluation and two setup blockers. It is not the input to the preview above. Assessment produces a plan; it does not edit code.
The report’s “Axis B” evaluates flag-configuration compatibility. It does not promise a configuration migration: this example explicitly keeps LaunchDarkly and sets “Migrate flag configuration” to “no.”
Download the complete Markdown report ↓This is a synthetic test fixture from FlagShark’s migration-assessment regression suite, not a customer assessment or a statement of current support for your repository. Counts and effort estimates below apply only to this fixture. The full report is preserved so you can inspect its evidence, scope, and blockers. Current support: https://flagshark.com/platform/openfeature/#support
“Axis B” below assesses flag-configuration compatibility, not configuration migration. This example retains LaunchDarkly as its backend and explicitly does not migrate flag configuration.
adopt-openfeature/launchdarkly-node-server/ecmascript/server@2assessment (highest supported: verification; built-in-verified)adopt-openfeature@openfeature/server-sdk@launchdarkly/openfeature-node-serverprodhttps://app.launchdarkly.com/api/v2 · API 20240415 · source workspace:workspace-1:project:prod · unarchived-and-archived| Disposition | Count | Share of observed |
|---|---|---|
| 🟢 Automation candidate | 1 | 100% |
| 🟡 Assisted | 0 | 0% |
| 🔴 Manual | 0 | 0% |
| Disposition | Count | Share of observed |
|---|---|---|
| 🟢 Automation candidate | 1 | 100% |
| 🟡 Assisted | 0 | 0% |
| 🔴 Manual | 0 | 0% |
This is an assessment-only estimate: green items are deterministic automation candidates, but no source changes were generated.
1 Automation candidate × 2m + 0 Assisted × 5m + 2 Manual × 30m = ~1h 2m.
These items are part of the scoped inventory. Classified items are included in the estimate even when they are assisted rather than blocking.
| Disposition | Kind | Flag | Location | Required work |
|---|---|---|---|---|
| 🔴 Manual | dependency-replacement | — | acme/web:package.json |
Add @openfeature/server-sdk and the runtime-provider package identified by the assessment target; retain or remove @launchdarkly/node-server-sdk@^9.11.0 according to residual direct usage. |
| 🔴 Manual | provider-initialization | — | acme/web:src/flags.ts:2:16 |
Replace direct LaunchDarkly initialization with OpenFeature provider registration for the runtime provider identified by the assessment target. |
2 blocking items must be resolved before the migration is complete:
acme/web:package.json: Add @openfeature/server-sdk and the runtime-provider package identified by the assessment target; retain or remove @launchdarkly/node-server-sdk@^9.11.0 according to residual direct usage.acme/web:src/flags.ts:2:16: Replace direct LaunchDarkly initialization with OpenFeature provider registration for the runtime provider identified by the assessment target.| Disposition | Source role | Flag | Location | LD → OpenFeature | Evidence-qualified note |
|---|---|---|---|---|---|
| 🟢 Automation candidate | production | checkout-v2 |
acme/web:src/flags.ts:4:10 |
boolVariation → getBooleanValue |
Typed value evaluation with a deterministic argument reorder. |
| Disposition | Flag | LD version | Environments / archive | Config inventory | Basis | Reasons |
|---|---|---|---|---|---|---|
| 🟢 Automation candidate | checkout-v2 |
1 | 1 total; 0 archived | 0 rules; 0 segment references (none); 0 rollouts; 0 target values; 0 prerequisites (none); 0 experiment metrics; event tracking in 0 environments (0 fallthrough); purpose: standard; context kinds: none | backend-agnostic | Simple typed definition with no targeting complexity; final portability still depends on the selected backend. |
| Repository | Status | Source | Commit | Acquired files | Source bytes | Analyzer coverage |
|---|---|---|---|---|---|---|
acme/web |
complete | https://api.github.com · API 2022-11-28 · installation:inst-1 |
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
2/2 | 272 | 1/1 parsed · 0 parse errors · 1 manifests |
03 / Cleanup UI regression scenario
The homepage’s retirement example is adapted from a dashboard test. In that simulated scenario, provider evidence supports retaining the true branch of checkout-v2 and the required test passes on the generated commit. The PR remains a draft under its recorded policy. Merge and default-branch verification have not happened.
This demonstrates how the product distinguishes evidence, checks, and completion. It is a UI fixture, not a customer result or a live cleanup run.
Inspect the scenario and source provenance ↓04 / Executed cleanup simulator
We ran the existing deterministic cleanup exercise against four checked-in JavaScript and TypeScript fixtures. The real pinned Piranha transformation was checked against the expected code, including compile gates and removal of the target flag. The lifecycle then progressed through simulated draft publication, CI, human merge and default-branch verification.
No external services were called. GitHub, CI and human merges were simulated. This does not establish production behavior, customer results or general availability. The separate migration preview above still has publication blocked.
Inspect the TypeScript scheduled-cleanup fixture below. The intended branch remains. The separate sibling evaluation remains too; the exercise proves removal of this target flag, not every flag in the repository.
- import type { LDClient, LDContext } from '@launchdarkly/node-server-sdk'
-
- export async function scheduledCheckout(client: LDClient, context: LDContext) {
- const siblingEnabled = await client.boolVariation('rga-launch-exercise-sibling', context, false)
- if (await client.boolVariation('rga-launch-exercise-candidate', context, false)) {
- return 'scheduled-new-checkout'
- }
- return siblingEnabled ? 'scheduled-legacy-checkout' : 'scheduled-fallback'
- }
-
+ import type { LDClient, LDContext } from '@launchdarkly/node-server-sdk'
+
+ export async function scheduledCheckout(client: LDClient, context: LDContext) {
+ const siblingEnabled = await client.boolVariation('rga-launch-exercise-sibling', context, false)
+ return 'scheduled-new-checkout'
+ }
+
Use an authorized source checkout with dependencies and polyglot-piranha 0.4.8 installed. Set PYTHON_BIN if that package is in a separate Python environment.
bun scripts/generate-homepage-cleanup-exercise.tsThe report contains the exercise source hash, the simulator scope, individual receipts and the results it does not prove.
Share your SDKs and repository scope. We’ll review pilot fit and the next step with you.
Request migration assessment