[wp-trac] [WordPress Trac] #60647: Script Modules: Allow modules to depend on existing WordPress scripts

[WordPress Trac]

#60647: Script Modules: Allow modules to depend on existing WordPress scripts
-----------------------------+-------------------------
 Reporter:  jonsurrell       |       Owner:  jonsurrell
     Type:  feature request  |      Status:  assigned
 Priority:  normal           |   Milestone:  6.6
Component:  Script Loader    |     Version:  6.5
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:  javascript
-----------------------------+-------------------------

Comment (by jonsurrell):

 I've spent more time thinking about this. I see two options:

 The first option is to allow modules to depend on scripts. This seems to
 be a fairly simple and safe change. Scripts continue to exist as scripts
 for the foreseeable future. Modules would use the scripts as e.g.
 `window.wp.apiFetch`. We can adapt existing tooling to help with this so
 folks can continue to author code like `import apiFetch from '@wordpress
 /api-fetch'` and compile it with the expected dependency and result (`wp-
 api-fetch` ''script'' dependency and `const apiFetch =
 window.wp.apiFetch`).

 The downside with this first option is that it does not provide a
 transition strategy from scripts to modules and we sacrifice some of the
 potential benefits of modules like deferred or conditional/on-demand
 loading of modules.

 ----

 The alternative is to expose scripts as modules somehow. Most of the
 modern scripts available in WordPress are authored as modules, then
 compiled via webpack as "libraries" — they expose their exports as global
 values, e.g. `window.wp.apiFetch`.

 The proxy modules I've described in earlier comments provide a mechanism
 where a script dependency could be used when present or a module used on-
 demand when necessary. However, the proxy modules are worse in most ways:
 they're mostly overhead that only serve to use a module or script. The
 benefit would come if we can determine that a given script is not used on
 a page so that its corresponding module can be used directly without a
 proxy. If we cannot meet those conditions or only meet them in extremely
 rare conditions, then I don't see reason to pursue this approach.

 I'll describe some scenarios to explain my thinking:

 - `wp-api-fetch` script is present. `@wordpress/api-fetch` module is not a
 dependency. Behavior is unchanged.
 - `wp-api-fetch` script is present. `@wordpress/api-fetch` module is a
 dependency. In this case `@wordpress/api-fetch` should point to the proxy
 module so that the `wp-api-fetch` script is used and not duplicated as a
 module.
 - `wp-api-fetch` script is not present. `@wordpress/api-fetch` module is a
 dependency. In this case `@wordpress/api-fetch` should point to the full
 `@wordpress/api-fetch` module  to take advantage of the benefits of ES
 modules.

 The difficulty of this comes from knowing whether a given script will be
 added to a page when we print the module importmap, that's the moment when
 we must provide a URL pointing to a proxy module or a real module. The
 importmap  must be present on the page before any `script type=module` or
 `link rel=modulepreload` tags. Ideally the module preloads and the
 importmap are printed early in the page, so if scripts are enqueued late
 this information may not be available. [https://github.com/WordPress
 /wordpress-develop/pull/5931 This was a problem with the Modules API and
 classic themes].

 Maybe proxy modules could always be used with classic themes, but block-
 based themes could use this strategy of using the proxy or a real module
 depending on whether a script is enqueued.

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