Support jQuery 3.7.1 and jQuery UI 1.14.0

ram4nd → changed the visibility of the branch 7.x-4.x to hidden.

Sorry I haven't had time to review the MR in detail.

Can you please explain why it doesn't work to use custom paths to update to the newest versions of:

* jQuery
* jQuery UI
* jQuery Migrate

?

One of the problems with committing all the JS for specific versions - e.g. jQuery 3.7.1 - is that it's likely to go out of date so quickly.

Do we then add a full copy of 3.7.2 when it's released (leaving 3.7.1 in place too)?

That's how we ended up with tens of megabytes of JS in the module before; most of it outdated.

The problems in my eyes are:

• There are some style changes that need to be added.
• You would have to add jquery.ui on every single page, instead of loading it with $form['#attached']['library'][] = array('system', 'ui.dialog');.
• Consistency, the deprecated versions are selectable via dropdown, but correct version is not? Reverting to urls, is kind of getting past the point of the module.

Personally I'd prefer to add the style tweaks / any other shims to the module, plus make any logic changes to e.g. add UI whenever jQuery is being added - if that is necessary..

..but leave the actual libraries out of the module.

The final releases of the 1.x and 2.x branches were retained for legacy / BC, but you can see all the old cruft that was removed in #3311834: remove unsupported JS libraries → .

I would really prefer not to add any more copies of the actual libraries to the module.

They will go out of date and the module will bloat (again) if a new copy has to be committed with every release.

Perhaps after EoL the logic changes, but one motivation for removing almost all of the copies of the jQuery libs from the module was that otherwise there's some expectation that if a copy is included in the module, it's somehow "Supported". Moving to the actual JS code being managed externally removes that; once a release is no longer supported by upstream it's not supported by this module either (sort of with the exception of those two final releases from the 1.x and 2.x branches).

Sorry I think missed an important point in my previous comments.

It's not just that the module gets bloated and messy if it includes a full copy of every upstream release.

It also means that the module maintainers are expected to do a new module release for every (point) release that comes from upstream.

That's probably the most compelling reason to decouple the module from the upstream releases.

The module should handle the integration and any shims etc.. but when it comes to updating to a new upstream release sites should be able to do that for themselves.

(Another reason it makes some sense for the old 1.x and 2.x releases to be included in the module as we don't expect any new releases on those branches).

I'm going to set this to NW as I'm pretty convinced that we shouldn't add the actual JS libraries to the module.

I am of course happy to discuss it further though.

To me it is a question of what the module actually is. I know that libraries are preferably not bundled in modules. But this seems to be the exception. I am not worried about bumping the minor version if there would be never version of 3. Since the module never was focused on CDN implementation, but bundling jQuery for replacement in core. I personally would prefer it to be updated in core itself, but it seems using jquery_update is preferred by the community. The changes posted seemed appropriate to me.

Okay to get all "existential" about it (what's the module actually for?)..

The reasons for stripping out all but the final 1.x and 2.x jQuery releases from the module and moving to the "custom paths" approach were explained in detail here:

• #3166985: [Proposal] provide supported / recommended jQuery versions for Security coverage →
• 🌱 Plan for jQuery Update 7.x-4.0 release Fixed

From fairly early on the module provided some CDN integration, and the previous maintainer had argued for a long time that it should focus only on providing integration with CDNs so that jQuery libs could be brought in that way - see #1869928: Better CDN/API/automation support → .

The problem was that nobody actually implemented that improved CDN functionality.

Given the time (and/or community contributions) I'd have happily committed changes to the module that allowed a slick CDN integration where e.g. the admin UI presented a choice of versions available from a choice of CDNs.

However, what we had to settle for instead was a basic implementation which is somewhat DIY for site maintainers - i.e. they have to provide the URLs of a CDN version, or to a local copy.

This certainly isn't fancy (although we did manage to add some functionality to advise site owners when new releases are available etc..) but it solved some of the fundamental problems that the module had whereby it was - at one point - a collection of outdated and insecure copies of the various jQuery libraries, which was for the most part unmaintained but nevertheless used by a large percentage of all D7 sites.

Going back down the path of committing copies of the libraries to the module seems like a big step backwards to me (for the reasons outlined), and I'd need to be convinced that there's a very good reason for doing so.

In the meantime, I'd welcome an MR that provides compatibility shims etc.. for more recent release of jQuery 3.x and other libraries.

There's also:

• ✨ jQuery Cookie 1.4.1 replace with Js-Cookie 3.0.5 and Shim Needs review - seems worthwhile, but has been waiting for (basic) tests for a long time.
• ✨ jQuery 4.0 Support Active

📌 [DRAFT] [META] Drupal 7 policy on jQuery related vulnerabilities Active is also relevant.