[Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path

For me we should only deprecate jquery ui in D8 and remove it in D9. The need is mainly around dialogs, autocomplete, and dragging: we should use new libs to do the job (and we already have 2 issues open for dialog and autocomplete replacement).

It's going to be a bit painful to do but I'd say it's worth it. At least it's less work than maintaining the whole jQuery UI project.

+1 on #3

I'll be happy to help to replace jQuery UI code with new libraries.

:D

I would love to see more about what this will take, how disruptive it would be, and how we could mitigate the disruptions. From a release management perspective, having jQuery UI as a dependency is risky business.

Makes sense to resurect as well #2833968: Upload progress using jQuery.form plugin instead of 3rd party PHP libraries

Also opened #3051766: Deprecate and replace jQuery Joyride (for tours) based on the Umami demo meeting today.

Anecdotally: just today, I encountered an issue where accessibility issues were raised with Drupal 8's (and hence presumably also jQuery UI's) dialogs: #3037446: Forms with required fields marked by asterisk do not have text explaining what the asterisk means.

I'd like to have a replacement for jQueryUI :tabbable and :focussable selectors. Now that we have Nightwatch in core, we can start adding tests for expected keyboard behaviours; those selectors will be handy for some assertions.

A possible replacement is a11y.js, which has equivalents for these selectors, and provides a few more handy things (e.g. a :focus-within polyfill). As it happens, jQueryUI was considering Replacing jQuery UI's :focusable and :tabbable implementations with the ones from a11y.js.

There is also marklagendijk/jQuery.tabbable but that still depends on jQuery itself, so it won't help us with #3052002: [meta] Replace JQuery with vanilla Javascript in core.

Re. #10: I'm not convinced those are jQueryUI problems. I'll comment on that issue soon.

Now that we have Nightwatch in core, we can start adding tests for expected keyboard behaviours; those selectors will be handy for some assertions.

My god, how I wished we had this when working on Quick Edit ~6 years ago! #1844220: Make in-place editing keyboard and aurally accessible still hasn't happened :|

Drupal.tabbingManager would still benefit from such tests: https://www.drupal.org/node/2014545.

So according to a jQuery UI blog post from 2017, the goal was to merge jQuery UI and jQuery mobile. However, jQuery Mobile hasn't received a stable release since 2014, doesn't even support jQuery 3 yet, and it's not clear if the major release they've been developing for the past 2-3 years will actually serve as a jQuery UI replacement.

Given that jQuery 4 might show up as early as next year and (based on history) jQuery 3 security coverage is going to stop after that, I don't think we can risk having dependencies on packages with such slow development and that are so far behind. So let's audit everything we use jQuery UI for in core, and then start working on replacements for individual parts (whether it's decoupling our code, forking that part of the library and making it our own, finding a modern replacement, etc.)

Based on the security risk and the fact that this might end up blocking Drupal 9, I'm promoting this to critical.

I agree with Jess' proposed plan 👍

I agree with 1 caveat, we need to have a contrib module with jquery.ui so we don't break the 'Drupal 8 to 9 will be a painless update'

Many client sites will have components built on top of jquery.ui - in particular the widget and we should give them a BC layer to do it over time.

@xjm: do you have a source link for next year's potential jQuery 4 release? I randomly found https://github.com/jquery/jquery/issues/3886 which mentioned jQuery 4 beta may be released in 2018 but that apparently did not happen.

Looking at the jquery repository only 12 of the total 67 open issues have been created this year: https://github.com/jquery/jquery/issues?page=1&q=is%3Aissue+is%3Aopen also average commit activity is 0-4 commits per week: https://github.com/jquery/jquery/graphs/commit-activity so it does not look like a project preparing a new major version? The roadmap page was last changed in 2018 September, other than a minor one line addition of plans to moving API docs 3 months ago.

These 2 websites might be a good place to start finding solid replacements for the various jquery ui plugins:

http://youmightnotneedjqueryplugins.com/
https://plainjs.com/javascript/plugins/ui/

Wow.

To be clear: we're talking only jQuery UI, right, not jQuery? Or is also a risk? (Based on #16, it sounds like that could also be a risk.)

Re #19: this issue is just about jQuery UI.

jQuery potentially releasing version 4 within the next year or so is relevant in that it's uncertain whether jQuery UI will be compatible with it, which provides extra urgency for Drupal core to move off of jQuery UI, which I think is part of the motivation for #13 having raised this issue to Critical.

https://blog.jquery.com/2019/04/10/jquery-3-4-0-released/ mentions "we will move on to the overhaul that will be jQuery 4.0", but I'm unaware of any public communication from the jQuery team about how long they think that'll take.

@effulgentsia: I added this based on digging from @vijaycs85:

In the meantime the former jQuery foundation became the JS foundation which merged with Node's foundation and formed OpenJS Foundation. That lists jQuery UI as an Emeritus project in https://openjsf.org/projects/ which is described as:

Emeritus projects are those which the maintainers feel have reached or are nearing end-of-life

So we know jQuery UI will not get further updates/support. The goals of jQuery 4.0 itself are at https://github.com/jquery/jquery/milestone/7, development is not going too fast to say the least. Drupal 9 is planned to be supported until at least 2024 (ref: https://twitter.com/gaborhojtsy/status/1138715342174339074) so the jQuery team would still have 5 years to disrupt Drupal 9.

I spoke with @mglaman on Slack

The best simple approach seems to be:

• What jQuery UI libraries are we using vs. just defined
• Possible dependency tree inspection
• Fix from the bottom down, as most module are using `core/*` libraries which use jQuery UI.
• Find a vanillaJS replacements for each component, make sure it supports accessibility

I created an editable Google Sheet to summarize findings for each jQuery UI components with VanillaJS:
https://docs.google.com/spreadsheets/d/1XjWIg95-nTQDFJdhLJtgva9vq_sa6Lhp...

I added #3064049: Replace jQuery UI sortable with Sortable js as a child issue. Not sure if we want to do something similar for some of the other components used by core, but I figured it's a reasonable place to start, and we can iterate/evolve as needed.

Might want to take a look at the Van11y set of plugins. They have a focus on accessibility and do not have JQuery dependencies. They tend to use data attributes, BEM class names, and SMACSS js- prefixed classes by default, so they might be easier to integrate.

If you don't mind a dependency on JQuery, the same author has done a similar set of plugins.

#26 – Thanks @PCate. I've been aware of the Van11y project for a couple of years. They are indeed a good contender from the accessibility point of view. I think I've tried most of them, but it will be worth reviewing the latest versions, open issues etc.

Added #3064017: Create a means to mark an asset library as deprecated in a *.libraries.yml file to allow marking the unused Jquery UI libraries as deprecated.

I updated the IS with some research on which libraries are actually used in core and where.

Here's a search of where jquery.ui is used across all of D8 contrib code: http://grep.xnddx.ru/search?text=jquery.ui

I want to be clear that the approach we want here is essentially what @larowlan described in #15: We decouple it from core (either completely or as much as we can before our deprecation deadline), but ensure contrib can just declare their own dependency in a simple way.

The main library that's used by contrib but not by core according to webchick's grep appears to be accordion, looks like https://van11y.net/ has an accordion replacement so that's not the worst one.

I think we should do something like the following:

1. Open an issue to deprecate the unused libraries which are used by neither core nor contrib for Drupal 9. The most we could do for those is a change record pointing to a jQuery UI contributed project but more important to me to document what's happening asap. Even if we can't decouple in time for 9.0.0 we don't want to be on the hook to security support unused libraries. This should be critical IMO.

2. For libraries that core actually uses, make sure there are individual issues to switch to something else as child issues of this. These should all be critical, we can decide whether they're critical for Drupal 9 or Drupal 10 later, but it's going to be one or the other - we're either going to be doing the work to move to something else, or doing the work to keep supporting EOL code.

3. For libraries that core doesn't use but contrib does, we need a contrib project to provide the library definition to support the continuous upgrade path, but could also open core replacement issues if we want to.

Given any contributed jQuery UI project is going to suffer from the same security support issues we're facing here, IMO it would make more sense to have individual contrib projects for each component - that way a security release for one component doesn't impact users of the other ones. For a concrete example let's say jquery.ui.selectmenu has a security issue and jQuery UI is out of security support, that should not affect people who only use jquery.ui.accordion.

This would mean that for accordion specifically, something like this process:

1. Contrib project for jquery.ui.accordion that provides the library definition only for accordion.
2. Deprecate jquery.ui.accordion in core with a change record pointing to the contrib project.
3. Optionally add a new accordion implementation to core, but with no particular deadline for that.

+1 to everything in #33.

It makes sense to separate each of these libraries into a separate contrib module. @catch Do you think that jquery.ui.effects should be a single module with core, blind, bounce, clip, drop etc. all included, or should each single library be a separate module?

Looking at the link @webchick posted http://grep.xnddx.ru/search?text=jquery.ui.effects&filename= for "effects" and you see some themes include them all.

I think a single contrib module for jquery.ui.effects would work well, each of the individual effects could still be a separate library within that module.

+1 for a single Drupal Libraries dependency contrib module as it would be easy to support (single place to provide contribution), find maintainer and continually add following unsupported 3-rd party libraries (not only jQuery UI) in the future.

There are some benefits to keeping these individual projects separate, such as if there is a security issue with a single third party library.
If we start with the list @lauriii posted, it would be possible to make very simple contrib projects for each of the jQuery UI libraries listed in core.libraries.yml.

Some utilities could be grouped under a main jquery_ui project.

These modules could consist of an info and libraries file and the specific js or css currently in core/assets/vendor/jquery.ui.

example folder structure:

jquery_ui_[component]
 |_jquery.ui
 |  |_ui
 |  |  |_widgets
 |  |    |_[component]-min.js
 |  |
 |  |_themes
 |    |_base
 |      |_[component]-min.css
 |
 |_jquery_ui_[component].info.yml
 |_jquery_ui_[component].libraries.yml

example info file:

name: jQuery UI Droppable
type: module
description: 'Provides jQueryUI Droppable library.'
package: jQuery UI
core: 8.x
dependencies:
    - jquery_ui
    - jquery_ui_draggable        

The libraries file would be identical to what is currently in core.libraries.yml except for updated paths to files and dependent libraries.

Proposed list of modules, starting with the modules that can be currently marked deprecated:

• jquery_ui - this project page already exists but has not had activity since jQuery UI went into core. It would be great if we could use this as the namespace for this new module.
  It could include jQuery "core" files as well as some utilities depended on by the other libraries.
  • jquery.ui
  • jquery.ui.widget (required by nearly all the other libraries)
  • jquery.ui.mouse (required by slider, selectable, draggable)
  • jquery.ui.position (required by selectmenu, tooltip)
• jquery_ui_accordion - jquery.ui.accordion
• jquery_ui_button - jquery.ui.button - not in the deprecated list but required by spinner.
• jquery_ui_checkboxradio - jquery.ui.checkboxradio
• jquery_ui_controlgroup - jquery.ui.controlgroup
• jquery_ui_draggable - jquery.ui.draggable - not in the deprecated list but required by droppable.
• jquery_ui_droppable - jquery.ui.droppable
• jquery_ui_effects - since the individual effects depend on jquery.ui.effects.core it's more convenient to package them together.
  • jquery.ui.effects.core
  • jquery.ui.effects.blind
  • jquery.ui.effects.bounce
  • jquery.ui.effects.clip
  • jquery.ui.effects.drop
  • jquery.ui.effects.explode
  • jquery.ui.effects.fade
  • jquery.ui.effects.fold
  • jquery.ui.effects.highlight
  • jquery.ui.effects.puff
  • jquery.ui.effects.pulsate
  • jquery.ui.effects.scale
  • jquery.ui.effects.shake
  • jquery.ui.effects.size
  • jquery.ui.effects.slide
  • jquery.ui.effects.transfer
• jquery_ui_menu - jquery.ui.menu - not in the deprecated list but required by selectmenu.
• jquery_ui_progressbar - jquery.ui.progressbar
• jquery_ui_selectable - jquery.ui.selectable
• jquery_ui_selectmenu - jquery.ui.selectmenu
• jquery_ui_slider - jquery.ui.slider
• jquery_ui_spinner - jquery.ui.spinner
• jquery_ui_tooltip - jquery.ui.tooltip

#37 looks like a good plan to me and yeah seems sensible to group the effects together into one project.

Over at #3064017: Create a means to mark an asset library as deprecated in a *.libraries.yml file we've developed a way to mark libraries deprecated. In the journey towards RTBC, we initially had code to actually deprecate the core/jquery.ui.effects.scale asset library (and a test for it), but the core committers preferred not to actually deprecate anything until the dust settles in here. Therefore, the latest patch removes those hunks. So the work doesn't get lost, I'm attaching them here as the basis for what we should do once we decide what we're deprecating and how. Not bothering with needs review and a testbot run, since it won't do the right thing until #3064017 is committed, but at least it's now somewhere other than on the cutting room floor. ;)

Cheers,
-Derek

I've moved the proposal for moving deprecated jQuery UI libraries to contrib to the issue summary.

We don't have a plan for the components that core actually uses yet, but I think we can sort out this plan issue in a two stage process, so I'm going to RTBC the plan just for the components we don't use.

Once that's signed off, we can proceed deprecating those components, writing up change records and creating the contrib projects for them. We can then continue either here or in a follow-up issue to choose replacements for those we're using in core.

#3064017: Create a means to mark an asset library as deprecated in a *.libraries.yml file just landed. Re-testing #39, so now it should come back green.

Note that #40 marked this RTBC for the plan, not for the patch!

AFAICT given that both the infrastructure blocker (3064017) landed and the plan has sign-off from @catch, we can now start executing the plan? 😀

I don't remember how I found this document and who wrote it.
I think it will help in the process of phasing out jQuery UI components.

Drupal routes and frontend components

Based on @catch's comments and the IS update, I'm going to re-scope the issue to be about jQuery UI components not used by core. We'll need to create a followup meta for the rest of the work.

Edit: Key words were missing from sentence.

OK I've opened #3067251: Deprecate unused jQuery UI components in favour of a suite of contrib modules for the working issue to deprecate unused components.

And opened #3067255: Find replacements for jQuery UI components for finding replacements.

I think that's all we need to do here, but waiting for a +1 from someone else before marking this fixed since I RTBCed it. Also haven't yet sorted out issue credits but we should do that here despite there not being a patch since a lot of research happened.

Saving contribution credits for those that helped with the discussion here.

The follow-ups are in progress so I think we can call this fixed. Thanks everyone!

Just a note about the fact that the contrib modules cannot install under Drupal 9.0.x, see #3097631: Cannot install with Drupal 9.0.x