test(versions): Restrict Node versions allowed in JavaScript category

[ExE-Boss]

This ensures that in the JavaScript category, only the Node release that introduced a new V8 version is allowed.

Caveats:

• Node.js v8.5.0 introduced the ‑‑experimental‑modules flag, but didn’t ship a new V8 version, so it has to be special cased.
• Node.js v13.0.0 completed I18n support and introduced experimental support for WeakRefs behind the ‑‑harmony‑weak‑refs flag, but didn’t ship a new V8 version, so it also has to be special cased.

---

I’ve also added the Node versions from #3160.

[queengooborg]

I haven't really looked too deep into this PR, but right off the bat, I can see that this includes some changes that are beyond the scope of the title, such as the addition of Node versions, and code styling changes that have no relevance or alteration in functionality. Can we make sure that we're cherry-picking changes into their own individual PRs?

[freaktechnik]

The inclusion of the node versions was actually requested in #3160 (comment) to be in this change.

[queengooborg]

Huh, that seems odd for them to request. Personally, I would expect two separate PRs -- one for the versions, and one for the test -- to get a better-looking commit log.

Regardless, there are the formatting alterations that I feel should be omitted, both since they don't change the functionality of the program and all the other tests follow along with the existing formatting style. Not that I'm against them in general, but it makes the git blame a little cleaner. 😛

[ExE-Boss]

I haven't really looked too deep into this PR, but right off the bat, I can see that this includes some changes that are beyond the scope of the title, such as the addition of Node versions, and code styling changes that have no relevance or alteration in functionality.

All code changes are required by this, eg. the addition of hasCategorySpecificData is needed to display a better error message for Node versions in the JavaScript category.

Similarly, I don’t want to re‑do the (slightly expensive) getValidBrowserVersions(…) call for every SimpleSupportStatement, so I cache the result at the first moment it’s required.

As for findSupport(…), that has to keep track of the category to allow the Node versions to be restricted in the JavaScript category.

[freaktechnik]

Pretty sure the "code style changes" are a reference to the chalk coloring changes.

[Elchi3]

This is really hard to review as it adds even more complexity to test-versions. I'd prefer if we first think about making test-versions less of a monolithic function and have tests for it. Otherwise, this will need an in-depth reviewing for both the new functionality and to make sure nothing is regressed.

[ddbeck]

Another thought on this: can we break out the new Node.js data itself? #3160 has been blocked on that for some time.

[saschanaz]

I don't think this is always valid, for example Node 14.8.0 didn't introduce a new V8 version but it did enable unflagged top level await. https://nodejs.org/en/blog/release/v14.8.0/

[ddbeck]

This has been open a long time and seems to have never really come up as a data quality issue. Given #4264 (comment), this probably can't be enforced without continuing to monitor for exceptions, too. For both of those reasons, I'm going to close it. Nevertheless, thank you for your effort here!