[wp-trac] [WordPress Trac] #65165: Script module dependencies may be unavailable on evaluation

[WordPress Trac]

#65165: Script module dependencies may be unavailable on evaluation
---------------------------+--------------------------
 Reporter:  jonsurrell     |       Owner:  westonruter
     Type:  defect (bug)   |      Status:  accepted
 Priority:  high           |   Milestone:  7.0
Component:  Script Loader  |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  javascript
---------------------------+--------------------------

Comment (by jonsurrell):

 Replying to [comment:7 jorbin]:
 > > This ties in with some thoughts I have about private modules. I'd like
 to be careful and judicious about what modules Core exposes and espree may
 not make a lot of sense as a Core module.
 >
 > Could you go into a little more details about what you are thinking
 here? What are the risks associated with espree being available outside of
 core?

 The general idea is that any modules exposed by Core become part of the
 WordPress public API. Then it's much more difficult to modify them in any
 way due to backwards compatibility concerns.

 To use `espree` in a hypothetical example, the latest version is `11.2.0`.
 If version `12.0.0` comes out soon and is full of nice improvements and
 breaking changes, then Core has a difficult decision to make if it wants
 to upgrade. Assuming `espree at 11.2.0` has become part of Core's public API,
 can Core upgrade without breaking a backwards compatibility? Does it need
 to add `espree12` as another Core module and leave `espree` as the v11
 module indefinitely?

 I don't think WordPress Core actually has any business providing an
 `espree` module for extenders. Exposing it as a Core module is really an
 undesired effect of the current limitations of WordPress' module system.

 I'd like to expose some modules as "Core-only" by scoping them to be
 available only to Core. [https://developer.mozilla.org/en-
 US/docs/Web/HTML/Reference/Elements/script/type/importmap#scoped_module_specifier_mapsThis
 can be achieved technically by using importmap scopes:]

 {{{#!xml
 <script type="importmap">
   {
     "imports": {
       "…no espree here…": "…"
     },
     "scopes": {
       "/wp-includes/js/": {
         "espree": "/path/to/espree.js?v=123"
       }
     }
   }
 </script>
 }}}

 This makes it clear that `espree` is private, it's only exposed to
 JavaScript under the `/wp-includes/js/` path. Extenders cannot access it.
 `espree` is clearly private and there are no longer backwards
 compatibility concers. Core is free to update, change, or remove it at any
 time in the future.

 A more interesting case than espree is when considering syntax
 highlighting for code editors. It's a similar situation where I don't
 think Core has any desire to expose a code editor library to extenders,
 but does have reason to use one internally. A code editor library is more
 likely to bundle functionality and it would be good to have flexibility to
 change the exposed functionality or split up the bundle in different ways
 to optimize its size or loading characteristics.

 There are a number of tricky questions to work out, like scoped modules
 that may be served from a CDN or how a private modules API could be
 exposed to extenders. For most extenders, there's likely littler reason to
 use private modules and the global `imports: {}` is fine. However, I
 suspect framework-like plugins would likely find private modules useful to
 differentiate their public modules from internal, private ones.

 This is worth a ticket of its own, but I'm glad to share these ideas 🙂

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