Tracking Issue: Script Modules API

[luisherranz]

• Part of Start using JavaScript Modules and Import Maps #36716.

The goal of this initiative is to implement the necessary low-level primitives to add native support in WordPress for registering and enqueueing JavaScript modules, including generating an import map. This will allow developers to leverage the native JavaScript modules system available in modern browsers.

Tasks

• Basic version of the Modules API
  • Trac: https://core.trac.wordpress.org/ticket/56313
  • PR: Script Modules API wordpress-develop#5818
• Renaming from Modules API to Script Modules API
  • Trac: https://core.trac.wordpress.org/ticket/56313
  • PR: Script Modules API: Rename wp_module functions to wp_script_module wordpress-develop#5869
• Print the import map and enqueued modules in the footer in classic themes
  • Trac: https://core.trac.wordpress.org/ticket/60240
  • PR: Script Modules API: Move the script modules to the footer in classic themes wordpress-develop#5931
• Update the code in Gutenberg and move it to the compat/wordpress-6.5 folder
  • PR: Script Modules API: update the code and move it to the compat/wordpress-6.5 folder #57778
• Add import map polyfill
  • Trac: https://core.trac.wordpress.org/ticket/60348
  • PR: Script Modules API: Backport - Add import map polyfill wordpress-develop#5947
• Figure out how to overwrite the script modules registered by WordPress Core in the Gutenberg plugin
  • Trac: https://core.trac.wordpress.org/ticket/60463
  • PR: Script Modules API: Add deregister module function wordpress-develop#6061

[luisherranz]

First experiment: implement the simplest system possible

I've opened a PR with the first experiment:

• Experiment: A simple Modules API with no server dependency graph #56092

This is the simplest system possible, delegating dependencies completely to the client.

• An API to register modules using:
  • A module identifier (required)
  • The full URL or the path (required)
  • Whether the module is for the admin, the frontend or both (required)
  • A version (optional)

Feel free to review or add any comments.

[luisherranz]

Second experiment: add the possibility to preload static dependencies of enqueued modules

I've opened a PR with the second experiment:

• Experiment: A Modules API with optional static server dependency graph #56118

This is a slightly more complex system that includes an optional graph of static dependencies to be able to avoid the initial waterfalls:

• An API to register modules using a module identifier, a version, a path and whether the module is for the admin, the frontend, or both.
• An API to enqueue modules.
• An optional server graph of static dependencies.
• All registered modules add an entry in the import map.
• Enqueued modules add a <script> tag in the head.
• Static dependencies of enqueued modules add a <link rel="modulepreload"> in the head.

Feel free to review or add any comments.

[westonruter]

There are also various comments about modules on Core-12009, the work to implement script loading strategies.

[luisherranz]

Thanks, Weston. I'll take a look 🙂

[thomas-price]

For reference, some earlier tickets:

• https://core.trac.wordpress.org/ticket/56313
• https://core.trac.wordpress.org/ticket/40834

[luisherranz]

Thanks, Thomas 🙂

---

Third experiment: use a server dependency graph to know which modules are used in the page

I've opened a PR with the third experiment:

• Interactivity API: Use modules instead of scripts in the frontend #56143

This is a more complex system than the first ones, including a required array of both the static and dynamic dependencies to be able to populate the import map only with the necessary entries:

• An API to register modules using:
  • A module identifier (required)
  • The full URL or the path (required)
  • The static and dynamic dependencies (required)
  • A version (optional)
• An API to enqueue modules.
• Only the dependent modules add an entry in the import map.
• Enqueued modules add a <script> tag in the head.
• The static dependencies are preloaded when the module is enqueued using a <link rel="modulepreload"> tag in the head.

Feel free to review or add any comments.

[youknowriad]

@luisherranz to be honest, all of the experiences are decent. I do think at the minimum we should have the "preload" deps. So I'm thinking we should go either with 2 or 3 but I suspect that the decision is going to be hard and not really objective. So how do you think should we go about this? Is there a world where we can land one, explore it in Gutenberg plugin for some weeks/months before committing entirely.

I also think that it would be good to explore automating the "deps" extraction in a follow-up and in the Gutenberg plugin automate all the gutenberg_register_module calls.

[luisherranz]

So I'm thinking we should go either with 2 or 3 but I suspect that the decision is going to be hard and not really objective

Yeah, I also think 2 or 3 are the best options, as I think there should be an easy way to avoid the initial waterfalls.

I also think that it would be good to explore automating the "deps" extraction in a follow-up and in the Gutenberg plugin automate all the gutenberg_register_module calls.

Yes, that's one of the next things I want to explore: how easy it is to extract the dependencies to some sort of manifest (or autogenerated PHP file similar to the one we have for scripts), and make Gutenberg consume it automatically.

Do you have any suggestions on how to approach this? I was thinking about experimenting with a viewModule property in the block.json file.

Is there a world where we can land one, explore it in Gutenberg plugin for some weeks/months before committing entirely.

Absolutely. I think we can easily land this for the frontend (Interactivity API), and once it's in trunk, try to use it in the Block Lazy Loading experiments as well. I'll prepare everything and test the polyfill.

[youknowriad]

Do you have any suggestions on how to approach this? I was thinking about experimenting with a viewModule property in the block.json file.

I think it should be independent of blocks entirely, it should just be a Webpack plugin like the existing dependency extraction one.