[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 westonruter):

 Replying to [comment:4 jorbin]:
 > Otherwise, I would like to also propose an Option E: Throw a
 `doing_it_wrong` if `module_dependencies` is set without `in_footer` as
 `true` or `strategy` set as `defer`.

 I like this suggestion, along with documentation that
 `module_dependencies` requires footer printing or `defer` loading
 strategy. Eventually, when browsers all support multiple import maps and
 we just-in-time print `importmap` scripts before printing scripts and
 script modules, we can remove this warning. It's true that a script
 //may// work around this by waiting to `import()` until
 `DOMContentLoaded`. But we can't know that, so better to warn. We won't
 block it, so the script may still work correctly, and the
 `doing_it_wrong_trigger_error` filter can be used to suppress the warning.
 However, this won't be needed if we do:

 > b. Add the polyfill and print multiple importmaps as needed.

 This would nicely eliminate the timing issues for ensuring that the
 `importmap` script is printed after all modules.

 > 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.

 This is true, but core has many libraries it makes available in default
 scripts which extenders can use. So adding espree is no different from
 previous such libraries (not to say we should keep doing this forever).

 In regard to scoped modules, we wouldn't actually have to register espree
 as a module to begin with. Inside of `wp_enqueue_code_editor()` we could
 include the full URL to the `espree.js` file among the data that gets
 exported from PHP to JS via the `wp.codeEditor` global. Then the relevant
 JS could do `await import( wp.codeMirror.path.to.espreeUrl )` as opposed
 to `await import( 'espree' )`.

 ----


 For 7.0, I think the least impactful to go with the documentation and
 `_doing_it_wrong()` to warn if `module_dependencies` is being used without
 `in_footer` or `defer`. For performance, we really want classic scripts to
 be using these anyway as a best practice, since it eliminates a blocking
 script from the critical rendering path. Then in 7.1 we can explore adding
 the printing of multiple `importmap` scripts along with the polyfill and
 remove the restriction.

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