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

[chihsuan]

Proposed changes

Third leaf in M2 — Shared Packages Integration (WOOA7S-1317): port @next-woo-analytics/routing into @automattic/jetpack-premium-analytics as an internal package. 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 prerequisite packages, which have now landed on trunk: every helper imports from @jetpack-premium-analytics/data and @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
b3a0aa5f8c	feat(premium-analytics): copy routing package from next-woocommerce-analytics	Mechanical — byte-for-byte copy of upstream packages/routing (verified with diff -r); skim only
3b2d1ec070	refactor(premium-analytics): adapt routing package imports and manifest for monorepo	The interesting one — specifier renames, manifest rewrite, leaf tsconfig.json deletion, README name adaptation
4b1dc4e641	style(premium-analytics): apply jetpack prettier and eslint fixes to routing package	Mechanical — pure prettier --write + eslint --fix output, no manual edits mixed in; skim only
790de85a29	chore(premium-analytics): add routing lint overrides and changelog entry	Routing-scoped eslint override block + changelog

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/* in doc examples	@jetpack-premium-analytics/*	README titles use the canonical name:; import examples use the bare-scope specifier consumers actually import — same convention as the data package README
wpModule: true	dropped for now	The @wordpress/build equivalent is wpScriptModuleExports, but adding it today breaks pnpm build: the @jetpack-premium-analytics/* specifiers are tsconfig-paths-only (leaf packages aren't pnpm workspace members), so the module build can't Node-resolve them. Same call as the data port (#49263); wired up with the first consumer
@tanstack/react-router in dependencies	dropped	Declared upstream but imported nowhere in routing src
date-fns in dependencies	dropped from the leaf	Not imported by routing; @wordpress/route is the only external runtime dep
(hoisted upstream)	@wordpress/route 0.12.0 pinned on the leaf	Imported directly by routing src; pin 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: untouched. @wordpress/route 0.12.0 and react are already on the parent manifest, and — as on feat(premium-analytics): port data package from next-woocommerce-analytics #49263 — all link: wiring for the internal packages is deferred to the first consumer PR (the valid-dependencies lint rejects link: entries anyway).
• eslint.config.mjs (temporary): adds a routing-only override block (packages/routing/**) softening the JSDoc rules the upstream style trips (require-jsdoc, require-param, require-returns, check-indentation) and silencing the react extraneous-dependency false positive (the hook imports react directly; the internal package's deps live on the parent manifest). No shared glob is widened — datetime/data overrides are unchanged.

What's intentionally not here

• No parent package.json / link: changes — deferred to the first consumer PR, same as feat(premium-analytics): port data package from next-woocommerce-analytics #49263.
• No wpScriptModuleExports — see the wpModule row above.
• 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).

cd projects/packages/premium-analytics
pnpm install
pnpm typecheck       # tsgo --noEmit — 0 errors
pnpm exec eslint .   # clean
pnpm test            # existing suites pass (routing has no tests upstream)
pnpm build           # wp-build — passes

To verify the copy commit is verbatim: git diff <copy-commit> -- projects/packages/premium-analytics/packages/routing against a checkout of upstream next-woocommerce-analytics/packages/routing is empty (modulo node_modules).

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 drops out — so long term there's no @jetpack-premium-analytics/... to maintain. The package READMEs already use the canonical @automattic/jetpack-premium-analytics-* names in their titles (import examples and 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

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