feat(semver-major): Upgrade package to Node.js v23

[avivkeller]

Ref: https://github.com/nodejs/admin/issues/928

This PR introduces a major upgrade to the package, adding support for Node.js v23 features. Please note that the minimum required Node.js version is now v18, which was used for all testing.

The update includes most of the new features in v23, with the following exceptions:

• Importing reporters or custom modules from node_modules located outside the test module's directory
• Setting global hooks using --require or --import when process isolation is disabled and multiple files need to be executed
• Code coverage support
• File watching capabilities
• Module mocking functionality
• Source map caching

[aduh95]

This PR is hard to review without knowing what process did you follow and understanding the motivations behind the choices that were made.

[avivkeller]

Sorry if this is difficult to review! A breakdown of my thought process is as follows:

When updating the library, there was the primary goal of adding as many v23 features that could be backported to this version easily. Along with this goal, a secondary goal was to modify as little source code as possible (E.G. the files in lib/internal/test_runner/ that are directly from the core repository).

With that in mind, the instances where code absolutely had to be modified are denoted with /* NOTE(RedYetiDev): ... */ comments.

Additionally, I understood the following limitations

• Without access to the internal inspector bindings, code coverage was not possible (and therefore source maps aren't really needed)
• Without access to the internal libuv bindings associated with the FileWatcher class, file watching was not possible
• Without access to the module loader, module mocks would not be possible, nor modules imported as --test-reporter, among other things.
• In order to make use of the CLI flags that are not allowed on v18, they would have to be passed after the fiile, therefore, process.argv and process.execArgv are both checked.

Anything else you want to know?

[bnb]

(Edit by @RedYetiDev: I accidentally removed the content of this comment, re-added)

I think landing this is good as a way to get close to catching up, but ideally there would be 1:1 parity between the package and the core module - it should be a drop in replacement.

IMO, testing shouldn't be using core modules - we should only be using things that are available to the ecosystem. If there's something that's useful for testing that we want to hook into in core, we should find ways to expose those APIs.

[avivkeller]

IMO, testing shouldn't be using core modules - we should only be using things that are available to the ecosystem. If there's something that's useful for testing that we want to hook into in core, we should find ways to expose those APIs.

I highly disagree with this. The test runner should make use of core modules, it's a builtin for a reason. Users who do not wish for this behavior can use alternative libraries, such as Mocha.

As for the builtin, using internal modules allows for it to use a wide-range of features not typically exposed to userland, and it can access (if needed) the CPP builtins that are the backbone of Node.js.