Closed (fixed)
Project:
Drupal core
Version:
10.0.x-dev
Component:
javascript
Priority:
Critical
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
3 Aug 2022 at 12:16 UTC
Updated:
23 Sep 2022 at 13:09 UTC
Jump to comment: Most recent
Comments
Comment #2
xjmPer @nod_, we also need to file an upstream PR to update Shepherd.js for this change.
Comment #3
nod_shepherd upstream issue opened: https://github.com/shipshapecode/shepherd/issues/2013
Comment #4
nod_upstream PR started.
This can only be a 10.x patch since floating UI uses await/async
Comment #5
catchThis is referred to in a few tests, but just as example-ish content not actual test coverage. We could switch those to floating-ui or just something else entirely:
The only other core usage, apart from via Shepherd, was in quickedit, which is removed from Drupal 10, so that leaves us with swapping around the library definition and updating the assets.
Main question for me then is what do we do about removing the popperjs if this is a 10.x only patch, can we:
1. Backport the floating-ui library to 9.5.x only as a library definition, so that it's available to contrib modules (who are entitled to drop IE11 support before 9.5.x is EOL). We've then got the option to deprecate it for removal in Drupal 10 or 11.
2. Deprecate popperjs in 10.0.0 for removal in 11.0.0, with no 9.5 backport.
3. Remove popperjs from 10.0.0 with no deprecation (not really)
#1 seems better for modules dealing with Drupal 10 compatibility.
Comment #6
nod_I'd say 1. as well, but we might not need to add that library to core at all? if we don't have any use for it I don't see the reason to add a unused library to core?
It's not a drop-in replacement so there will be work on their end, might as well let people install popperjs library on their own and keep their code running. I don't see a need to enforce a rewrite of their code.
Comment #7
catch@nod_ don't we need it for Shepherd though?
Comment #8
nod_it's built in the library. when we use shepherd and popperjs in the same page we essentially load popperjs twice today. see https://github.com/shipshapecode/shepherd/issues/1857
Comment #9
nod_Comment #10
catchOhhhh got it. In that case should we just mark this duplicate of #3307471: Deprecate popperjs?
Comment #12
nod_Let's see what happens if we just remove it.
Guess it's a little different between the two branches?
Comment #13
catchComment #14
nod_Strictly speaking we don't need the shepherd PR given that the use of popperjs is their responsibility and it's built-in the library.
It's good collaboration for open source in general though so I'll still try to make it land and update the tour module to work once it's released.
Comment #15
bnjmnmI think Popper can be taken out of the eslint globals.
That's the only code change I can see being needed. The issue summary also needs updating to reflect the new approach. Popper is a nice library, but it's nice to be able to have fewer dependencies.
Comment #17
spokjeApplied the suggested change by @bnjmnm in #15, back to NR for code review.
Still needs an IS update, but I'm certainly not the JS-guru that can pull that off.
Comment #18
bnjmnmComment #19
bnjmnmComment #20
bnjmnm@Spokje addressed my feedback.
Compared this to the changes in #3307471: Deprecate popperjs and the changes that need to be in both issues are nicely consistent with each other. Also pleased that Spokje spotted that
popperjscould be removed from spellcheck. I'd assumed the Shephard use would keep that needed, but always nice when the dictionary can be reduced a bit.Comment #22
catchCommitted/pushed to 10.1.x and cherry-picked to 10.0.x, thanks!
Comment #23
phenaproximaThis should probably be in the release notes, since it's a removed/deprecated dependency.
I think the current release note could also be a little more detailed. Re-opening for that.
Comment #24
nod_tried to update the release note.
Comment #25
nod_Comment #26
phenaproximaMade a few changes, including an actionable suggestion for people who need the library. ;) Moving this back to fixed. Thanks @nod_!