[wp-trac] [WordPress Trac] #56313: Add the ability to handle ES Modules and Import Maps

[WordPress Trac]

#56313: Add the ability to handle ES Modules and Import Maps
-------------------------------------+-------------------------------------
 Reporter:  idad5                    |       Owner:  luisherranz
     Type:  enhancement              |      Status:  reopened
 Priority:  normal                   |   Milestone:  6.5
Component:  Script Loader            |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-unit-      |     Focuses:  javascript,
  tests                              |  performance
-------------------------------------+-------------------------------------

Comment (by luisherranz):

 > Is it desirable or possible for a module to depend on a non-module
 script, or vice versa? Should it be?

 I think so, yes.

 Copy-pasting here the opinion
 [https://github.com/WordPress/gutenberg/issues/55942#issuecomment-1839058988
 I shared about this topic] in the Gutenberg Tracking Issue:

 Migrating from scripts to modules is not possible for scripts that have
 external dependants due to backward compatibility issues. This means there
 are going to be scripts that will remain scripts forever.

 To increase the adoption of modules, it makes sense that:

 - New modules can still use those remaining scripts as dependencies.
   Ideally, developers should be able to use modules instead of scripts,
 and the need for script dependencies should not be an obstacle to the
 decision to use modules instead of scripts.
 - Those remaining scripts can use new modules as dependencies.
   Ideally, all new packages should be modules from now on, and the need
 for existing scripts to use those modules as dependencies should not be an
 obstacle to the decision to use modules instead of scripts.

 I also believe that the priority should be on the modules:

 - **From now on, WordPress developers should be able to use modules
 instead of scripts for all their needs**.
 - All the existing WordPress packages should be available to be consumed
 as modules from now on, even if some of them are linked to existing
 scripts under the hood.
 - Developers should not need to know which WordPress packages are linked
 to existing scripts. For them, everything should look like regular modules
 from now on.
 - Developers should not need to use a _script-related_ bundling tool while
 building their modules anymore.
 - Existing scripts should be able to import modules, but in this case, the
 API can be explicit: developers should know when they are importing a
 module instead of a script.


 > There appears to be no way to fetch the list of enqueued modules like it
 is for non-module scripts. I'd like to display the list of enqueued
 modules in my Query Monitor plugin but it doesn't seem possible. Perhaps
 the `get_marked_for_enqueue()` and `get_dependencies()` methods need to be
 public instead of private.

 As stated in [https://github.com/WordPress/wordpress-develop/pull/5818 the
 PR description], **this initial version was intentionally simplistic**.
 That way, we start with something that provides the basic functionality,
 and build upon it incrementally. So if you want/need to add new
 capabilities, I think those should be discussed in new tickets.

 > This feature only works on the front end, not within the wp-admin area,
 is this intentional?

 It's not. Feel free to add a new ticket to add hooks for the admin.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56313#comment:49>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform