(Try to) update Sheperd.js to latest major version

Not sure how to best test but the fact you updated and nothing broke is a good thing right?

needs someone to try some of our tours

Some code needs to be removed/updated on our end.

Ah just tested the tour for block layout.

The tour opens but at the bottom and page slowly auto scrolls up. So definitely buggy now.

Reverting patch makes the tour work perfectly again.

Although the parent issue is already tagged as a stable release blocker, I think we're now getting close enough to 10.0.0's scheduled release date, that it's time for the individual issues to also be tagged with that.

That said, per the issue title, the scope of this issue is to "try to" do this, so if we get to a point where we feel we sufficiently tried without succeeding, at that time we can bump this to Drupal 11. But it would be nice to succeed with this prior to 10.0.0's release if we can.

I did some poking around and my findings have me thankful for the (Try to) qualifier.

The Floating UI equivalent of the PopperJS modifier option is middleware.. This middleware requires args that wrapped are by functions exported by Floating UI. For example, an offset middleware:

import {computePosition, offset} from '@floating-ui/dom';


computePosition(referenceEl, floatingEl, {
  middleware: [offset(10)],
});

Notice how that offset() is imported from '@floating-ui/dom'? Core doesn't have a runtime node_modules to pluck that from, and (as far as I can tell), Shepherd does not expose their Floating UI instance outside of the scope it is used in. It's also not available as window.FloatingUIDOM, which is how CDN supplied Floating UI's are provided. I see two options here:

1. work with Shepherd to expose their Floating UI instance in the Shepherd object
3. It looks like we'd either need to work with Shepherd to expose their Floating UI instance, or add Floating UI as a core library and be careful to keep the core and Shepherd Floating UI's on the same version

I don't see either working well for a 10.0 release, but perhaps there's an option 3?

Also, if we need to provide true ['drupalSettings']['tourShepherdConfig'] backwards compatibility so there's a deprecation window, this will likely require a complex shim. I think there might be valid arguments for limiting how much that shim covers, though.

Given #12, I think we're too close to Drupal 10's release to do this for Drupal 10. We're already in the RC phase (and pretty far along in it), and it sounds like this can cause non-trivial disruption, even if it's contained to Tour and rogue modules depending on core/internal.shepherd despite "internal" being in the name.

Let's make this a Drupal 11 blocker, although #12 is not especially encouraging.

For Drupal 11, alternatives to dealing with the challenge of #12 include:

• Remove usage of Shepherd: #3204011: Replace Tour BackboneJS usage with VanillaJS equivalent
• Punt the problem to contrib: #3325445: [Policy] Remove tour module from core

Re: item 1 from #16: Although removing Shepherd is an alternative to keep in mind, the scope of issue mentioned: #3204011: Replace Tour BackboneJS usage with VanillaJS equivalent is an orthogonal concern. That issue is focused on removing Tour's BackboneJS usage which is relatively easy to do but unfortunately would not bring us closer to addressing the issues faced here. It would change how the Shepherd code is invoked, but Shepherd would continue to operate as it currently does.

Isn't this outdated now that Tour is a contrib module? #3442286: Deprecate and remove shepherd.js
https://www.drupal.org/node/3442299

Otherwise please reopen!