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