Components: migrate Tier 1 jetpack-components to @wordpress/components & @wordpress/icons

[CGastrell]

Tracks #48160 — first "easy wins" slice of the @automattic/jetpack-components → @wordpress/ui / @wordpress/components migration.

Proposed changes

Retires 5 named-import sites of @automattic/jetpack-components across 4 files in 3 packages, with WP design system equivalents. No user-facing visual changes for any state these consumers were already rendering on trunk — see "Visual impact" below.

File	Change
packages/my-jetpack/_inc/components/product-detail-card/index.jsx	Alert → Notice from @wordpress/components (level="warning" becomes status="warning"); StarIcon → Icon icon={starFilled} from @wordpress/icons.
packages/publicize/_inc/components/services/custom-inputs.tsx	Alert → Notice (Bluesky reconnect prompt).
packages/publicize/_inc/components/services/service-status.tsx	Alert → Notice (broken-connection / re-auth status).
packages/videopress/src/client/admin/components/input/index.tsx	SearchIcon → Icon icon={search} from @wordpress/icons. Note: SearchIcon from jetpack-components is the Jetpack Search product icon; this consumer was using it as a generic magnifying glass, which is a misuse. The product icon export stays in place for legitimate uses.

Out of scope, deliberately

A few "obvious" Tier 1 candidates were inspected and bumped:

• Dialog and Popover — names are misleading; in jetpack-components they're layout wrappers (sectioned panel, icon+body+action card respectively), not WP-style modal/popover primitives. Not drop-in replacements.
• H3 and Title — both wrap <Text>, which is itself in the migration backlog. Migrating these without Text is churn.
• CheckmarkIcon — looked like a one-line swap, but the Jetpack version is a green-circle-with-white-check while @wordpress/icons check is a monochrome stroke. PR My Jetpack: use ui-icon instead of CheckmarkIcon #48165 already attempted a global replacement and ran into design backlash without consensus. Holding all CheckmarkIcon swaps until that lands.
• NumberControl — promoted to intentional keeper. The Jetpack wrapper isn't a thin shim: it handles eslint-disable @wordpress/no-unsafe-wp-apis for the __experimentalNumberControl import AND provides a TextControl fallback when the experimental component isn't available. Worth keeping until WP ships a non-experimental NumberControl.
• ButtonProps type re-export — kept importing from jetpack-components. The original PR tried a local mirror, but Button itself is still in the migration backlog so decoupling its types now is premature.

Related product discussion/links

• Tracking issue: Jetpack UI Modernization #48160 (Jetpack UI Modernization)

Does this pull request change what data or activity we track or use?

No.

Visual impact

TL;DR — minor, edge-case-only. Most call sites are conditional and/or visually identical between old and new components. The only meaningful visual differences:

Component	Visible difference
Alert → Notice	Jetpack Alert has an inline warning icon at the start of the text. WP Notice has no inline icon but a thicker colored left-border accent.
StarIcon → Icon icon={starFilled}	Visually identical at the sizes used (16-24px).
SearchIcon → Icon icon={search}	Visually identical (both monochrome magnifying glass at 24px).

Where to actually look

The components migrated here render in conditional / edge-case states that aren't visible on a fresh install. Use these URLs and conditions to spot the changes:

Surface	URL	Condition required to see it
MJ Add Security / Add Extras / Add Scan / Add Growth / Add Complete (ProductDetailCard rendered via the legacy ProductInterstitial path)	/wp-admin/admin.php?page=my-jetpack#/add-security (or /add-extras, /add-scan, /add-growth, /add-complete)	The yellow Alert/Notice only appears when cantInstallPlugin is true (status === 'plugin_absent' AND fileSystemWriteAccess === 'no'). The "Popular upgrade" star pill appears at the top whenever the product is a bundle upsell. Most product slugs use a newer PricingInterstitial instead, which doesn't render this card.
Publicize / Social — connecting a Bluesky account	Social plugin admin → "Add new connection" → Bluesky → handle/app-password fields	The Alert/Notice ("Please provide an app password to fix the connection") only renders during a reconnection flow (when reconnectingAccount?.service_name === 'bluesky').
Publicize / Social — broken connection status	Social plugin admin → Connections list	The Alert/Notice ("X expiring/broken connection(s)") only renders when there's an actual broken or re-auth-required connection.
VideoPress dashboard search input	/wp-admin/admin.php?page=jetpack-videopress	The magnifying glass icon in the search input is always rendered — easiest visual confirmation.

Testing instructions

Easiest visual check (no special site state needed):

1. Visit /wp-admin/admin.php?page=jetpack-videopress and confirm the search input renders with a leading magnifying glass icon (rendered identically pre/post — @wordpress/icons search).

To trigger the cantInstallPlugin Notice on ProductDetailCard (the only non-trivial visual diff):

1. On a site where you can't install plugins (filesystem read-only, or simulate by setting WP_AUTO_UPDATE_CORE constraints), visit /wp-admin/admin.php?page=my-jetpack#/add-security.
2. The card should render with a yellow "Due to your server settings, we can't automatically install the plugin..." callout.
3. Compare against trunk: same callout, same copy, same yellow background — only the inline orange ⚠ icon (Jetpack Alert) is gone, replaced by the WP Notice left-border style.

Bluesky reconnect flow (Publicize Notice):

1. Connect a Bluesky account via Jetpack Social.
2. Reset/expire the app password externally.
3. On the site, attempt to reshare or open the connection management UI; the reconnection screen should render with a "Please provide an app password to fix the connection" notice.

No-state confirmation:

• pnpm jetpack build packages/my-jetpack, pnpm jetpack build packages/publicize, pnpm jetpack build packages/videopress — all build clean.
• Confirm grep -rE "from '@automattic/jetpack-components'" projects/packages/videopress no longer shows SearchIcon; packages/my-jetpack no longer shows StarIcon; packages/publicize no longer shows Alert.

Changelog

• Each affected package gets a patch / changed entry: "Components: migrate Tier 1 jetpack-components to @wordpress/components and @wordpress/icons (no user-facing change)." See changelog/migrate-tier1-jp-components in each affected package. (External Media gets a no-op changelog since the NumberControl change was reverted; its entry can be deleted on next push if it stays unchanged.)

🤖 Generated with Claude Code

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack), and enable the feat/migrate-tier1-jetpack-components branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack feat/migrate-tier1-jetpack-components

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

---

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

• WordPress.com Simple releases happen as soon as you deploy your changes after merging this PR (PCYsg-Jjm-p2).
• WoA releases happen weekly.
• Releases to self-hosted sites happen monthly:
  • Scheduled release: May 5, 2026
  • Code freeze: May 4, 2026

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report · JS report

[simison]

Why not Notice from @wordpress/ui instead?