[wp-trac] [WordPress Trac] #37110: Update to jQuery 3.*

[WordPress Trac]

#37110: Update to jQuery 3.*
-------------------------------------------------+-------------------------
 Reporter:  jorbin                               |       Owner:  (none)
     Type:  task (blessed)                       |      Status:  reopened
 Priority:  normal                               |   Milestone:  5.5
Component:  External Libraries                   |     Version:
 Severity:  critical                             |  Resolution:
 Keywords:  early has-patch needs-testing        |     Focuses:  javascript
  needs-screenshots has-dev-note commit          |
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:157 desrosj]:
 > If a plugin or theme adds an enqueue for jQuery migrate, they are
 acknowledging that they are aware of the problem, researched why it
 happened, and made a purposeful change to temporarily fix the issue.

 True. At the same time letting `jquery-migrate` be enqueued separately
 (instead of `jquery`) will bring problems/make things messier in the
 future, when jQuery Migrate is updated. After that too, when it is
 disabled/removed again in 5.7+. Then the only way to control this would be
 to remove Migrate from core and fail all these plugins and themes...

 So the options here are:
 - Add support for direct enqueuing of jQuery Migrate "temporarily" only
 for 5.5, then remove it in 5.6. This will break all plugins and themes
 that still use it at that time.
 - Add support for migrate and keep it in core "forever". This will make it
 even harder to update jQuery in the future, almost impossible, considering
 that some plugins will expect some versions of jQuery with some versions
 of Migrate, others will expect different, ... :)

 > As for creating a plugin or polyfill to solve this (other than
 [attachment:"37110-add-dependency.diff"]), I am still of the opinion that
 creating a custom wheel here should be avoided.

 Generally if the core team doesn't create a plugin, somebody else will (in
 few hours). Then the core team will be "stuck" with having to consider
 users of that plugin as well, instead of having opportunity to reach users
 that still need to update old scripts.

 > If it's decided that there is enough potential for breakage that action
 should be taken, then my vote would be to revert [48323] and use a more
 aggressive outreach program (emailing plugin and theme authors directly,
 and often), and retry again in 5.6.

 Yeah, this is also a possibility, but... There will always be some
 breakage, and always will be need of old code to be updated. Not sure what
 kind of "aggressive outreach" you have in mind, thinking a good example
 would be to have a postbox on the dashboards of all WP installs that still
 have old scripts. That would be doable by a canonical plugin, would also
 be doable directly in core, but..? :)

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