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
5640b43a30	feat(premium-analytics): copy data package from next-woocommerce-analytics
f4f0628941	refactor(premium-analytics): adapt data package imports and manifest for monorepo
8510450d21	refactor(premium-analytics): decouple data package from admin-toolkit experiments
cacb76f756	style(premium-analytics): align ported data package with jetpack lint and prettier
b8a36689ac	chore(premium-analytics): wire data package deps and test setup
8ec819e4c1	changelog: add entry for premium-analytics data port

What's in the package

Path	Purpose
src/api/**	REST fetchers for each report (orders, products, customers, coupons, visitors, sessions, conversion rate, bookings, order attribution, export) plus endpoint constants
src/queries/**	React Query queryKey/queryFn definitions per report
src/hooks/**	useReport* hooks (and useProductImages) wrapping the queries
src/processing/**	Response normalization/sanitization and chart-data shaping per report
src/providers/**	AnalyticsQueryClientProvider, QueryClient config, and global error context/manager
src/prefetch/**	prefetchReport for warming the cache
src/utils/**	Report-param normalization, date/interval helpers (thin wrappers over datetime), parsing, product filters, search
src/defaults/**, src/types/**, src/types.ts	Default presets/query params and shared types

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)	local areQueryDevtoolsEnabled() flag	Drops the admin-toolkit dependency; devtools stay lazy + Suspense-gated, now opt-in (OFF by default; enable via window.jetpackPremiumAnalyticsQueryDevtools = true, or automatically outside production)
@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): extends the existing datetime JSDoc softening to packages/data/**, and adds a small data-only block (keeps upstream's intentional as any generic-TData escapes and silences the react extraneous-dependency false positive).
• 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 4 ported tests run and the test globals typecheck.

What's intentionally not here

• No @automattic/admin-toolkit / experiments dependency — replaced by the local devtools flag 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 / formatting cleanup of upstream patterns — out of scope for the port; 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 --flag v10_config_lookup_from_file --max-warnings=0 packages/data/   # clean
pnpm test        # 4 suites, 40 tests — all pass

Optional — build-time resolution via link: (confirms wp-build tracks the package as a module dependency once a consumer imports it):

1. Add to projects/packages/premium-analytics/package.json dependencies: "@jetpack-premium-analytics/data": "link:packages/data" (add "@jetpack-premium-analytics/datetime": "link:packages/datetime" too if you want datetime resolved at build time). The valid-dependencies lint rejects link: — relax it for the temp edit.
2. Import + reference a data export in routes/dashboard/stage.tsx.
3. pnpm install && pnpm build → build/routes/dashboard/content.min.asset.php lists the dependency under module_dependencies.
4. Revert the edits + pnpm install.

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 already uses the canonical @automattic/jetpack-premium-analytics-data name.

[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

No summary data is available for parent commit c5d75bf, so cannot calculate coverage changes. 😴

If that commit is a feature branch rather than a trunk commit, this is expected. Otherwise, this should be updated once coverage for c5d75bf is available.

Full summary · PHP report · JS report