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