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: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org>

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

Codecov Report

❌ Patch coverage is 62.61682% with 40 lines in your changes missing coverage. Please review.
✅ Project coverage is 60.91%. Comparing base (cde564d) to head (7aa3e08).

@@              Coverage Diff              @@
##             develop     #340      +/-   ##
=============================================
+ Coverage      57.70%   60.91%   +3.20%     
+ Complexity       617      596      -21     
=============================================
  Files             46       46              
  Lines           3173     3116      -57     
=============================================
+ Hits            1831     1898      +67     
+ Misses          1342     1218     -124     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@dkotter or @justlevine, can you verify that the proposed approach to the build step is compatible as the intermediate step? It would allow converge on one approach in other PRs, namely I was thinking about this work from @Jameswlepage:

• Add AI Request Logging experiment with observability dashboard #149

Ideally we're able to show Features at the top of the page, here's some low-fi mockups of what this could look like: #234 (comment)

@dkotter or @justlevine, can you verify that the proposed approach to the build step is compatible as the intermediate step? It would allow converge on one approach in other PRs, namely I was thinking about this work from @Jameswlepage:

Changes to the build script look fine to me, assuming this question is around the changes in package.json? Seems to properly support building our current scripts and also support the new Dataviews UI. Would be great if we could use a single approach for both but no concern from me on how this currently works.

I tested this PR and here are my findings:

• npm run build and npm run build:routes — both work correctly.
• Browser testing — everything works as expected.
• npm run start — the Settings > AI menu disappears. The issue is that wp-scripts start and wp-build --watch run concurrently and share the same build/ folder. One wipes the other's output, so the generated PHP files needed for the admin menu registration get lost.

Proposed fix: Use separate build folders for each tool so they don't interfere with each other during development.

Addressed the npm run start conflict. The root cause is webpack's output.clean.keep regex only preserving fonts/ and images/, which wipes all wp-build output on every rebuild.

Regarding separate build folders — both wp-build (BUILD_DIR hard-coded in build.mjs) and Asset_Loader.php (hard-codes build/ paths) would need upstream changes, so that's not feasible right now.

Instead, extended the clean.keep regex in webpack.config.js to also preserve wp-build directories (modules, pages, routes, scripts, styles). This lets both tools coexist in build/ during watch mode — webpack still cleans its own stale output normally.

Hi @gziolo, @dkotter thank you a lot for the reviews, I think all the feedback was applied.

This is necessary until @wordpress/build adds plugin-aware boot asset resolution

would need upstream changes, so that's not feasible right now.

Yah the wp-admin part is required it is wp-build works.

@jorgefilipecosta @gziolo how future-compat is this current config?

It's one thing to be dogfooding a library to provide early feedback, but based on the lack of basic "plugin" support and these coexistence workarounds y'all had to find, how confident do you feel that our config won't require undue maintenance while the lib has a chance to stabilize?

If it is unstable, I ultimately defer to @dkotter and @jeffpaul as to whether they think it's a good idea to assume the potential tech debt, but I do want to remind folks that we're not just about to become a canonical plugin, but we're about to become the first canonical plugin that WordPress directly promotes in Core, and we don't want a breaking 0.3.0 holding up a patch or security release while we're still getting our feet wet.

I'm not sure what parts of this new build process are required for the latest dataviews lib, nor what about the new build process delayed WP7.0/how it was eventually resolved and whether it's relevant to us here, but assuming knowing both help decide whether this is a conversation worth having, or premature worry.

(Changes themselves look fine to me 🚀)

@justlevine, all fair feedback. I wasn’t aware of all the limitations of wp-build surfaced in this PR. I’m less worried about that as Gutenberg and WP core also use it, so in theory it should improve substantially over time.

@jorgefilipecosta, wp-scripts is flexible enough to output to a different folder. If I recall correctly in the past Gutenberg was using two different build folders to avoid race conditions between scripts and script modules. The solution you proposed works today but it really brittle and something unexpected can pop up in the future as soon wp-build will need its cleanup. It all really depends on how long two build systems will coexist. Therefore, I’m too worried about it, but it’s important to keep it in mind.