Upgrade for node v18

[igorschoester]

Context

Node LTS compatibility is the goal.
Not only that, but also adding some structure to have the code as source of truth for future version changes. The idea is that this will make it easier to test and thus upgrade further.
Added bonus is us streamlining the version we use locally to also be used in our CI and releasing.

Summary

This PR can be summarized in the following changelog entry:

• Upgrades @wordpress/scripts and @wordpress/dependency-extraction-webpack-plugin, for their compatibility with Node v18.
• Updates the MiniCssExtractPlugin usage in our Webpack configuration, not being removed from default config and updating to passing a relative path. This was needed after the upgrade of WP scripts.
• Bumps Node version to 18 in .nvmrc, and use that in our GH-actions.
• Adds a VERSIONS.json file that holds information about our used versions for Composer, Node, PHP and Yarn. Though Composer and PHP are the only ones currently read from. Node and Yarn are specified in .nvmrc and .yarnrc, respectively.
• [@yoast/browserslist-config 0.0.1] Adds the missing Jest development dependency.
• [@yoast/ui-library 0.0.1] Adds a tooling workaround to get Webpack 4 to build the storybook in Node 17+.
• [yoastseo 0.0.1] Adds a ESLint ignore rule to trigger the tests in the CI.

Relevant technical choices:

• Keeping .nvmrc as source of truth for the Node version as that syncs up with development.
• Keeping .yarnrc as source of truth for the Yarn version, because that is how Yarn enforces it (it turns out the brief Yarn upgrade did not work in the first place).
• The VERSIONS.json is an implementation from our Devops that was used in our platform already. It is currently implemented on a test branch of our CI. And currently has a test path in there to pull in this branch, for testing purposes.
• Note on why 18 and not 20: I previously ran into UI library build & test problems. I falsely concluded that was a problem with Node 20. Turns out this was a Node 17+ problem. However, I never switched back to Node 20 after that. I think it is okay to continue this path with Node 18 for now. I think there is a benefit in confirming it works in both versions. Making Node 20 a future iteration.
• Note: the NODE_OPTIONS for the UI library makes it no longer build with Node version < 17. As that flag is not accepted and an error is thrown instead. Meaning developers and our tooling has to be on Node version > 16.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

Locally [devs only]

• Install Node v18 (lts/hydrogen)
• Yarn install
• Build the plugin
• Run the tests
• Smoke test the plugin (Edit post/taxonomy, check settings, etc)

PR build

• Verify the PR build passed (GitHub actions)

RC/Release

Arnoud made a branch on our CI that pulls in this branch and reads from VERSIONS.json. This makes it so we can run the PRE/test versions of our RC and release scripts on this branch.

• Verify the release script was successful
  • The fake release build: https://ci.yoast.com/view/Plugin-View/job/Plugin-Release/view/All/job/X-free-TEST/163/
  • The fake release result: https://github.com/Yoast/experimental-releases/releases/tag/21.9
• Download the artifact and smoke test it

UI library Storybook [devs only]

• Start the UI library storybook (yarn workspace @yoast/ui-library storybook)
• Smoke test it by clicking through a bit

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Block/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

QA can test this PR by following these steps:

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

• The JavaScript tooling, meaning building our plugin should be thoroughly checked. But if building successfully, I don't expect the result to have a high chance of failure. Hence the only smoke testing.

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Other environments

• This PR also affects Shopify. I have added a changelog entry starting with [shopify-seo], added test instructions for Shopify and attached the Shopify label to this PR.

Documentation

• I have written documentation for this change.

Quality assurance

• I have tested this code to the best of my abilities.
• During testing, I had activated all plugins that Yoast SEO provides integrations for.
• I have added unit tests to verify the code works as intended.
• If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.
• I have written this PR in accordance with my team's definition of done.
• I have checked that the base branch is correctly set.

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label.
• I have added my hours to the WBSO document.

Fixes #19565

[coveralls]

Pull Request Test Coverage Report for Build 1c577ba9c975592063e97de03292c00eea9e6c73

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall first build on igor/try-upgrade-for-node at 56.134%

---

Totals
Change from base Build 9ae37c010550b9cf771819b187db97b995c73acf:	56.1%
Covered Lines:	13479
Relevant Lines:	23606

---

💛 - Coveralls

[enricobattocchi]

@igorschoester running yarn test fails with

> Image snapshot tests › 2) Components/Textarea field › Validation
@yoast/ui-library:     Expected image to be the same size as the snapshot (800x632), but was different (800x634).
@yoast/ui-library:     See diff for details: /home/lopo/src/Yoast/plugin-development-docker/plugins/wordpress-seo/packages/ui-library/tests/__image_snapshots__/__diff_output__/storyshots-js-image-snapshot-tests-2-components-textarea-field-validation-1-diff.png

is it expected?

---

it seems to be happening already on trunk, so it should not be related to this PR.

[enricobattocchi]

Ok for me

[d-claassen]

Looks good to me too! ✅