feat(onboarding): Implement SCM platform & features step

[jaydgoss]

Implement the SCM_PLATFORM_FEATURES onboarding step -- the second step in the SCM-first onboarding flow where users select a platform and features after connecting their SCM.

What it does

Two variants depending on whether the user connected their SCM in the previous step:

SCM connected: Calls the platform detection API to identify platforms from the repository. Detected platforms are rendered as selectable cards with the first auto-selected. Falls through to manual selection if detection returns no results.

Skipped SCM: Shows a searchable dropdown for manually picking from 100+ platforms. Base languages (JavaScript, Python, etc.) trigger a framework suggestion modal.

Both variants share a feature selection card grid. Error Monitoring is always on. Available features are filtered by platformProductAvailability and gated by the user's plan via getDisabledProducts (disabled features show a tooltip with the reason). Profiling requires tracing -- enabling profiling auto-enables tracing, disabling tracing auto-removes profiling. Gaming/console platforms are blocked when not enabled for the org.

How state flows

Platform and feature selections use derived state locally (e.g. selectedPlatform?.key ?? detectedPlatformKey) and are persisted to OnboardingContext in the Continue handler. Platform detection is pre-warmed in SCM_CONNECT via React Query cache sharing.

New files

• useScmPlatformDetection.ts -- hook wrapping the platform detection API
• scmFeatureSelectionCards.tsx -- 2-column feature card grid with heading and count
• scmFeatureCard.tsx -- individual feature card with icon, checkbox, and tooltip
• scmPlatformCard.tsx -- detected platform card with platform icon and name
• scmCardButton.tsx -- shared unstyled button primitive for card click semantics
• detectedPlatform.ts (fixture) -- test fixture for detected platform data

Follow-up

VDY-30 -- sync feature selections from context into SetupDocs URL params.

Refs VDY-23

[linear-code]

VDY-23 SCM platform-features step: functional implementation with platform detection

[github-actions]

🚨 Warning: This pull request contains Frontend and Backend changes!

It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently.

Have questions? Please ask in the #discuss-dev-infra channel.

[TkDodo]

just leaving some low importance post-merge cleanup points if you get to it.

[TkDodo]

as far as I can see, none of the useMemo or useCallbacks in this file are necessary. All we do at the end is pass those to another component, which isn’t memoized. None of the operations seem expensive either:

const disabledProducts = getDisabledProducts(organization);

is perfectly fine 🤷 . It would remove a bunch of cognitive load and about 30 loc.

[TkDodo]

reducing from an array into an array can usually be represented with a simpler alternative, in this case, a flatMap:

const resolvedPlatforms = detectedPlatforms.flatMap(detected => {
  const info = getPlatformInfo(detected.platform);
  return info ? [{...detected, info}] : [];
});

[TkDodo]

@JonasBa I think we need better skills for how to do this in new code. The recommended approach would be apiOptions with skipToken:

const query = useQuery(
  apiOptions.as<PlatformDetectionResponse>()(
    '/organizations/$organizationIdOrSlug/repos/$repoId/platforms/',
    {
      path: repoId
        ? {organizationIdOrSlug: organization.slug, repoId}
        : skipToken,
      staleTime: 30_000,
    }
  )
);

I just told claude “rewrite this to apiOptions” and it did a good job, so we have to nudge it in that direction per default.

The advantage of using skipToken also means we don’t need a no-null assertion when building the path.