Uh oh!
There was an error while loading. Please reload this page.
feat(feature-flags): add wizard feature-flags install skill - #378
feat(feature-flags): add wizard feature-flags install skill#378fristovic wants to merge 3 commits into
Conversation
| `advanced_disable_feature_flags: true` in test/CI stops forgotten CI jobs from polling `/flags` (see `cutting-costs.md`). A missing token in production is a no-op (render `children`); in development throw the missing-config error named in the framework guidelines. | ||
| **If `instrumentation-client.ts` (or `.js`) already inits `posthog-js`:** move that init into this provider so bootstrap can be passed per request. Keep the existing `api_host` / `defaults` / other options. Do not leave both inits in place. Do not follow any framework note that says to keep init in `instrumentation-client.ts` — that path cannot take per-request bootstrap. |
There was a problem hiding this comment.
this might work better as a commandment (check and see if it already is, it might be) and see what this might contradict with in commandments in general
gewenyu99
left a comment
There was a problem hiding this comment.
Hey, this is a great start. I have some suggestions:
- I'm not sure if I understand who would want/need this Wizard
- Try setting up feature flags yourself, think about the pain points/difficult bits that someone is likely to fumble on, see if this resolves those issues.
- I would think about this program's relationship to the main PostHog integration program and shared skill reuse. I think this contains a less reliable but duplicate version of many of they paths.
| Record: package manager, whether `src/` is used, and whether PostHog is already initialized (`posthog.init`, `PostHogProvider`, `instrumentation-client`, `posthog-js` / `posthog-node` in dependencies). If flags are already wired the way this skill describes (`evaluateFlags` + bootstrap + a gated call site), verify they are correct and skip to STEP 10. | ||
| ### STEP 2: Credentials |
There was a problem hiding this comment.
If we're installing the package, we can init this for them. There's examples you can copy from, the OAuth session will let you grab the token on the wizard side to add them. I think it'd be pretty odd to have an environment variable -> have no integration.
| ```ts | ||
| import { PostHog } from 'posthog-node' | ||
| export function PostHogServer(token: string) { |
There was a problem hiding this comment.
I'm gonna throw you one more wrench, you'll need to figure out a reasonable lower bound for the patterns you apply here. The way Next versions work across the board differs, and changes how PostHog need to be initialized. There are examples here in the repo
| Flags change production UI. Ask **once**, then create a flag and gate only if they picked a target. | ||
| 1. Scan pages and components for additive surfaces (a banner, an extra card, an empty-state illustration). Prefer a new element over wrapping existing critical logic. |
There was a problem hiding this comment.
🤔 Do you think someone is more likely to come to this program with a thing they have in mind and wanna gate, or do you think they'd be looking for suggestions on what to gate?
| const token = process.env.NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN | ||
| const cookieStore = await cookies() | ||
| const distinctId = | ||
| cookieStore.get('ph_distinct_id')?.value ?? crypto.randomUUID() |
There was a problem hiding this comment.
PostHog always generates a distinct_id on the frontend. You can call posthog.get_distinct_id(). If they're not identified, they'd have an anonymous distinct Id that's merged with the user on identify.
There's already
wizard audit feature-flags(read-only) and a docs-onlyfeature-flagsgroup. Neither of those actually wires flags into an app.This adds
feature-flags-setupforwizard feature-flags. Next.js App Router only: evaluate on the server withevaluateFlags(), bootstrap into the client, create one boolean flag, and gate one UI path after the user confirms. Other stacks abort instead of growing a second pattern.