Script Modules API: Allow list of enqueued module data to be exposed

[johnbillion]

There's no means for a plugin to fetch a list of registered or enqueued script modules for debugging purposes from the Script Modules API as there is from the existing Scripts Dependencies API.

Most likely the get_import_map(), get_marked_for_enqueue(), get_dependencies(), and get_versioned_src() methods of the WP_Script_Modules should be made public to facilitate this.

[swissspidy]

Are we comfortable with making all of these public and maintaining backward compatibility going forward?

Now would be the last chance to change anything about the function signature etc.

[swissspidy]

cc @luisherranz @westonruter

[luisherranz]

I think it's too soon to expose the internals.

I'd rather expose another function that only returns the list of enqueued/registered module identifiers.

[johnbillion]

I don't think this can really be considered "internals". The public print_import_map() method mostly just prints a JSON encoded representation of the data from the get_import_map() method which in turn constructs its data from the methods that I'm proposing should be public.

In order for my Query Monitor debugging plugin to show info about script modules in the same way that it does for enqueued scripts and styles, it needs to be able to fetch a list of enqueued modules (get_marked_for_enqueue()), their dependencies (get_dependencies()), and the full source URL (get_versioned_src()).

[luisherranz]

get_marked_for_enqueue and get_dependencies return a list of script module arrays, not a list of script module identifiers (strings). Those script module arrays are the arrays stored in $registered, and contain all the internal information about a script module.

So instead of making the $registered arrays public, which would mean they can't be refactored in the future, I would expose functions that return the script module identifiers (strings) only. If you need more information than that, like the corresponding src or dependencies of a script module identifier, I would create additional public functions that return a single piece of information (the src, the list of dependencies, etc).

That's just my opinion, though.

[swissspidy]

Tough one! I understand both sides, though I am probably leaning towards creating dedicated methods for this as suggested by Luis. This would be cleaner and wouldn't put us into a bad spot regarding BC. That would be an enhancement for early 6.6 though in my eyes, given how late in the release cycle we are. It's not ideal for plugins such as Query Monitor, but there might be workarounds.

What do you think?

[johnbillion]

Alrighty let's bump this. I should be able to work around this via the magic of the reflection API for now.

[oglekler]

No movement in 3 months, I am moving this ticket to the 6.7 milestone

[chaion07]

Thanks @johnbillion for reporting this. We discussed this Ticket during a recent bug-scrub session. Based on the feedback received we are updating the milestone to Future Release and if anyone is willing to contribute then they can simply update the milestone back to 6.7 🙏

Props to @mukesh27

Cheers!

[gziolo]

This came up as in issue again when working on enhancements in the Gutenberg plugin:

​https://github.com/WordPress/gutenberg/pull/65380/files#r1761621029

Re-sharing my feedback:

It's about time to take action in WordPress core and expose the missing functionality for extenders:

• get_import_map should become public, it contains imports field only, so it can get extended but it's enough for now as it's exactly the same shape that gets printed in HTML.
• add public method is_marked_for_enqueue to verify if a script tag will get printed in HTML
• add public method is_marked_for_import to verify if a script module will be listed in the import map

Bonus points for adding a filter that gets called before returning the value from get_import_map call so plugins could apply their changes.

I guess it also makes sense to promote get_marked_for_enqueue to public to have the same level of access for both concepts.

[jonsurrell]

The use case I've wanted most often is a method to know what Script Modules are "available" - either enqueued themselves or part of the import map because they're in the dependency graph.

In ​https://github.com/WordPress/gutenberg/pull/65380, the use case was "is this specific Script Module available?"

Previously, ​I needed a way to iterate through all available Script Modules. That implementation moved to Core in [58579] and was able to access private methods to achieve its goal.

[justlevine]

Another use case:

I'm working to add Block Theme support for WPGraphQL, for which we need to be able to return the array of enqueued script modules so a headless frontend can generate and output the corresponding <script> tags (alongside the traditional $wp_scripts).

Similar use case to John's Query Monitor, except this is for frontend rendering, not an admin tool, so we ideally want to avoid the reflection penalty.

Trac ticket: https://core.trac.wordpress.org/ticket/60597

[westonruter]

Also discussed in #61734 starting at this comment.

Note that WP_Script_Moules::get_marked_for_enqueue() now has a public method available as of 6.9 in r60951 for #63676: WP_Script_Modiles::get_queue().

[westonruter]

In 61073:

Script Loader: Restore original return value for WP_Script_Modules::get_dependencies().

Even though this method is private, there are some usages of it in the ecosystem via the Reflection API. So this reverts the script module IDs string[] return value in favor of the original array<string, array> return value. This re-emphasizes the need for more public accessor methods being tracked in #60597.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10403

Follow-up to [60999].

Props pbiron, westonruter, johnbillion.
See #63486, #60597.

[westonruter]

In 62278:

I18N: Add translation support for script modules.

Add automatic translation loading for script modules (ES modules), so strings using __() and friends from @wordpress/i18n can be translated at runtime. This brings classic script i18n parity to script modules registered via wp_register_script_module(), which previously had no way to load translation data, leaving strings untranslated on screens like Connectors and Fonts that are built as script modules.

At the admin_print_footer_scripts and wp_footer actions, every enqueued script module and its dependencies are walked, the translation chunk is loaded for each, and an inline <script> calls wp.i18n.setLocaleData() so translations are available before deferred modules execute. Note there is currently a runtime dependency on the wp-i18n classic script, which is printed just-in-time if not already enqueued. This coupling is to be removed in a future release.

Public API:

• WP_Script_Modules::set_translations() stores the text domain (and optional path) per registered module to override the text domain and path. A global wp_set_script_module_translations() function is added as a wrapper around wp_script_modules()->set_translations().
• WP_Script_Modules::get_registered() obtains a registered module's data. See #60597.
• WP_Script_Modules::print_script_module_translations() emits inline wp.i18n.setLocaleData() calls after classic scripts load but before modules execute.
• load_script_module_textdomain() loads the translation data for a given script module ID and text domain.
• The existing load_script_textdomain_relative_path filter gains a third $is_module parameter so callers can distinguish classic-script and script-module lookups when resolving translation paths.

PHPStan types are also added in WP_Script_Modules. See #64238.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/11543

Props manzoorwanijk, westonruter, jsnajdr, jonsurrell, mukesh27, peterwilsoncc, 369work, desrosj, sabernhardt, nilambar, jorgefilipecosta, malayladu.
See #64238, #60597.
Fixes #65015.

[peterwilsoncc]

In 62286:

I18N: Add translation support for script modules.

Add automatic translation loading for script modules (ES modules), so strings using __() and friends from @wordpress/i18n can be translated at runtime. This brings classic script i18n parity to script modules registered via wp_register_script_module(), which previously had no way to load translation data, leaving strings untranslated on screens like Connectors and Fonts that are built as script modules.

At the admin_print_footer_scripts and wp_footer actions, every enqueued script module and its dependencies are walked, the translation chunk is loaded for each, and an inline <script> calls wp.i18n.setLocaleData() so translations are available before deferred modules execute. Note there is currently a runtime dependency on the wp-i18n classic script, which is printed just-in-time if not already enqueued. This coupling is to be removed in a future release.

Public API:

• WP_Script_Modules::set_translations() stores the text domain (and optional path) per registered module to override the text domain and path. A global wp_set_script_module_translations() function is added as a wrapper around wp_script_modules()->set_translations().
• WP_Script_Modules::get_registered() obtains a registered module's data. See #60597.
• WP_Script_Modules::print_script_module_translations() emits inline wp.i18n.setLocaleData() calls after classic scripts load but before modules execute.
• load_script_module_textdomain() loads the translation data for a given script module ID and text domain.
• The existing load_script_textdomain_relative_path filter gains a third $is_module parameter so callers can distinguish classic-script and script-module lookups when resolving translation paths.

PHPStan types are also added in WP_Script_Modules. See #64238.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/11543

Reviewed by audrasjb.
Merges r62278 to the 7.0 branch.

Props manzoorwanijk, westonruter, jsnajdr, jonsurrell, mukesh27, peterwilsoncc, 369work, desrosj, sabernhardt, nilambar, jorgefilipecosta, malayladu.
See #64238, #60597.
Fixes #65015.

[wildworks]

I would like to check the status of this ticket. Is there anything else we need to address? If not, I would like to close this ticket.

[westonruter]

Additional methods are needed to expose the internals. So I'm punting to the next release.

[jonsurrell]

​This comment and surrounding discussion from @jsnajdr describes more extension points that would be useful for Script Modules.