Test package versions of default scripts match package.json

[peterwilsoncc]

The following dependencies included via NPM are registered in wp_default_scripts() rather than wp_default_packages_vendor() are they are not stored in the standard location for vendor files for back-compat reasons.

• backbone
• clipboard
• hoverintent-js (the vanilla JS version)
• imagesloaded
• jquery-core
• jquery-color
• jquery-form
• hoverintent (the jquery version)
• masonry
• underscore

These currently lack tests to ensure the version registered in WordPress matches the version listed in the package.json file. This ticket is to add tests for that as they've been known to fall out of sync.

Adds tests to confirm the registered version number of the following scripts matches the version in package.json

• backbone
• clipboard
• hoverintent-js (the vanilla JS version)
• imagesloaded
• jquery-core
• jquery-color
• jquery-form
• hoverintent (the jquery version)
• masonry
• underscore

[peterwilsoncc]

While working on the PR for this, it appears that some of the scripts included via wp_default_packages_vendor() are also missing similar tests. Some of the naming conventions differ but it would be good to add:

• tests for the existing scripts
• a test the tests test to ensure that when scripts added to package.json, they are also added to the tests

[jorbin]

Test looks good, It seems like these are the ones that are missing:

all of the @wordpress scripts
core-js-url-browser
element-closest
es-module-shims1
formdata-polyfill
json2php
objectFitPolyfill
polyfill-library
wicg-inert
whatwg-fetch

I think for the test of tests to ensure testing we could combine the two data providers and then make sure that everything that's not a @wordpress package is covered.

[peterwilsoncc]

I've updated the tests in the ​linked pull request to validate all of the scripts included via package.json except for the @wordpress/ scripts and the following:

• json2php is used by grunt but not enqueued, so left out
• element-closest uses a range rather than precise version number, ^3.0.2 -- @desrosj is this intentional
• wp-polyfill -- unsure where the version number comes from so have left out

[jorbin]

I think we should make element-closest use a precise number. It was originally set to the range in [43719] when it was first introduced. Everything added at that time used a range so it feels like an artifact rather than intentional.

[peterwilsoncc]

Replying to jorbin:

I think we should make element-closest use a precise number. It was originally set to the range in [43719] when it was first introduced. Everything added at that time used a range so it feels like an artifact rather than intentional.

I've updated this in the linked pull request after confirming the value used in the package-lock file.

I've also pushed a test the tests test to test the dataprovider used for the version test is maintained.

[peterwilsoncc]

In 59071:

External Libraries: Test registered script versions match package.json.

Expands tests to ensure the version number of packages updated via NPM matches the version number used for registering the script in the script loader.

This adds tests for (by their registered name in WordPress):

• backbone
• clipboard
• hoverIntent
• hoverintent-js
• imagesloaded
• jquery-color
• jquery-core
• jquery-form
• masonry
• react-jsx-runtime
• underscore
• wp-polyfill-dom-rect
• wp-polyfill-element-closest
• wp-polyfill-fetch
• wp-polyfill-formdata
• wp-polyfill-inert
• wp-polyfill-node-contains
• wp-polyfill-object-fit
• wp-polyfill-url

This expands on the earlier tests introduced for:

• lodash
• moment
• react
• react-dom
• regenerator-runtime

An additional test is added to ensure that the data provider for these tests is maintained as libraries are added via package.json.

@wordpress/* scripts are excluded from these tests as wp-scripts generates a version number automatically based on the file's contents.

Additionally, the version of element-closest listed in package.json is updated to use a fixed version rather than a range. This reflects the current practice of WordPress to define the specific version in core. For the avoidance of doubt, this does not affect the version shipped in WordPress.

Follow up to [57185].

Props peterwilsoncc, jorbin.
Fixes #61855.

Merged 59071 / ​https://github.com/WordPress/wordpress-develop/commit/d46067a77628797897a8c853fabbefc4cc2b1790