Build: detect version and generate asset.php for vendor scripts#76811
Build: detect version and generate asset.php for vendor scripts#76811
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. |
|
Because the PR modifies |
|
Size Change: 0 B Total Size: 7.69 MB ℹ️ View Unchanged
|
|
Flaky tests detected in 399e9ac. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23608562684
|
|
🍺 Thank you for prepping this PR!!
I'm happy to help massage it through, but I'm not 100% sure of the backport, and wondering if this is a plugin-only change 🤔 I'm assuming it need to be somewhere in https://github.com/WordPress/wordpress-develop/blame/trunk/src/wp-includes/script-loader.php#L85 |
Yes, to me this looks like a plugin-only change as the function only seems to be used for the plugin. I imagine we'd want to do a backport if we want the same I think it'd be valid to go with this PR without proposing the core change just yet. If so, we could add the |
Yes, the backport will be something that doesn't share any code with this Gutenberg PR, but will implement the equivalent changes in Core. The Some related patches from fairly recent past: Turns out this is not the first time we see the |
5426f71 to
7aa0cca
Compare
|
The backport problem is solved, I created WordPress/wordpress-develop#11359 to backport the changes in this PR. The code is completely different, but the end goal is the same. |
| @@ -0,0 +1,3 @@ | |||
| https://github.com/WordPress/wordpress-develop/pull/11359 | |||
There was a problem hiding this comment.
Is this mean as 7.0 backport or 7.1 (I guess that depends on whether the change of the UMD builds happened on 7.0 or not)
There was a problem hiding this comment.
In the https://core.trac.wordpress.org/ticket/64958 discussion we settled that it's for 7.1. I moved the changelog entry to the right directory.
…Press#76811) * Build: detect version and generate asset.php for vendor scripts * Add backport changelog entry * Move changelog entry from 7.0 to 7.1 Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
…) (#76900) * Build: detect version and generate asset.php for vendor scripts * Add backport changelog entry * Move changelog entry from 7.0 to 7.1 Co-authored-by: Jarda Snajdr <jsnajdr@gmail.com> Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Alternative for #76798: when building vendor scripts (ie., React), detect the real version from
package.jsonand generate an.asset.phpfor each script. This asset file is the place where the version and the dependencies are specified.Then we modify the
gutenberg_register_vendor_scriptsfunction to use the.asset.phpinfo when registering the scripts, instead of hardcoded values.Claude noticed a nice detail about registering the
wp-react-refresh-entrydependency: that it's already added in Core bywp_register_development_scriptsand that we merely need to preserve it.After this patch,
reactandreact-domscripts are loaded with?ver=18.3.1query param, and you're invited to verify that it's true. We can discuss using a content hash instead of18.3.1, it would be a simple change.