Script Modules

[ajgagnon]

Hi Team!

Very excited about this project - a few things to think about for the new script modules/imports implementation.

I have implemented JavaScript modules in a few widely used plugins, so there are a couple things to note. None of these are blockers, but I thought maybe bringing them up now may help in some potential architectural decisions.

1. Script import maps need to happen first before any other <script type="module"> on the page. If a script uses type="module" on the page, and it's printed before the import map, ALL scripts using the import will fail on the page. Ideally, the import map will output on the page before any potential scripts.

2. JavaScript CDNS don't always play nice with javascript modules due to CORS issues. CORS headers need to be added, or they will get blocked. So if @wordpress/interactivity is served through a CDN, it won't work due to CORS issues. One specifically worth testing or reaching out to is bunny.net.

Thanks team!

[cbravobernal]

Hi there!

Thanks for starting the conversation. All the feedback is vital for the people that is working in this project.

Script import maps need to happen first before any other <script type="module"> on the page.

I tested with some use cases and this error appeard. For that reason, we print the import maps asap. before the modules and the preloads. If you coud test it too with more examples, that would be awesome. This file is the one that contains all the functions to register, enqueue and print a Module.

https://github.com/WordPress/gutenberg/blob/47866156b33340523ce08a5b30b35828543059ff/lib/compat/wordpress-6.5/class-wp-script-modules.php#L165-L166

public function add_hooks() {
 $position = wp_is_block_theme() ? 'wp_head' : 'wp_footer';
 add_action( $position, array( $this, 'print_import_map' ) );
 add_action( $position, array( $this, 'print_enqueued_script_modules' ) );
 add_action( $position, array( $this, 'print_script_module_preloads' ) );
}

JavaScript CDNS don't always play nice with javascript modules due to CORS issues. CORS headers need to be added, or they will get blocked....

Thanks for the feeback, will take a look at it 🚀, feel free to add an issue or PR if you want to contribute too!

[ajgagnon]

Nice! I'll run some tests and see if I can reproduce anything.

Regarding CDNs, I don't think there is anything needed on gutenberg/WP end. Perhaps I'll shoot a note over to Bunny.net and maybe they can add compatibility or at least put it on their radar.

[cbravobernal]

Should this be in all CDNs radar then? Should we talk with WordPress hosting community?

[ajgagnon]

Probably a good idea! Not sure how to go about that. I did reach out to bunny.net as I know them to be one of the CDNs with this issue specifically. I think there are probably a handful.

[ajgagnon]

In this line:

https://github.com/WordPress/gutenberg/blob/47866156b33340523ce08a5b30b35828543059ff/lib/compat/wordpress-6.5/class-wp-script-modules.php#L165-L166

I see this reason:

In classic themes, the script modules used by the blocks are not yet known
when the `wp_head` actions is fired, so it needs to print everything in the
footer.

Which makes sense - I think this is edge enough I suppose - modules have to be included in the footer for classic themes.

[cbravobernal]

That's it, printing on the head caused Interactivity to stop working in classic themes, being the lighbox feature the most noticed by hundreds of websites that reported feedback.

[luisherranz]

As a reference, a comment from @westonruter about a mechanism that could be used to optimize this in the future:

This could be a performance optimization that could be applied via Core-43258: if pages are output-buffered by default, then the import map could be moved to the head even if it is printed in the footer.

• Script Modules API: update the code and move it to the compat/wordpress-6.5 folder #57778 (comment)