Widget Primitives: Ship as a script module

[retrofox]

What

Ships @wordpress/widget-primitives as a WordPress script module (wpScriptModuleExports).

Why

The package holds module-scope state: the field type registry is a Map in the module. Bundled, the package produces one copy per consumer bundle, so state registered against one copy is invisible to every other, and the package is duplicated across consumers.

As a script module it resolves one shared, singly-evaluated instance from the import map. Consumers externalize the package instead of bundling their own copy. The dedup and the single-instance guarantee compound as more consumers appear (route bundles, and independently built widget render modules).

How

• packages/widget-primitives/package.json: add wpScriptModuleExports, so wp-build emits build/modules/widget-primitives/ and consumers externalize the package to the import map instead of bundling it.

Testing

1. Build (npm run build) and confirm build/modules/widget-primitives/ exists and is registered in build/modules.php.
2. Confirm a module consumer (e.g. the dashboard route asset, build/routes/dashboard/content.min.asset.php) lists @wordpress/widget-primitives as a module dependency instead of bundling it.

Follow-ups

• Move the dashboard's field type registration into the page init module without inflating it. The location control it registers pulls in the @wordpress/ui autocomplete stack, which isn't a script module yet, so it inlines into the init module (on the critical path). Fix by externalizing @wordpress/ui as a shared module, or by loading the control as a separate script module (the @wordpress/latex-to-mathml pattern). Tracked in #TBD.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: retrofox <retrofox@git.wordpress.org>
Co-authored-by: chihsuan <chihsuan@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: +1.15 kB (+0.01%)

Total Size: 7.73 MB

📦 View Changed

Filename	Size	Change
build/modules/widget-primitives/index.min.js	1.15 kB	+1.15 kB (new file)	🆕

_{compressed-size-action}

[github-actions]

Flaky tests detected in 3b51525.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29519291761
📝 Reported issues:

• [Flaky Test] inserts synced patterns by dragging and dropping from the global inserter #61291 in /test/e2e/specs/editor/various/inserting-blocks.spec.js

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[chihsuan]

Thanks @retrofox shipping @wordpress/widget-primitives as a script module makes sense to me!

I just have one concern:

build/modules/dashboard-init/index.min.js 81.6 kB +81 kB (+13641.92%) 🆘

The compressed-size report shows the init module growing by roughly 81 kB, and it must finish loading before the dashboard can render.

The dashboard route also continues to use much of the same UI stack through widget-dashboard, so some of that code is duplicated.

Would it be possible to consider one of these alternatives?

1. Keeping registration in the route. This is simpler and avoids the extra init bundle, but registration remains route-specific and tied to module evaluation.
2. Keeping registration in init while lazy-loading LocationControl. This preserves centralized ownership but adds loading complexity and may not remove all duplication.

Both have tradeoffs, so I’d also be interested in any other approach you have. 🙂

One small documentation follow-up: docs/explanations/architecture/dashboard-widgets.md still says the dashboard route registers its field types, so that description should be updated if the current approach remains.

[retrofox]

Thanks, @chihsuan. You were right to flag the init module.

I first went down the lazy-loading path, but the weight comes from @wordpress/ui, and since it isn't a script module yet, it inlines into whatever bundle imports the control.

The init module stayed heavy either way. Moving registration into init only pays off if that code can be deferred, and right now it can't.

So I go back to registration, staying on the route where the UI stack is already bundled, so there's no extra init module. This PR is now just the wpScriptModuleExports change for @wordpress/widget-primitives.

The good thing is that since registration is back in the route, the dashboard-widgets.md note is accurate again 😅

[chihsuan]

Thanks for digging into it! @retrofox Totally agree on staying on the route for now. LGTM 👍