Problem/Motivation

Now that jQuery 3.0 has been released jQuery 2.x will only be receiving security updates. I know what we've had discussions about updating specific libraries in the past. But there are a few compelling reasons why we should consider updating jQuery to 3.x

Support for JavaScript Promises: This could potentially make a large change in the readability / programming of deferred actions / behaviors.
Better error reporting: Apparently jQuery has add a number of actions that silently failed in the past, now fewer of those silently fail.
Let's make a statement that Drupal doesn't get stuck in the past with JavaScript libraries any more: A key problem with Drupal in the past is that we didn't want to break core by updating jQuery but that led to all kinds of hacks that we had to rely on in cases where we needed to update the library. Let's move forward now that we have semantic versioning.
References:
https://blog.jquery.com/2016/06/09/jquery-3-0-final-released/

Proposed resolution

- A POC with jQuery3 naively applied can be made to actually evaluate the issues with it. (it may take to wait for jQueryUI to be compatible ?)
- Considering to remove deprecated APIs in current 2.x before other libs supports catch up.

Files: 
CommentFileSizeAuthor
#31 core-js-update-jquery-2533498-31.patch577.18 KBnod_
#4 prepare-d8-for-jquery3.patch606.83 KBDom.
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 98,232 pass(es). View

Comments

Dom.’s picture

Wim Leers’s picture

Issue tags: +JavaScript
nod_’s picture

Title: [policy] Should we embrace Jquery 3 for the future ? » Prepare D8 for jQuery3
Category: Plan » Task

Updating issue metadata to reflect the situation :)

Since we update to latest lib available, and jQuery has a good track record of shipping before us we should get ready. They don't have a 1 year beta cycle :þ

Looking at the changelog I don't think that many things will break (haven't tried it yet though).

Dom.’s picture

Status: Active » Needs review
FileSize
606.83 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 98,232 pass(es). View

Actually it does not seems to break much indeed. Too bad we don't have JS-enabled test coverage to know for sure on any feature.

cilefen’s picture

Issue summary: View changes
Dom.’s picture

Thanks for corrections @cilefen ! I'm not a native you have guessed, and I know bad grammar can be a spike in the eye while reading for native readers !

nod_’s picture

Issue tags: -jQuery Version

Probably need a jquery ui update at the same time.

Just got a "Uncaught TypeError: f.getClientRects is not a function" error on some quickedit dialog. It's still functional but the placement is wrong. Looked at jqueryui source, it's fixed in the git repo but no release with said fix. Need to wait for a jquery3 compatible jquery ui to update this.

In our code, I haven't seen anything breaking. Looks like we did a good job dodging bullets.

catch’s picture

Priority: Normal » Major
Issue tags: +rc target
catch’s picture

It'd be great to ship Drupal 8 with jQuery 3. Does someone have a contact at jQuery that could help us coordinate that?

nod_’s picture

I'll ping scott_gonzalez. In the meantime the github milestone shows it's not there yet. https://github.com/jquery/jquery/milestones

webchick’s picture

I'm thinking this is something we could call out in the release notes as "not yet, but targeting before release" maybe. It doesn't seem wise to replace a stable, working jQuery with an alpha jQuery in RC1. OTOH, I would hate to ship 8.0.0 with jQuery 2 if 3 is ready before we are. And even if it's merely close (at least beta, ideally RC), we might want to move 8.0.0 to it, or at least 8.1.0.

Dom.’s picture

I can't find info on jQuery3 roadmap at the moment. But indeed, it would require to be included as soon as possible (ie stable) in Drupal 8.

catch’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Needs review » Postponed
Issue tags: -rc target +minor version target

This isn't possible until there's a new tag for jQuery 3, since it's been months since the last one and there's no information anywhere about it.

Bumping to 8.1.x. If that new tag does arrive during release candidate, we can move it back.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mirom’s picture

Status: Postponed » Needs work
droplet’s picture

Title: Prepare D8 for jQuery3 » Update jQuery to version 3
Issue summary: View changes
Wim Leers’s picture

http://blog.jquery.com/2016/06/09/jquery-3-0-final-released/ lists BC breaks. For example .load() has been removed. devel and panels_ipe use that, for example. It's easy to fix, but it is a break.

OTOH, there are still relatively few D8 contrib modules and sites, so the pain to fix these relatively minor breaks will be fairly small, and will have the benefit that we're not left behind on jQuery 2.x for years to come.

Tough call. Does semver apply to APIs of the 3rd party libraries shipped with software?

effulgentsia’s picture

Does semver apply to APIs of the 3rd party libraries shipped with software?

Technically, I think, yes, it does. If something is a break to the "public API" of a library, then I think it's also a break to the public API of the Drupal core package, if Drupal core's composer.json or bundled JS files are changed to use the later version of the library. https://www.drupal.org/core/d8-allowed-changes#minor lists patch- and minor- level library updates as allowed during Drupal minor updates, but does not mention how to handle major- level library updates, because those need to be evaluated case by case.

In the case of updating to jQuery 3, we might have an out: the .load() method mentioned in #17 and the other event aliases removed in jQuery 3, were all marked as deprecated in jQuery 1.8, and jQuery 2 was released as being API-compatible with 1.9. Which means these methods could be interpreted as not in the public API of jQuery 2 for semver purposes. Note that by the jQuery team bumping the major version number from 2 to 3, they're signaling that that isn't their interpretation, but as Drupal, I think we're free to interpret differently than them.

I don't know if there are other breaks in jQuery 3, which we'd need to also evaluate with respect to semver.

Something else to consider is that jQuery Migrate can be used to restore (some? all?) legacy APIs. So we could potentially either ship with this in 8.2 and then remove in 8.3, or leave it out of 8.2 and leave it to contrib modules that need it to add it as a dependency.

Tagging for release manager feedback.

catch’s picture

With Symfony 3.0 we posted https://www.drupal.org/node/2403135

#2712647: Update Symfony components to ~3.2 shows that in practice Symfony 3.x has bc breaks which aren't just dropping deprecations from Symfony 2.8. We're trying to minimize those in the issue but even then, on impact vs. disruption it makes sense to update the version.

For me the same goes for jQuery 3.0 - I do think would be worth adding jQuery migrate in 8.2.x and removing it in either 8.3.x or 8.4.x, but unless there was serious breakage, staying on 2.* for the next 3-8 years would feel like shooting ourselves in the foot.

droplet’s picture

effulgentsia’s picture

Removing "Needs release manager review" tag, because that was provided in #19.

I do think would be worth adding jQuery migrate in 8.2.x and removing it in either 8.3.x or 8.4.x

Given that comment, how about making this issue add jquery-migrate to core/assets/vendor and adding that as a JS asset within the jquery entry of core.libraries.yml? That way, it's always included when jquery.js is included.

We can then open a follow-up issue to either make it a separate library within core.libraries.yml or to remove it entirely from core, and make corresponding decisions for when to do either or both of those. But meanwhile, I think that would allow this issue to proceed right away with minimal (possibly 0, depending on how complete jquery-migrate is) BC breakage.

andypost’s picture

I think better to make jQuery library dependent on that new "migrate" library and change record to describe how contrib themes can disable that

Maybe for 8.2.x add new experimental module #2042165: Add a 'deprecated' module that includes deprecated functions only when enabled

Wim Leers’s picture

and adding that as a JS asset within the jquery entry of core.libraries.yml

IMO it would be better to add jquery.migrate as a separate library, and let the jquery library depend on jquery.migrate. That provides the same guarantee. But then it's conceptually separate, which makes it a bit easier for sites with "better jQuery code" to omit the jquery.migrate library.

… which apparently is exactly what @andypost wrote :)

effulgentsia’s picture

I think better to make jQuery library dependent on that new "migrate" library and change record to describe how contrib themes can disable that

+1. I agree that's better than #21. However, do we need a way to prevent someone from adding the jquery.migrate library directly without adding the jquery library? Not that there's a use case for that, just what code is needed to prevent it happening by mistake? I don't think we can have each library depend on the other, can we?

Maybe for 8.2.x add new experimental module #2042165: Add a 'deprecated' module that includes deprecated functions only when enabled

Yes. If/when we have that module, we can make that the module that creates the dependency. Until then, let's proceed with the dependency created in core.libraries.yml for now.

Wim Leers’s picture

However, do we need a way to prevent someone from adding the jquery.migrate library directly without adding the jquery library?

I don't see why. More importantly: we can't. We don't have the concept of "private libraries" like we have "private services".

effulgentsia’s picture

I don't see why.

See https://code.jquery.com/jquery-migrate-3.0.0.js. The JS does in fact depend on the jQuery object existing. Therefore, jquery.migrate should list jquery as a dependency, both for conceptual accuracy, and because including the former in a web page without including the latter results in a JS error.

I don't think we can have each library depend on the other, can we?

I checked, and currently we cannot. We get infinite recursion in LibraryDependencyResolver::doGetDependencies().

I therefore think we need to either add support for mutual (circular) dependencies, or make it all part of a single library, per #21.

which makes it a bit easier for sites with "better jQuery code" to omit the jquery.migrate library

Even if part of the jquery library, can't these sites hook_library_info_alter() out the jquery-migrate JS file?

webchick’s picture

Just noting that jquery.com promotes v3.1.0 as the recommended release on the home page. We should try and figure this out for 8.3.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

frob’s picture

I checked, and currently we cannot. We get infinite recursion in LibraryDependencyResolver::doGetDependencies().

I therefore think we need to either add support for mutual (circular) dependencies, or make it all part of a single library, per #21.

So what is the next step? Add support for circular dependency?

nod_’s picture

Title: Update jQuery to version 3 » Update jQuery to version 3 and jQuery UI to 1.12

jQuery 1.12 got out this month, and does support jQuery 3, we're good to go (but need to update both at the same time).
http://blog.jqueryui.com/2016/09/jquery-ui-1-12-1/

nod_’s picture

Patch with jquery 3, no jquery ui update. Dialog are opening but not placed correctly on the page.

nod_’s picture

Problems with jquery ui latest version, upstream bug: https://bugs.jqueryui.com/ticket/15052#ticket

nod_’s picture

Title: Update jQuery to version 3 and jQuery UI to 1.12 » Update jQuery to version 3
Related issues: +#2809427: Update jQuery UI to 1.12

Split the jquery ui in it's own issue since it might be headache-y

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

effulgentsia’s picture

We didn't get this done in time for Drupal 8.3 beta. Updating a library to a new major version is risky to do after beta and not allowed at all in a patch release. So this issue is now likely an 8.4 only issue.

From http://blog.jquery.com/2016/06/09/jquery-3-0-final-released/:

While the 1.12 and 2.2 branches will continue to receive critical support patches for a time, they will not get any new features or major revisions.

Hopefully "for a time" will be at least 7 more months or so, long enough for Drupal 8.4 to be released.

I opened #2852636: Update jQuery to version 2.2.4 to at least get Drupal 8.3 onto the latest 2.2 patch release in the meantime.

gnuget’s picture

Should we postpone this one until #2809427: Update jQuery UI to 1.12 be fixed?