Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Script Modules: Add method to include modules in importmap #8009

Conversation

sirreal
Copy link
Member

@sirreal sirreal commented Dec 16, 2024

This is a first step towards 61500, it adds a method to the script modules class to allow modules to be flagged for inclusion in the import map.

This means that a module can be flagged for inclusion and it will appear in the import map regardless of whether it's absent from the script module dependency graph.

This can be useful for developers to force modules to appear in the import map where they can be imported on the browser console. I expect this method to be used in the future so that classic scripts can create a dependency on script modules, where this new method will act the script dependency system to request that modules appear in the importmap.

Internally it uses an array: moduleId => null. The value is always null, but other values could be used, e.g. to request that it appear in the import map and in module preloads the value might by moduleId => true or moduleId => 'preload'. Only nullis used at this time. This would also appear as an argument to theinclude_in_import_map` method, but again that is not implemented at this time and only presented for consideration.

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


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

Copy link

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • The Plugin and Theme Directories cannot be accessed within Playground.
  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

@sirreal
Copy link
Member Author

sirreal commented Dec 16, 2024

@luisherranz I'd love your thoughts on this.

@youknowriad @swissspidy This is one of the first pieces towards allowing scripts to depend on modules, I know that you're working on functionality that would like to leverage this. I'd appreciate your thoughts.

@sirreal sirreal marked this pull request as ready for review December 16, 2024 16:21
Copy link

github-actions bot commented Dec 16, 2024

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props jonsurrell, swissspidy.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

*
* @param string $id The identifier of the script module.
*/
public function include_in_import_map( string $id ) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this method name is too specific and tied to the implementation.

Originally I had used expose() and was also considering make_available(). I'm wondering about a future where this may add some option arguments for preload, etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My first thought was add_to_import_map()

@sirreal sirreal requested a review from swissspidy December 17, 2024 09:02
@sirreal sirreal marked this pull request as draft December 17, 2024 09:05
@sirreal sirreal marked this pull request as ready for review December 17, 2024 09:27
@sirreal
Copy link
Member Author

sirreal commented Dec 17, 2024

I added a test and fixed an issues where regular dependencies and "requested for inclusion" modules were being incorrectly overwritten.

This allows for script modules to be exposed in the import map
regardless of being a dependency or enqueued.

This will enable scripts to depend on script modules by requesting they
be exposed.
The + operator merges arrays with key overwriting.
array_merge renumbers numeric arrays, the desired behavior in this case.
@sirreal sirreal force-pushed the script-modules/new-method--add-to-importmap branch from 350705f to d30c9de Compare December 17, 2024 09:36
/**
* @ticket 61500
*/
public function test_included_module_appears_in_importmap() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In core, the best practice when using multiple assertions in a test is for each assertion to have a custom error message. Makes debugging easier.

@sirreal sirreal marked this pull request as draft December 19, 2024 09:08
@sirreal
Copy link
Member Author

sirreal commented Dec 19, 2024

#8024 implements a complete system utilizing this.

I'm not too happy with the result. It requires scripts to print before the importmap which is not reliable.

It may be better to have scripts continue to declare module dependencies, but when printing the import map have the module system query enqueued scripts and print their module dependencies in the importmap.

I'll make this PR a draft while I continue to explore a complete implementation.

@luisherranz
Copy link
Member

@luisherranz I'd love your thoughts on this.

Code-wise, it looks good to me. The only question I have is why you decided to use an external array instead of a flag in the properties of the registered script module (like enqueue).

@sirreal
Copy link
Member Author

sirreal commented Dec 19, 2024

I've found an approach in #8024 that seems like a better solution and does not require this work. I'll close this PR. If folks think there's still value in adding this method we can reopen and consider it.

@sirreal sirreal closed this Dec 19, 2024
@sirreal sirreal deleted the script-modules/new-method--add-to-importmap branch December 19, 2024 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants