Premium Analytics: add the fields package for widget DataForm controls

[nerrad]

This is part of the analytics updates work that is happening

Proposed changes

Note

This internal package should become irrelevant in follow-ups by moving towards native (if/when updated) Data Form fields. However, this initial implementation exists to unblock current work on porting the existing WooCommerce Analytics work over to the new analytics dasboard.

Adds the internal packages/fields package: custom DataForm field controls for dashboard widgets, starting with ReportParamsField — the date-range/comparison editor (full DateFiltersPanel date picker), moved from the widgets-toolkit port.

Why a separate script-module package: widget metadata modules (widget.ts) declare attribute editors as dataviews Edit components, but wp-build's widget metadata pipeline has no style plugins — a styled editor's .module.scss graph cannot be bundled there (No loader is configured for ".scss" files). This package declares wpScriptModuleExports, so:

1. Phase-1 transpile compiles its sources (and CSS modules, via the style runtime) into scss-free build-module/ output;
2. Phase-2 builds that into a registered script module;
3. a widget's widget.ts import of @jetpack-premium-analytics/fields is externalized — the metadata bundle carries only a module dependency, resolved at runtime through the page import map.

One shared copy of the controls serves every widget on the page, instead of each metadata module bundling its own editor.

Also completes the parent-manifest link: entries (data, routing, fields) that the fields module's bundle resolves through (#49189 mechanism), and extends the existing ui-package lint override to packages/fields (same upstream code style).

The widgets-toolkit copy of the field stays for now; it gets deleted when the toolkit dissolves and widgets consume this package instead.

Stacked on the ui script-module PR (base of this PR) — the field's DateFiltersPanel import externalizes to the ui module.

Related product discussion/links

• Stacked on the ui script-module PR; first consumer is the average-items-per-order widget (Premium Analytics: port the Average items per order widget #49505), which gains its Range attribute editor in a follow-up commit there once this lands.
• Verified end to end (editor renders in the dashboard settings drawer, range changes refetch the report) on the experimental branch try/wooa7s-1460-widget-inline-report-params-field.

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

No.

Testing instructions

• pnpm --filter @automattic/jetpack-premium-analytics build — Phase 2 reports ✔ Bundled fields and ✔ Bundled ui; build/modules/fields/index.min.asset.php lists @jetpack-premium-analytics/ui as a static module dependency.
• pnpm --filter @automattic/jetpack-premium-analytics typecheck and eslint on packages/fields/** — clean.
• For the full runtime flow (widget metadata externalizing the field, editor in the settings drawer), see the experimental branch above — the consumer wiring intentionally isn't part of this PR.

[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!

[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 add/pa-fields-package branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack add/pa-fields-package

bin/jetpack-downloader test jetpack-mu-wpcom-plugin add/pa-fields-package

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

[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]

Looks good — clean packaging move 🚢

[nerrad]

closing and reopening because CI checks seem stalled.