Problem/Motivation
jQuery UI is supported again, unfork it and close all head-scratching related issues. The patch includes the few file changes from the 1.13 release: https://jqueryui.com/upgrade-guide/1.13/#files-amp-directory-structure
- #3093175: Document version numbering system for forked jQuery UI components
- #3093172: Test coverage for forked jQuery UI components
- #3094226: Determine what coding standards to apply to jquery ui source code
Proposed resolution
Get the unminified source from https://www.npmjs.com/package/jquery-ui and keep the existing minification step we currently have to build the production files used by Drupal.
The unminified source code is kept in core to allow easy audit during library updates.
During the minification step, a map file is created to allow easier debugging.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Previously jQuery UI was an emeritus (unsupported) project. However, it recently began receiving support again. Therefore, Drupal core has replaced its fork of jQuery UI with jQuery UI itself, to make it easier to keep it up to date. Additionally, core's jQuery UI package dependencies have been updated to jQuery UI 1.13.1. The unminified source code is kept in core to allow easy audit during future library updates.
| Comment | File | Size | Author |
|---|---|---|---|
| #34 | 3265652-34-d94.patch | 543.58 KB | bnjmnm |
| #34 | 3265652-34-d10.patch | 534.09 KB | bnjmnm |
Issue fork drupal-3265652
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3265652-unfork-jquery-ui
changes, plain diff MR !1866
Comments
Comment #2
nod_All right here is a patch that use the vendor-update system to copy the source files to the assets/vendor/jquery-ui directory. essentially unforking the code.
This also takes care of updating the libraries.yml version whenever we update the jquery ui package.
Comment #3
nod_This is where the magic happens.
Comment #4
xjmCool, I guess #3241514: Update jquery ui to 1.13.1 can be closed as duplicate?
Comment #5
lauriiiThank you @nod_! Can we remove
build:jqueryuicommand?Comment #6
nod_kinda different scope I'd say. Ideally we do this one after the other.
I want to remove the copy/paste of the source file so we keep only the minified versions of the JS files in the vendor/assets/jquery.ui folder
Comment #7
nod_Sorry crosspost my reply was to xjm. Yes removing that was the plan
Comment #8
lauriii#6: Not sure it makes sense to do #3241514: Update jquery ui to 1.13.1 separately since it's a complex issue to review since it's a lot of updates for our forked code without test coverage. We also can't do a version of this that would use 1.12.1 because we have changed the forked code to fix security vulnerabilities fixed by 1.13.0.
Comment #9
xjmComment #10
lauriiiIf we remove the source files, is there a way for us to get source maps?
Comment #12
wim leersNot sure what this means exactly … and seems like there's a word missing or something like that in this comment, making it hard to parse? 🤓
Out of scope (and unintentional) change?
Comment #13
nod_removing the comment was on purpose, it's not accurate anymore we don't aggregate the translations files :)
So here i'm using jquery 1.12.1 (unpatched!) to avoid having a huge diff in the patch.
Made some significant refactor to the vendor-update code, we can now define a callback that transforms a file content and file name during the copying. I don't want to add anymore features to this vendor-update thing because at some point it makes more sense to just use webpack or something.
This patch should be green. I'll add a few more patches with interdiffs to eventually remove all unminified files from the jquery.ui asset folder, adding a sourcemap to the files, removing the build:jqueryui command and commit checks.
Comment #14
nod_Comment #16
nod_was faster than expected. Latest code is 1.13.1 version with the build step removed, sourcemap info inlined, using vendor-upgrade
Comment #17
wim leersBut that's not being changed here, in this issue, right? Let's move that to a separate issue with a simple patch that can be committed to all 3 branches swiftly and painlessly? :)
Comment #18
xjmI think if we can review the source maps when they are and define a process for that, that will work.
@nod_ brought up today whether it is safe to remove the non-minified source files in a minor release. It's a somewhat disruptive change from a core contribution process, but I think it is safe in a minor because the sources are internal API. Folks should be using the libraries as the API, and even if they were referencing files, they would be using the minified ones.
I'll get other opinions on this but I think it's minor-safe. (I haven't actually reviewed the diff, just thinking about it at a high level.)
Comment #19
xjmComment #20
nod_I would think that all the code review would happen on the jquery-ui repo/release notes. We don't review the changes to the source files in our repo for most of our other assets such as ckeditor*, js-cookie, pooperjs, shepherd, sortable, tabbable, etc.
Comment #21
xjm@nod_, mainly it is about built assets. We are building our own assets for jQuery UI because they don't ship the individual libraries independently. That's still the case, right? So it's valuable to be able to do reviews of readable versions of the diffs from a security perspective.
Comment #22
nod_Updated the code so that we have the source file, the minified file and a separate sourcemap to avoid bloating the minified file.
Comment #23
lauriiiWould it be possible to update the issue summary on what is the proposed solution? I see that the source files were added back to the MR but I don't understand why do we need those on top of the source maps.
Comment #24
nod_That was after a discussion with xjm. We don't have the source file for poperjs, etc. because they don't ship an unminified production version in their package. We have the unminified source for jquery, backbone, jquery form, jquery once, once. I guess the only other that jscookie and underscore would be libs we could also add the unminified source since they're available.
From what I understood, we're keeping the source for audit purposes during updates when we can, which is a different concern than having a map file available for debugging. Map files are not very suited for code audits during updates.
Comment #25
nod_Comment #26
nod_added a change notice
Comment #27
lauriiiEpic work here @nod_! I think the overall approach is sound and the changes to the build tools look good ✨
Moving to RTBC but we still need a draft release note at least for the jQuery UI version update before we can 🛳.
Comment #28
gábor hojtsyAdded this release note snippet to the issue summary, feel free to tweak as needed.
Comment #29
nod_Thanks! just corrected the version number, it's 1.13.1
Comment #30
gábor hojtsyAh, correct, I was looking at the patch not the MR, sorry.
Comment #31
xjmTest failure looks like a 500 error from chromedriver which could have been the testbot dying, so requeuing.
Comment #32
xjmHiding the patches for IS clarity.
Comment #34
bnjmnmComment #38
bnjmnmAside from being a clever way to add jQuery UI, this also includes refactoring that makes the vendor-update process easier to understand and maintain. My manual review included confirming source maps work properly and there are no load order conflicts resulting from the changes in jQuery UI 1.13.1.
Added to 10.0.x, 9.4.x. Ported to 9.3.x since the jQuery UI 1.13.1 update is needed, and the modifications to the vendor-update process is not disruptive.
Comment #41
xjmComment #42
xjmComment #43
xjmWe can actually skip the 9.4 notes since 9.3.10 shipped before 9.4.0-alpha1.