Refactor (if feasible) uses of the jQuery closest function to use Vanilla/native

Can someone look into the MR and confirm why Tests Pipelines are failing. Seems like few test cases are failing but not sure why

Changes seems fine in the MR

But moving to NW for the eslint rule change.

Left a comment.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

havent' finished but it'll need more work

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Appears to have javascript test failures.

Fixed tests.

Still needs subsystem thumbs up believe

But applied the MR and did some light testing of checking random features (views, layout builder popups, etc) and didn't notice anything.
The 2 threads appear to be addressed (I believe)

So to keep from stalling going to mark as tests are also showing fine.

First of all thank you all for the hard work on this one, I've had to push a number of patches like this and I know how hard it is to keep up.

I'm going to try and refocus the jQuery removal work and to do that I need to take a few decisions. I'm going to close this issue for a few reasons:

• This MR is big, it impact a very big number of subsystems and make the code more brittle. jQuery is good at dealing with undefined elements, empty sets and so on, the DOM isn't. We already had regressions from a previous patch with undefined elements
• The MR is too big to review and make sure there are no regressions (even with the tests we already have), it would create unstability that we don't have to endure
• Sometimes the jQuery code is simply more readable, I do not think this change is a net positive:
  

        $(once('filter-guidelines', '.js-filter-guidelines', context))
          .find(':header')
          .hide()
          .closest('.js-filter-wrapper')
          .find('select.js-filter-list')
          .on('change.filterGuidelines', updateFilterGuidelines)
          // Need to trigger the namespaced event to avoid triggering formUpdated
          // when initializing the select.
          .trigger('change.filterGuidelines');
        // Define the closest function for finding the closest ancestor with a given selector
        function closest(element, selector) {
          while (element && !element.matches(selector)) {
            element = element.parentNode;
          }
          return element;
        }
  
        const contextElement = document.querySelector('.js-filter-guidelines');
        const closestWrapper = closest(contextElement, '.js-filter-wrapper');
        if (closestWrapper) {
          const $context = $(contextElement);
          const selectElement = $(closestWrapper).find('select.js-filter-list');
          $context.find(':header').hide();
          selectElement
            .on('change.filterGuidelines', updateFilterGuidelines)
            // Need to trigger the namespaced event to avoid triggering formUpdated
            // when initializing the select.
            .trigger('change.filterGuidelines');
        }
  

  There is one line to change and we have to make many, many other changes for this to work

I ported the credits to #3464044: Credit for work on the reduce jQuery issues, which I will mark as fixed as soon as I go through all the others impacted jQuery issues.