@sirreal Thoughts on this? Because a full URL to a module is supplied, the codemirror script indeed no longer has any dependency on the import map and it can freely be printed in the head before the importmap script.

In the future, when we support multiple importmap scripts, we could return to using module_dependencies and importing espree.

One note here:

Because a full URL to a module is supplied, the codemirror script indeed no longer has any dependency on the import map and it can freely be printed in the head before the importmap script.

Before multiple importmaps (unsupported as of current Firefox 150), any module loading or preloading would invalidate subsequent importmaps. Firefox will print a warning and refuse to load an importmap. It's not sufficient to not use an imports, the act of loading (or preloading) a module triggers this behavior.

I don't think this is likely to be a problem in practice on the plugin pages, but we could defer and move them to the footer. This would also resolve the "practice what we preach" concern above. If the editor won't be initialized until DOMContentLoaded anyways, it doesn't seem like a big change.

Here's a demo:

• Firefox rejects the importmap here after any module loads.
• Firefox respects importmap if it appears before any other module or preload.

Before multiple importmaps (unsupported as of current Firefox 150), any module loading or preloading would invalidate subsequent importmaps. Firefox will print a warning and refuse to load an importmap. It's not sufficient to not use an imports, the act of loading (or preloading) a module triggers this behavior.

Alas, you're right. I was testing with Chrome which allows this:

<script type="module">
import { parse } from '/wp-includes/js/codemirror/espree.min.js';
// import { parse } from 'espree';
console.log( 'Parsed:', parse( 'document.write("Hello World!");' ) );
</script>

<script type="importmap">
{"imports":{
	"@wordpress/a11y": "/wp-content/plugins/gutenberg/build/modules/a11y/index.js?ver=1c371cb517a97cdbcb9f",
	"espree": "/wp-includes/js/codemirror/espree.min.js"
}}
</script>

<script type="module">
import { speak } from '@wordpress/a11y';
speak( 'Hello world!' );
console.log( 'World greeted!' );
</script>

If I swap the imports to be like this, however:

// import { parse } from '/wp-includes/js/codemirror/espree.min.js';
import { parse } from 'espree';

Then Chrome errors:

Uncaught TypeError: Failed to resolve module specifier "espree". Relative references must start with either "/", "./", or "../".

In Firefox, there is always this failure:

Uncaught TypeError: The specifier “@wordpress/a11y” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.

The error appearing in Chrome also appears in Firefox if I try importing espree before the importmap is seen.

When looking at the PHPStan analysis, this inconsistency with the fetchpriority and ! $this->registered[ $handle ]->src conditions and popped out at me. This was originally introduced in 613b0e7.

See above: https://github.com/WordPress/wordpress-develop/pull/11788/changes#r3238300276

These are the only two functions which use this internal function. Again, something which would have been helpful to add when it was introduced in 6357346.

This function is introduced in 7.0 but it lacks full PHPStan typing. This is a follow-up to 6357346.

I've simplified the types here to avoid the excessive indentation. This is a follow-up to 6357346 which is for 7.0.

I've provided the full PHPStan types below, whereas they were previously incomplete by not specifying the array keys above (and so not very helpful).

Ditto above: https://github.com/WordPress/wordpress-develop/pull/11788/changes#r3238309052

Technically this could be string[], as $handle could be ? or ?foo=bar or ?????????????. But in practice, and the intended usage (which has test coverage) is for the handle to optionally have query string args added after it (which is extremely unusual anyway). In the future we can add some assertions to validate that $_handle[0] is actually a non-empty string.

For that matter, the $handle should actually use strtok() to obtain the value:

$_handle = strtok( $handle, '?' );