Problem/Motivation
This module will continue to be useful for Drupal 10. For example, to support sites using Bootstrap 3 (
🌱
Drupal 10 compatibility
Fixed
).
Currently, this module's jquery_ui.core library extends core's jquery.ui library, but that will be removed in
📌
Actually remove deprecated jquery_ui libraries from core
Fixed
, so we'll need to decide on a different approach for this.
Steps to reproduce
Proposed resolution
As of nov 10 2022 the proposed solution implemented is the MR is option D: committing built files to the d.o repository, and only committing built files in jquery_ui, not in the various sub-modules such as jquery_ui_tabs, jquery_ui_slide, etc.
1. End-user experience
jQuery ui is used by about
27% of D8+ sites today (112188 sites) →
according to d.o project usage data. Because we point people to it in the deprecation message that number is going to increase in the short term and until jquery ui is removed from the various custom and contrib module/themes using it (so, not soon).
- This means that this module should be a "composer require and forget", after the
require the module is functional: no nodejs required, no running a build step, people can go in the project browser, install it and it just works. Regardless of how we handle assets.
- The user need to be able to update the jquery UI version independently of updating the Drupal module. A new jQuery UI release should not mean the module needs a new release. It suggest having a way to monitor the latest version in the module and comparing to the installed version.
Do we agree on the target user experience? Before we dig in the technical discussion we should align on this first.
2. Module management/maintenance on d.o
It seems like we agree that having individual jquery ui component in it's own module is not ideal.
Regardless of how we handle the assets, would deprecating all the jquery_ui_* modules and regrouping everything in jquery_ui would be something acceptable? That would also simplify asset handling. We would lose the component usage data but it's not that critical.
- jquery ui module should replace the core assets to keep a single consistent version loaded (since we can update the version at any point per 1.2. above)
3. Library definition/component separation
Context for later: we have always split the jquery ui library by component so that one jquery ui component = one drupal library definition. That is because jquery UI packaged in a single file is big 69kb gzip (255kb unziped), for reference what core uses:
- dialog only: 37kb gzip (86kb unziped)
- autocomplete only: 20kb gzip (35kb unziped)
- dialog + autocomplete: 43.7kb gzip (105kb unziped)
Using the existing jquery-ui.min.js as a whole hosted in CDNs adds twice or three time as much JS as the current component-based libraries.
Using the unminified files from the cdn such as widget.js has an unnecessary impact on file size. The source version of the widget.js file is 20kb unziped and the minified version is 8.5kb unziped.
- We need to keep each component separated => a step between the official jquery-ui npm package and the end-user is necessary.
4. Extra step/Asset handling
Assumptions:
- Respects target user experience in 1.
- A single jquery_ui module, see 2.
- We keep a lib definition for each jquery ui component, see 3.
If we don't have the same assumptions we can stop here and align before going technical. I'm not trying to address the security concerns because I'm not 100% familiar with them so I don't want to make wrong assumptions, the implications should be pretty clear in each case though.
A. The bad solution
One possibility we didn't discuss is to opt-out of security coverage for the jquery ui module altogether.
B. Serve assets from a CDN
In this scenario *someone* would create a npm package that has all the built assets like we need them, and publish that on NPM (not under @drupal namespace of course). And use one of the auto CDN to point to the files in the module library definition. A setting could be available to serve the files from the CDN (default) or from the libraries/ directory if the user install them manually somehow.
This introduce a couple of problems:
- there is now a js package to maintain/trust (outside of core js packages)
- If we host this pacakge as a general project on d.o, then jquery ui code still ends up on d.o
- We trust a CDN with a third of all the Drupal sites, and hope nothing changes unexpectedly
I do not think this is a good solution. It simply moves the problem somewhere else (or not even in case of a general project) and adds a couple of new moving parts.
C. Composer magic aka. PHP built step
I think it's possible to do the whole build pipeline in PHP: essentially we would download the zip file for jquery-ui from npm, unzip it, run some php minifier over the files, copy them in a libraries/ folder somewhere so they'll be picked up automatically.
This fit with target UX, but has some problems:
- adds some significant processing for 100+k sites
- PHP-based minification is less good than what we have today
C'. Composer magic aka. PHP copy/paste
An alternative version of C. would be to get the Drupal-custom package created in scenario B. and unzip it in the libraries folder. Beside the CDN, same problems as scenario B.
- there is now a js package to maintain/trust (outside of core js packages)
- If we host this pacakge as a general project on d.o, then jquery ui code still ends up on d.o
D. Host built jquery ui assets on d.o
Adapt a version of the core vendor-update script to automatically copy/build the jquery ui files from the official npm package, like we do in core. Commit the built/minified files to the module.
No disruption for end users, no extra php code involved, additional maintenance is the vendor-update script run by the jquery_ui module maintainer.
Remaining tasks
User interface changes
API changes
Data model changes