Build: Add a step to auto-register scripts in the build tool#72628
Build: Add a step to auto-register scripts in the build tool#72628youknowriad merged 1 commit intotrunkfrom
Conversation
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: 0 B Total Size: 2.19 MB ℹ️ View Unchanged
|
|
Flaky tests detected in 338bcd5. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18755793265
|
be74555 to
338bcd5
Compare
| * @param bool $in_footer Optional. Whether to enqueue the script before </body> instead of in the <head>. | ||
| * Default 'false'. | ||
| */ | ||
| function gutenberg_override_script( $scripts, $handle, $src, $deps = array(), $ver = false, $in_footer = false ) { |
There was a problem hiding this comment.
This function is still used by gutenberg_register_vendor_scripts and now plugin throws a PHP fatal error without build step.
I think that should be avoided.
There was a problem hiding this comment.
The function is generated now though, I didn't remove it.
There was a problem hiding this comment.
throws a PHP fatal error without build step.
I guess we should avoid loading "client-assets.php" if the plugin is not built. Probably it's better to avoid loading any php.
There was a problem hiding this comment.
I don't think a build should be required for a plugin to run any PHP. It could create more confusion. Someone clones the repo and activates a plugin, but nothing happens.
What was the main reason for moving gutenberg_override_script to be generated during the build? The gutenberg_override_style is still defined in client-assets.php?
P.S. It took a while to realize why gutenberg_override_script was missing after pulling the trunk 😅
There was a problem hiding this comment.
I don't think a build should be required for a plugin to run any PHP. It could create more confusion. Someone clones the repo and activates a plugin, but nothing happens.
This was already the case, if you don't build the plugin you get a message on the admin saying your plugin should be built. I think it should just continue to work the same.
There was a problem hiding this comment.
Maybe we could check if gutenberg_override_script function exists and do the same message, plus stop loading parts of the plugin that will throw a fatal error.
There was a problem hiding this comment.
I'm still not seeing any issue though. If the build folder doesn't exist, there's no breakage and you just get the noticed. Maybe you just got in a weird state where you had a build folder but you didn't have the generated php yet. Which in theory, will never happen (unless you're switching form an old branch to a new branch).
There was a problem hiding this comment.
unless you're switching form an old branch to a new branch
Some days, I've to do that a lot 😅
…g adhoc code (WordPress#72628) Co-authored-by: youknowriad <[email protected]>
Related #72032
What
This continues the work on the build tool. This PR auto-registers scripts (like we did modules before) based on the packages built in the current plugin.
Why?
How?
build/scripts/index.php- module registry data arraybuild/scripts.php- registration logic with hooksTesting Instructions
E2E tests should pass (scripts are used everywhere)