WordPress script modules API can't be cache-busted, incorrect scripts are cached

[ryelle]

I unpinned and updated Gutenberg today, and ran into this error again: https://meta.trac.wordpress.org/ticket/7471 — but only on some sites.

After digging, I realized that the JS sent by the server was different on the working/broken sites, and that the broken sites had the previous version's JS cached (even at the new ?ver=17.8.2 URL). Our mid-deploy-cachebuster.php script should be handling this, but unfortunately, the new script modules API does not use the script_loader_src filter.

I tried fixing this quickly with this change — setting the version on a different filter, which did work for the <script type="module" src="… tags. But after deploying that, the issue persisted, because the interactivity/index.min.js file was not using this new cachebuster.

<script type="importmap" id="wp-importmap">
{"imports":{"@wordpress\/interactivity":"https:\/\/wordpress.org\/wp-content\/plugins\/gutenberg\/build\/interactivity\/index.min.js?ver=17.8.1"}}
</script>

We need to be able to update the version in the import map ^ somehow. This is totally unfilterable from my dive into the code. To fix the original nav issue, I ended up rolling back GB to 17.8.1 to force that version to change.

Maybe this should be a core ticket?

[dd32]

Maybe this should be a core ticket?

I agree, I've filed something upstream: https://core.trac.wordpress.org/ticket/60742

WP_Script_Modules::get_versioned_src should have a filter. It could re-use script_loader_src for max-compat.

https://github.com/WordPress/wordpress-develop/blob/45ec568f0ce905b9aabfb469b613e39d042ad3b7/src/wp-includes/class-wp-script-modules.php#L337-L348

[dd32]

Core has adopted the script_module_loader_src filter, and I've added it to our deploy cache changes.