Premium Analytics: route packages, widgets and routes through the externals module

[louwie17]

Fixes #

Proposed changes

Follow-up to #50932 (WOOA7S-1836), which added @jetpack-premium-analytics/externals and migrated packages/widgets-toolkit. Everything else still imported those libraries directly, so they were still compiled in more than once. This finishes the migration and locks it in with lint.

• Route packages/ui, packages/fields, packages/icons, and all of widgets/ and routes/ through the passthrough module — 69 files in total.
• Add the missing re-exports: Fieldset, Input, the Field namespace, and the Option / ViewBaseProps / DataViewRenderFieldProps DataViews types.
• @wordpress/ui's Field namespace collides with DataViews' Field type under one barrel, so it is re-exported as FormField. DataViews' Field keeps its name — it is what consumers already import from here.
• Move @automattic/ui into externals too. DateRangeCalendar is its only consumer in the package, but it reaches react-day-picker behind it — ~55 KB of vendor code that was re-emitted on every edit to packages/ui.
• date-fns deliberately stays out. ~30 files import it directly across data, datetime, routing, widgets/ and routes/, and it is tree-shaken per function, so routing it through here would mean a barrel that grows every time any consumer needs one more function — exactly the churn this module exists to avoid.

The ESLint guard

Now covers packages/**, widgets/** and routes/**, with packages/externals excluded (it is the passthrough). Stylesheet imports stay allowed everywhere — plain CSS carries none of the bundling cost.

Under widgets/ and routes/ the rule splits in two: @automattic/charts must still come from @jetpack-premium-analytics/widgets-toolkit, which themes the chart components and takes charts from externals itself; the design-system libraries come straight from externals. Both patterns live in one ESLint block on purpose — a second files entry naming no-restricted-imports again would replace the rule for those paths rather than add to it, silently dropping the charts guard. The charts pattern also moves from group to regex so it picks up the same .css exemption as the rest.

Build output

artifact	trunk	this PR	delta
modules/ui/index.min.js	766,662	173,201	−77.4%
modules/ui/index.min.js.map	3,749,692	561,370	−85.0%
modules/fields/index.min.js	243,511	11,450	−95.3%
modules/fields/index.min.js.map	1,202,474	96,740	−92.0%
widget render bundles (150 files)	958,410	604,295	−36.9%
route bundles (12 files)	3,867,104	3,736,108	−3.4%
modules/externals/index.min.js	1,074,665	1,159,187	+7.9%

Whole build: 22,044 KB → 17,060 KB.

Attributing minified bytes through the source map, ui goes from 18% to 82% first-party. fields was only 3% first-party — almost the entire module was @wordpress/ui and its transitive deps.

Routes move least because webpack was already tree-shaking them down to the few components each one used — routes/dashboard only pulled in Stack, so it is flat. The small route bundles still drop sharply (syncing −82.8%, connect −49.9%), and every route and widget asset now lists @jetpack-premium-analytics/externals under module_dependencies, so none of them can re-inline the libraries going forward. That structural guarantee is the point more than the byte count.

One expected side effect: fields drops out of i18n-manifest.json. It has no translatable strings of its own, so every string it carried came from the inlined @wordpress/ui copy, which now lives once in externals.

Rebased on trunk b2d013e031; the table above is measured against it. Trunk work that landed while this was open needed the same migration to satisfy the widened rule: the Comments-widget split (#50929), the new /reports/locations route, and the preset-measuring probe added by #50906.

Test mocks

Three suites needed updating — both cases are the barrel deepening the import graph:

• routes/reports/{tags,comments}/config/fields.test.tsx and report-csv-exports.test.tsx mocked @wordpress/ui, which the components no longer import, leaving the mocks inert. Retargeted to the externals barrel behind a lazy Proxy so the rest of it still resolves.
• routes/{video,post}-detail/stage.test.tsx mocked @wordpress/data with only useSelect. Reaching externals pulls @wordpress/components → @wordpress/rich-text into the graph, whose store calls combineReducers at import time, so those suites failed to load. Same lazy Proxy fallthrough.

Related product discussion/links

• Follows Premium Analytics: compile shared third-party libraries into their own module #50932 / WOOA7S-1836.

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

No.

Testing instructions

This is a build-output change with no intended user-visible effect, so the goal is to confirm nothing regressed.

Automated

• cd projects/packages/premium-analytics
• pnpm run typecheck, pnpm exec eslint . --ext .ts,.tsx,.mjs, pnpm run test — all clean (212 suites / 1495 tests).
• pnpm run build-production, then check that build/modules/{ui,fields}/index.min.asset.php and every build/{widgets,routes}/**/*.min.asset.php list @jetpack-premium-analytics/externals under module_dependencies — that is the proof the libraries are externalised rather than inlined.

Guard

Drop a throwaway file into packages/ui/src/, widgets/<any>/ and routes/<any>/ importing @wordpress/ui, @automattic/ui, @automattic/charts, a charts subpath, an import type from @wordpress/dataviews, and a .css import. Everything but the .css import must error; under widgets//routes/ the charts ones must point at widgets-toolkit while the rest point at externals. The same file under packages/externals/src/ must produce no errors.

Dashboard

Load the dashboard (?page=jetpack-premium-analytics) and confirm it renders as before: tabs, the date preset row, the "Compare to" dropdown, charts, widgets, and the report pages under /reports/*. Open the Custom date range and confirm the calendar still renders — DateRangeCalendar now crosses a module boundary, so it is the highest-risk item here.

Verified locally: all six script modules load, zero console/page errors, and every symbol crossing the new module boundary resolves from the built externals module (including DateRangeCalendar as a real function, plus FormField.Root, Tabs.Panel and Fieldset.Legend).

🤖 Generated with Claude Code

https://claude.ai/code/session_01TsoMLFnEC9XsUJxNiP3VZ5

[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 or WordPress.com Site Helper), and enable the fix/premium-analytics-ui-externals branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack fix/premium-analytics-ui-externals

bin/jetpack-downloader test jetpack-mu-wpcom-plugin fix/premium-analytics-ui-externals

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!

[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

[chihsuan]

Thanks for this! @louwie17

Left a minor comment for SectionTabPanel docblock but tested well locally and looks good.

[chihsuan]

Should we flip this one around?

[louwie17]

Yeah, thanks good catch!

[louwie17]

Good catch — that wording described a state partway through the branch. It was accurate when packages/ui was migrated, but the follow-up commit moved routes/ and widgets/ onto the passthrough too, which made "still import @wordpress/ui directly" false.

Flipped it to state the invariant instead: panel and root have to come from the same Tabs instance, and importing from externals is what makes that instance shared.

Also rebased on trunk — #50929 split the Comments widget while this was open, so most-commented-posts/most-commented-authors and the new /reports/locations route needed the same migration to satisfy the widened lint rule.