feat(premium-analytics): port data package from next-woocommerce-analytics

[chihsuan]

Proposed changes

Second leaf in M2 — Shared Packages Integration: port @next-woo-analytics/data into @automattic/jetpack-premium-analytics as an internal package, stacked on the datetime port (#49221). Provides the analytics data layer — React Query report hooks, REST fetchers, query keys, response processing/normalization, prefetching, and the global query-client/error providers consumed by analytics widgets.

Stacked on #49221 (WOOA7S-1312), which it consumes: every date/preset helper in this package now imports from the already-integrated @jetpack-premium-analytics/datetime.

Commits

Reviewed most easily commit-by-commit — the verbatim copy is isolated first, so every later diff shows exactly what the monorepo port changed.

Commit	Subject	What to review
cf0cc3460a	feat(premium-analytics): copy data package from next-woocommerce-analytics	Verbatim copy — no review needed beyond provenance
cf58d7c7ce	refactor(premium-analytics): adapt data package imports and manifest for monorepo	Mechanical specifier rename + manifest/README adaptation
e48b30f4d5	refactor(premium-analytics): decouple data package from admin-toolkit experiments	The one semantic change (devtools gate)
d472a680b9	style(premium-analytics): apply jetpack prettier and eslint fixes to data package	Mechanical formatter/autofix output — safe to skim
9e656b7cd2	chore(premium-analytics): wire data package deps, lint overrides, and jest setup	Parent wiring: deps, eslint overrides, jest, changelog

Monorepo adaptations

Upstream	Here	Why
name: @next-woo-analytics/data	name: @automattic/jetpack-premium-analytics-data	Internal-packages convention (parent README.md): the import specifier (@jetpack-premium-analytics/data) comes from wpPlugin.packageNamespace; the name: field is separate and uses the @automattic/... form
import … from '@next-woo-analytics/datetime'	… from '@jetpack-premium-analytics/datetime'	Consume the already-integrated datetime package via its monorepo specifier
import type { FilterCondition } from '@next-woo-analytics/data' (self-import)	relative ../../types/filter-condition	A package should not import itself by name
import { useExperiments } from '@automattic/admin-toolkit' (gates devtools)	process.env.NODE_ENV !== 'production'	Drops the admin-toolkit dependency; devtools stay lazy + Suspense-gated, rendered in dev builds only (no experiments system exists here)
"wpModule": true	dropped (for now)	See "What's intentionally not here" below — the @wordpress/build equivalent is wpScriptModuleExports, deferred to the first-consumer PR
@tanstack/react-router in dependencies	dropped	Declared upstream but imported nowhere
* version specs	pinned (@tanstack/react-query 5.90.8, @wordpress/api-fetch 7.46.0, @wordpress/url 4.46.0, @wordpress/core-data 7.46.0, @tanstack/react-query-devtools 5.90.2)	Jetpack convention; versions match siblings (my-jetpack etc.)
'woocommerce-analytics' text domain	'jetpack-premium-analytics'	Matches the package's text domain
Leaf tsconfig.json	(deleted)	Parent already includes: [packages/**/*] and supplies the @jetpack-premium-analytics/* path alias; mirrors packages/datetime/
Upstream prettier/import-order style	re-run through Jetpack ESLint + prettier	Aligns the port with monorepo formatting

Parent-level wiring (projects/packages/premium-analytics/):

• package.json: adds the real deps (@tanstack/react-query, @wordpress/api-fetch, @wordpress/core-data, @wordpress/url; date-fns/@date-fns/tz/@wordpress/data/@wordpress/i18n already present) plus @tanstack/react-query-devtools (dev). The leaf isn't a pnpm workspace member (the root glob doesn't reach two levels in), so the parent's deps are the load-bearing ones. No link: dependency is added yet — nothing imports data (same as datetime); the first consumer will add it.
• eslint.config.mjs (temporary): a packages/data/**-only block softens the JSDoc rules to land the port with upstream's JSDoc style, keeps upstream's intentional as any generic-TData escapes, and silences the react extraneous-dependency false positive. The existing packages/datetime/** block from feat(premium-analytics): port datetime package from next-woocommerce-analytics #49221 is untouched.
• Test setup: tests/jest.config.cjs (extends jetpack-js-tools/jest/config.base.js, maps @jetpack-premium-analytics/* to source), a babel.config.cjs (Jetpack webpack babel preset, for the test transform), a test script, and @types/jest/jest/@automattic/jetpack-webpack-config dev deps — so the ported tests run and the test globals typecheck.

What's intentionally not here

• No wpScriptModuleExports yet — upstream's "wpModule": true (build data as a standalone WP script module shared across routes) maps to wpScriptModuleExports in this repo's @wordpress/build. Adding it today breaks pnpm build: bundling the module hits the @jetpack-premium-analytics/datetime imports, and the externals plugin resolves them with plain Node resolution, which can't see the tsconfig-only alias (the leaf packages aren't pnpm workspace members). Verified working locally with the alias made resolvable, so it's deferred to the first-consumer PR together with the link: wiring below.
• No @automattic/admin-toolkit / experiments dependency — replaced by the dev-builds-only devtools gate described above.
• No @tanstack/react-router — unused upstream.
• No link: dependency on the parent — data isn't imported anywhere yet, so wiring it into the build is deferred to the first consumer (mirrors datetime). This also avoids the eslint-plugin-package-json link: conflict feat(premium-analytics): port datetime package from next-woocommerce-analytics #49221 flagged.
• No JSDoc backfill — the relevant jsdoc/* rules are disabled for packages/data/** only; writing real docs is deferred and tracked by the temporary eslint.config.mjs comments.

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

No.

Testing instructions

Requires Node 24 (repo engineStrict).

pnpm install
cd projects/packages/premium-analytics
pnpm typecheck     # tsgo --noEmit — 0 errors
pnpm build         # wp-build — passes
pnpm exec eslint . # clean
pnpm test          # 7 suites, 101 tests — all pass (4 data suites + existing formatters suites)

Optional — build data as a WP script module (confirms the upstream wpModule: true behavior carries over once the alias resolves):

1. Add to projects/packages/premium-analytics/packages/data/package.json: "module": "build-module/index.mjs" and "wpScriptModuleExports": "./build-module/index.mjs".
2. Make the alias resolvable, e.g. mkdir -p node_modules/@jetpack-premium-analytics && ln -s ../../packages/datetime node_modules/@jetpack-premium-analytics/datetime (from the package root).
3. pnpm build → emits build/modules/data/ and registers @jetpack-premium-analytics/data in build/modules/registry.php.
4. Revert the edits and remove the symlink.

Note: the @jetpack-premium-analytics/* specifiers (this package's own, and the @jetpack-premium-analytics/datetime it imports) are a temporary bridge inherited from the source repo. Once name-based identity (WordPress/gutenberg#78822, mirrored monorepo-wide by #48089) lands, each specifier becomes the package's own name (@automattic/jetpack-premium-analytics-*) and the bare-scope alias/link: drop out — so long term there's no @jetpack-premium-analytics/... to maintain. The package README keeps the canonical @automattic/jetpack-premium-analytics-data name as its title, while its import examples use the @jetpack-premium-analytics/data specifier — the one that actually resolves today.

[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 wooa7s-1316-integrate-data-package-into-analytics branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack wooa7s-1316-integrate-data-package-into-analytics

bin/jetpack-downloader test jetpack-mu-wpcom-plugin wooa7s-1316-integrate-data-package-into-analytics

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

[dognose24]

Reviewed as a package port — the bulk is the verbatim-copy commit, so I focused on the adaptations (import renames, the devtools-gate change, parent wiring) plus a spot-check of the copied source.

LGTM — clean, well-isolated port, and the commit-by-commit split + adaptation table made it easy to review. No blockers. Approving.

I left a handful of non-blocking suggestions. Most are latent issues carried verbatim from upstream that won't execute until the package is actually consumed (nothing imports it yet):

• ensureCoreSettingsReady() memoizes rejections → one transient failure can wedge all subsequent route loads. This is the one I'd most encourage fixing here, or tracking for the first-consumer PR.
• formatGmtOffset() treats gmt_offset === 0 (UTC) as unset → falls back to the viewer's browser timezone.
• getProductImagesQueryKey sorts the caller's array in place during render.

And two attributable to the adaptation itself (both minor, currently moot since the package isn't bundled yet):

• the dev-only devtools gate still lazy-imports the /production build, leaving an unreachable chunk in prod bundles;
• the packages/data/** ESLint block disables no-explicit-any / import/no-extraneous-dependencies more broadly than needed.

Nothing here needs to block the port. Thanks for the unusually thorough PR description!

[dognose24]

[suggestion] ! offset is also truthy for 0, so a site explicitly configured to UTC (empty timezone_string, gmt_offset === 0) falls through to DEFAULT_TIME_ZONE (the viewer's browser timezone) instead of +00:00. This affects both getSiteTimezone() and getSiteGmtOffset(). Prefer an explicit nullish check:

if ( offset == null ) {
	return DEFAULT_TIME_ZONE;
}

Upstream-carried; low frequency but produces shifted date ranges for UTC stores. Non-blocking.

[chihsuan]

Thanks for the review! @dognose24

The UTC gmt_offset guard and the ESLint scoping I'll carry on the first-consumer follow-up.

[kangzj]

Reviewed the migration/adaptation layer only (not the verbatim copy in cf0cc34). The port is clean — specifier rename and text-domain switch are complete and consistent, no leftover next-woo-analytics/admin-toolkit/react-router references, and the devtools decoupling is correct (gating lazy() on NODE_ENV drops the chunk from prod builds entirely). Two non-blocking suggestions inline.

[kangzj]

[suggestion] Leaf↔parent WordPress version drift. These pin @wordpress/api-fetch/core-data/data/url at 7.46.0/10.46.0/4.46.0, but the parent package.json (after the trunk rebase) resolves all of them at 7.48.0/10.48.0/4.48.0.

Harmless today since this leaf isn't a pnpm workspace member — the parent's deps are the load-bearing ones, as the PR notes. But it's misleading, and it becomes a real conflict the moment the first-consumer PR wires the leaf in with link:. Worth aligning these pins to the parent's .48 versions now.

[chihsuan]

Good catch! Addressed in 6ef580e

[kangzj]

[suggestion] Disabling import/no-extraneous-dependencies for the whole packages/data/** block silences more than the react false-positive the comment describes — it also masks any genuinely undeclared dependency in the ported code. Since this override is already documented as temporary, consider narrowing it (scope the off-rule to the specific files that trip the false-positive, or leave a TODO to re-enable once the leaf manifest becomes load-bearing) so a real missing dep can't slip through unnoticed.

[chihsuan]

Added a TODO to re-enable. Full narrowing stays with the JSDoc/leaf-deps follow-up.

[kangzj]

Approving — the migration is clean and the two inline notes are non-blocking suggestions that can be addressed in this PR or a follow-up. Scoped my review to the adaptation layer (specifier rename, text-domain switch, devtools decoupling, parent wiring); the verbatim copy was not re-reviewed.