Error tracking docs: recommend the error-tracking wizard command behind a flag

[ablaszkiewicz]

Summary

The error tracking docs recommend the wizard on three pages. The wizard adds a dedicated error-tracking command that installs the SDK, sets up exception capture, and sets up source map upload (PostHog/wizard#1185). Until that command ships, the pages must keep the current commands.

This PR lets those pages swap to error-tracking while the PostHog feature flag error-tracking-new-wizard is on. With the flag off, the pages do not change.

• WizardCommand gets an optional flagCommand prop. The server render and the first client render show the current command. When the flags load and the flag is on, the component shows the flagged subcommand.
• The installation index, the upload source maps index, and the wizard snippet shared by the webpack, CLI, Nuxt, and Angular source map pages pass flagCommand={{ flag: 'error-tracking-new-wizard', command: 'error-tracking' }}.
• The commands table on the AI wizard page does not change. A markdown table cannot read a flag, so the wizard error-tracking row comes with the wizard release.

The app side of the same rollout is PostHog/posthog#100838.

🗺️ PR tour

Stop 1: WizardCommand learns a flagged subcommand (diff)

The component keeps its old props. The new flagCommand prop names a flag and a subcommand. Without the prop, the component renders as before. With the prop, RenderInClient shows the current command as the placeholder, then renders FlaggedWizardCommand, which reads the flag with posthog.isFeatureEnabled and picks the subcommand.

posthog.com/src/components/WizardCommand/index.tsx

Lines 41 to 62 in 3cff908

	export default function WizardCommand({ flagCommand, ...props }: WizardCommandProps): JSX.Element {
	if (!flagCommand) {
	return <InlineWizardCommand {...props} />
	}
	return (
	<RenderInClient
	placeholder={<InlineWizardCommand {...props} />}
	render={() => <FlaggedWizardCommand flagCommand={flagCommand} {...props} />}
	/>
	)
	}
	function FlaggedWizardCommand({
	flagCommand,
	command,
	...props
	}: Omit<WizardCommandProps, 'flagCommand'> & { flagCommand: FlagCommand }): JSX.Element {
	const posthog = usePostHog()
	const enabled = posthog?.isFeatureEnabled?.(flagCommand.flag)
	return <InlineWizardCommand {...props} command={enabled ? flagCommand.command : command} />
	}

⚠️ The flag read sits in a child component, not in the render callback. RenderInClient calls render() inside its own render, so a hook in that callback would change the hook count between the placeholder and the real render.

Stop 2: The three error tracking pages (installation, source maps index, source maps snippet)

Each page passes the same flagCommand. The installation index showed the base command. The two source map call sites showed upload-source-maps. The prose around each command does not change, because the error-tracking command also does what each paragraph describes.

posthog.com/contents/docs/error-tracking/installation/index.mdx

Lines 10 to 14 in 3cff908

	Install PostHog in seconds with our wizard by running this command in your project directory with your terminal (it also works for [LLM coding agents](/blog/envoy-wizard-llm-agent) like Cursor and Bolt):
	<WizardCommand flagCommand={{ flag: 'error-tracking-new-wizard', command: 'error-tracking' }} />
	Wait for it to finish and test the setup once the wizard is complete.

🔍 Reviewer's guide

Testing done

Check	Command / method	Result
Formatting	pnpm exec prettier --check src/components/WizardCommand/index.tsx	No changes needed
Dev server	pnpm start (Node 22), loaded /docs/error-tracking/installation, /docs/error-tracking/upload-source-maps, and /docs/error-tracking/upload-source-maps/webpack	Pages render
Flag off	Headless Chromium with a posthog-js stand-in that answers false for the flag, on the three pages	Each page shows the same command as master
Flag on	The same stand-in answering true for error-tracking-new-wizard	Each page shows npx @posthog/wizard error-tracking
Console	Console errors captured on master and on this branch, flag off and on, on the three pages	No new errors. The one difference is a pre-existing validateDOMNesting warning whose component stack now names FlaggedWizardCommand
Window sizes	640px and 1440px viewports, light and dark	The command block wraps inside the column at both widths

Not tested: the real posthog-js flag load on the production site. The local checks stub the flag answer, because the dev build does not initialize posthog-js.

Screenshots

Pending upload. The before/after grid for the three pages is captured and follows in an edit.

What to look at

1. FlaggedWizardCommand reads the flag once per render and does not subscribe to later flag changes. RenderInClient mounts it after onFeatureFlags fires, or after its five second fallback, so the first read has the flags. A page that loads flags later than that keeps the current command until a reload.
2. The flag key appears three times in MDX. A typo in one page silently keeps the old command on that page. Search for error-tracking-new-wizard when the flag is renamed or removed.

🤖 Generated with Claude Code

[github-actions]

Deploy preview

Status	Details	Updated (UTC)
🟢 Ready	View preview	Sep 15, 2026 12:14PM

Changed pages

Page	Source
Install Error Tracking with PostHog	contents/docs/error-tracking/installation/index.mdx
Upload source maps	contents/docs/error-tracking/upload-source-maps/index.mdx

[github-actions]

Bundle report

Total JS (gzip)

8.78 MiB (+0.2 KiB / +0.0%)

Eager graph (modules shipped in each entrypoint's initial chunks)

Entrypoint	Eager size	Budget	Modules
✅ app	18.51 MiB (+2.2 KiB / +0.0%)	report-only	2062

Largest modules in the app closure

Module	Size
./src/data/mcp-tools.json	1137.9 KiB
css ./node_modules/.pnpm/css-loader@5.2.7_webpack@5.101.3/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[8].oneOf[1].use[1]!./node_modules/.pnpm/postcss-loader@4.3.0_postcss@8.5.6_webpack@5.101.3/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[8].oneOf[1].use[2]!./src/styles/global.css	773.5 KiB
./src/components/Stickers/Stickers.tsx	696.4 KiB
./node_modules/.pnpm/@radix-ui+react-icons@1.3.2_react@18.3.1/node_modules/@radix-ui/react-icons/dist/react-icons.esm.js	481.4 KiB
./node_modules/.pnpm/@posthog+brand@0.8.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/x-ray.mjs	480.8 KiB
./node_modules/.pnpm/rehype-raw@7.0.0/node_modules/rehype-raw/lib/index.js + 29 modules	395.1 KiB
./node_modules/.pnpm/@posthog+brand@0.8.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/im-the-driver.mjs	385.7 KiB
./src/hooks/useCustomers.tsx + 55 modules	370.0 KiB
./node_modules/.pnpm/@posthog+icons@0.36.6_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js	354.8 KiB
./node_modules/.pnpm/react-markdown@8.0.7_@types+react@16.14.66_react@18.3.1/node_modules/react-markdown/lib/react-markdown.js + 88 modules	351.4 KiB
./src/components/ProductComparisonTable/index.tsx + 126 modules	305.7 KiB
./node_modules/.pnpm/cloudinary-core@2.14.0_lodash@4.17.21/node_modules/cloudinary-core/cloudinary-core.js	281.9 KiB
./node_modules/.pnpm/@posthog+brand@0.8.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/doll-house.mjs	281.7 KiB
./node_modules/.pnpm/@posthog+brand@0.8.0_react@18.3.1/node_modules/@posthog/brand/dist/generated/hoggies/svg/director.mjs	275.6 KiB
./src/components/SearchUI/index.tsx + 87 modules	273.7 KiB

---

Eager-graph budgets are report-only until a baseline is established. Sizes are gzip of public/**/*.js; eager size is webpack module source bytes for the modules actually shipped in the entrypoint's initial chunks (post-tree-shake).