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

[chihsuan]

Proposed changes

Third leaf in M2 — Shared Packages Integration: port @next-woo-analytics/routing into @automattic/jetpack-premium-analytics as an internal package, stacked on the data port (#49263). Provides the routing/URL-search layer — date-range and comparison search-param encoders that write to the URL via @wordpress/route, the deriveComparisonRange helper, and the useStagedSearch hook (staged UI edits + atomic URL commits).

Routing is Layer 1 and depends on both already-integrated packages: every helper imports from @jetpack-premium-analytics/data and @jetpack-premium-analytics/datetime, so this stacks on #49263 (WOOA7S-1316), which itself stacks on the datetime port (#49221).

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
bb049fbeae	feat(premium-analytics): copy routing package from next-woocommerce-analytics
4234b7862c	refactor(premium-analytics): adapt routing package imports and manifest for monorepo
18c468ea92	style(premium-analytics): align ported routing package with jetpack lint and prettier
b302491565	chore(premium-analytics): wire routing package deps and eslint config
25e6b441a3	changelog: add entry for premium-analytics routing port

What's in the package

Path	Purpose
src/search/date-range/**	encodeDateToSearchParam, writeDateRangeToSearch, writeComparisonToSearch — serialize DateRange/comparison state to ISO(+offset) URL params via navigate()
src/search/comparison/**	deriveComparisonRange — derive compare_from/compare_to from the main range + preset, honoring the site timezone
src/hooks/use-staged-search/**	useStagedSearch — stage UI edits locally and commit them atomically to the URL (with optional debounced auto-commit); includes its usage README
src/hooks/use-date-range-search/**	upstream placeholder modules (empty), copied verbatim
src/index.ts	public exports

Monorepo adaptations

Upstream	Here	Why
name: @next-woo-analytics/routing	name: @automattic/jetpack-premium-analytics-routing	Internal-packages convention (parent README.md): the import specifier (@jetpack-premium-analytics/routing) comes from wpPlugin.packageNamespace; the name: field is separate and uses the @automattic/... form
import … from '@next-woo-analytics/data' / '…/datetime'	… from '@jetpack-premium-analytics/data' / '…/datetime'	Consume the already-integrated data + datetime packages via their monorepo specifiers
@next-woo-analytics/routing in doc examples	@jetpack-premium-analytics/routing	Examples reference the package by its monorepo specifier
@tanstack/react-router in dependencies	dropped	Declared upstream but imported nowhere
date-fns in dependencies	dropped from the leaf	Not imported by routing; @wordpress/route is the only external runtime dep and is already on the parent manifest
* version specs	pinned (@wordpress/route 0.12.0)	Jetpack convention; version matches the parent manifest
Leaf tsconfig.json	(deleted)	Parent already includes: [packages/**/*] and supplies the @jetpack-premium-analytics/* path alias; mirrors packages/datetime/ and packages/data/
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 @jetpack-premium-analytics/routing: link:packages/routing so the build resolves the package. @wordpress/route and the data/datetime links are already present from the earlier ports — nothing else to add.
• eslint.config.mjs (temporary): extends the existing JSDoc-softening glob to packages/routing/**, and adds a small routing-only block that silences the react extraneous-dependency false positive (the hook imports react directly; the internal package's deps live on the parent manifest).

What's intentionally not here

• No @tanstack/react-router — unused upstream.
• No date-fns leaf dep — not imported by routing.
• No tests — none exist upstream for this package.
• 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/routing/   # clean

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/routing": "link:packages/routing" (add link: entries for @jetpack-premium-analytics/data and @jetpack-premium-analytics/datetime too if you want its internal deps resolved at build time). The valid-dependencies lint rejects link: — relax it for the temp edit.
2. Import + reference a routing 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/data + @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 READMEs already use the canonical @automattic/jetpack-premium-analytics-* names (source imports + package.json deps keep the bare-scope bridge for now).

[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 8b2d9b4, 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 8b2d9b4 is available.

Full summary · PHP report