Update the `element-closest` polyfill

[desrosj]

The element-closest dependency is a polyfill used for the block editor. A new version is available so this should be updated.

What's not immediately clear is what this polyfill is used for and if it's still required. It's ​in the Gutenberg documentation, but is not defined as a dependency within that repository (most likely because it has been in Core for some time).

The update has relatively minor changes, but confirming that the areas of Core relying on this polyfill continue to work properly would be a good step to take.

Currently, version 2.0.2 is bundled with Core. The latest is now ​v3.0.2.

A full list of changes can be found on GitHub: ​https://github.com/jonathantneal/closest/blob/master/CHANGELOG.md#302-october-31-2019

[Hareesh Pillai]

Patch looks good and the QUnit tests have all passed. Based on my testing of a few areas that use .closest, it seems to work fine.

I suggest that we commit this patch so that we could catch any edge cases.

[desrosj]

52851.2.diff​ is just a refresh to apply to trunk cleanly.

I was looking at this again today. It seems that the name of the file in the package has changed. Previously, the package contained an element-closest.js file that was used in the Webpack build process.

In the latest release, it seems that browser.js is the result of a new build process and is meant to replace this file. However, the file is also minified. Core currently has an expanded and minified version of wp-polyfill-element-closest.js, so this will need to be addressed in the build process.

[gziolo]

As far as I can tell we should be able to use one of the unminified files:

• ​https://unpkg.com/browse/element-closest@3.0.2/index.js (Common JS)
• ​https://unpkg.com/browse/element-closest@3.0.2/index.mjs (ESM)

So we should need to update references in both vendors and minifiedVendors.

[desrosj]

This is not mission critical, and I have not had a chance to revisit this.

Going to punt.

[desrosj]

Would be nice to wrap this up in 6.2. The library has not been updated since 2019, so 3.x is likely the last version.

Trac ticket: https://core.trac.wordpress.org/ticket/52851

@desrosj Some how the map file is not copied from node_modules folder.

[mukesh27]

This ticket was discussed in the recent bug scrub.

Thanks @desrosj for the ticket and PR.

The tests on PR going fails do you have moment to take a look? We have beta in few week.

Props to @costdev

@desrosj Some how the map file is not copied from node_modules folder.

To be clear, the map file not being copied over is the correct behavior. This error is happening because there is now a //# sourceMappingURL=index.js.map line at the bottom of the unminified index.js file for the package.

[desrosj]

I've gone and refreshed the PR against the current state of trunk.

Thinking about this more, I'm leaning towards just using the minified version of the package in both versions of the file created.

It's not used in Core anymore and is only maintained as a courtesy and to prevent 404 errors if being loaded directly. Additionally, ​there's almost no real world usage of this polyfill according to a search of the plugin library.

I've also included this change in the PR. If this seems like the right route, I'll get it committed for 6.2. Otherwise we should just maybelater this one as there's really very little benefit.

[desrosj]

In 55275:

External Libraries: Update element-closest.

This updates the element-closest polyfill to the latest version, 3.0.2.

Because of changes to how the package is now built and distributed, both files for the library now contain minified code.

This library is no longer used by Core itself and maintained as a courtesy. Any projects utilizing it should reevaluate their usage requirements with modern browsers.

Props hareesh-pillai, gziolo, mukesh27, costdev.
Fixes #52851.

Merged in https://core.trac.wordpress.org/changeset/55275.