[wp-trac] [WordPress Trac] #47285: Better Management of External Asset Dependencies

[WordPress Trac]

#47285: Better Management of External Asset Dependencies
-----------------------------+--------------------------------------
 Reporter:  justlevine       |       Owner:  (none)
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Script Loader    |     Version:
 Severity:  major            |  Resolution:
 Keywords:                   |     Focuses:  javascript, performance
-----------------------------+--------------------------------------

Comment (by justlevine):

 Replying to [comment:1 nerrad]:
 > Worth noting, this problem is not new :)

 True that :) My big fear for why is believe it's now more urgent than ever
 is my understanding of the Block Library / Installer. When everything
 needs to be included in a standalone block, larger-scope plugins and all-
 in-one collections (where the author is using one version of one specific
 library for one function) become obsolete and replaced with everyone using
 the library at version they like the most. Not just do things become harder
 to dequeue, but you also end up loading even more competing libraries that
 a simple dequeue won't solve.

 >In the case of Gutenberg and blocks, there is some awareness around
 dependencies management

 Am I totally misunderstanding, or is stuff there   more regarding handling
 core WP libraries, and build processes? Which is obviously would be an
 even bigger issue (and I'm getting anxious just thinking about it)!

 I've only really seen a few slack messages or GitHub comments discussing
 the inclusion of external (non-Core) libraries, and how to prevent the end
 user from loading the 20 copies of FontAwesome in this distopian near-
 future. It'd be a relief to know this is on the radar of people who are
 actually qualified to discuss it!

 > The above doesn't speak to all your points in here but highlights
 related conversations/solutions happening elsewhere.
 Thanks! As I said an umpteen amount of times, while the issue is pretty
 obvious, my solution is half-assed and will hopefully (solely) serve to
 get this on the radar of people who aren't fretting about the
 #assetApocalypse, and the people who can actually do something to prevent
 it!



 Replying to [comment:1 swisspidy]:
 > Worth noting that the theme directory has some requirements for theme
 developers to always use the same script handle for external libraries
 when they use wp_register_script().
 If I'm not mistaken, it's only 'recommended'. More importantly this
 definitely isn't required for plugins, and to my knowledge is mostly
 discouraged in the developer community so as to prevent errors from using
 an incompatible library version. Which makes sense, IMO; better to include
 two scripts than increase the likelihood that the '80%' non-dev-enduser
 won't be able to get the plugin to work.
 But with mixing-and-matching functionality blocks on its way to becoming
 the norm, ''neither'' relying on handles nor including multiple copies of
 a dependency will be sustainable (comparative to now).

 >Resolving dependencies is not an easy task like this.

 I believe you. I'm admittedly more than  wholly unqualified to expect that
 the specifics of any part of the solution I proposed are sound. 😊

 Can you elaborate a bit though?

 From my basic understanding there's two issues when dequeuing and/or
 replacing multiple copies of a library:
 - The two versions aren't compatible. This is solved (well enough) by
 semver. If a plugin author says their plugin is compatible with 4.x.x,
 then even if they include v4.2, I can safely use 4.1, or the future-
 releaded 4.4. if someone is using v3 or v5, it gets included separately.
 - Two versions of the library can't be run at the same time. Sometimes
 this can be resolved with prefixing, or a noConflict mode included in the
 library. Other times, you're out of luck. Either way, this problem already
 exists, but with this proposal can be somewhat mitigated (by enqueueing a
 single version that meets both plugin requirements, or with WP core
 conditionals that check whether the library is enqueued twice and make it
 easier for either the plugin author or site developer to address the
 issue).

 And of course, there's likely a better way to resolve the dependencies,
 that someone more experienced than I would contribute!

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