Backporting util/types, path/posix and path/win32 to v15 proposal

[ExE-Boss]

Is your feature request related to a problem? Please describe.

I’d like to get #34055 and #34962 backported to v15.x.

---

Note that no backport PRs exist yet, and the above PRs were only merged into v16.0.

Describe the solution you'd like

I propose the following options:

1. Backport util: add util/types alias module #34055 and path: add path/posix and path/win32 alias modules #34962 as‑is to v15, which, as an odd numbered release, is considered an unstable non‑LTS release, and thus some minor breakage might be somewhat acceptable for it.

2. Backport util: add util/types alias module #34055 and path: add path/posix and path/win32 alias modules #34962 to v15, but restrict them to the node: scheme until v16, with the following sub‑options:

   1. Add support for require("node:<built‑in‑id>") and thus require("node:util/types"), require("node:path/posix") and require("node:path/win32"). (see also: Add support for node:‑prefixed imports of built‑in modules to require(…) #36098)

   2. Don’t add support for require("node:<built‑in‑id>"), thus only supporting import("node:util/types"), import("node:path/posix") and import("node:path/win32"), but not require("node:util/types"), require("node:path/posix") and require("node:path/win32")

[aduh95]

v15, which, as an odd numbered release, is considered an unstable non‑LTS release

I don't think that's true, v15 should not be considered unstable – the odd numbered release rule was in place in the early days of Node.js 0.x IIRC, nowdays Node.js follows semver for the most part. Stability should not be the focus anyway, breaking changes have been landed on even numbered releases too (E.G.: #27417 landed in v12.2.0).

Correct me if I'm wrong, the PR at stake here are not introducing breaking changes, but they do add a new core module which is the reason they got labeled semver-major (based on discussion around #34055 (comment)).

Here's what I could find in the docs regarding the add of a new modules in core:

node/doc/guides/collaborator-guide.md

Lines 328 to 346 in 7083425

	### Introducing new modules
	Treat commits that introduce new core modules with extra care.
	Check if the module's name conflicts with an existing ecosystem module. If it
	does, choose a different name unless the module owner has agreed in writing to
	transfer it.
	If the new module name is free, register a placeholder in the module registry as
	soon as possible. Link to the pull request that introduces the new core module
	in the placeholder's `README`.
	For pull requests introducing new core modules:
	* Allow at least one week for review.
	* Land only after sign-off from at least two TSC members.
	* Land with a [Stability Index][] of Experimental. The module must remain
	Experimental until a semver-major release.

Nothing here stipulates the PR MUST be considered as semver-major, I'd say it SHOULD land as semver-minor in v15 because:

• the new core modules are not "top-level", they uses already-reserved names (path and util).
• both PRs checks all the points in the above policy (well, maybe it would require a backport PR adding the experimental status first).

[ljharb]

util/types luckily doesn't conflict with https://unpkg.com/browse/util@0.12.3/, the browserify shim for util. path/posix and path/win32luckily do not conflict with https://unpkg.com/browse/path@0.12.7/ either. In general though, there's no such thing as a "reserved name" when it comes to appending file paths on the end.

There's still the chance someone in an enterprise app has named a private package, or manually added a dir, that conflicts with these module names - obviously it's exceedingly unlikely.

If it's decided to backport them, I can ensure that resolve resolves them properly prior to the release PR landing, so CIGTM can pass.

[Trott]

@nodejs/tsc @nodejs/releasers @nodejs/modules-active-members

[Trott]

Just in case I'm not at the TSC meeting: I'm in favor of backporting these changes to the 15.x line.

[targos]

Is there anyone against that?

[mhdawson]

+1 from me.

[ExE-Boss]

@mhdawson
This shouldn’t be closed yet, as #34055 and #34962 haven’t yet been backported to v15.x.

[targos]

I removed the semver-major label from those PRs. They'll be picked up automatically when the next release is prepared.

[ljharb]

@targos is this a general policy change about new core modules being semver-major? Or were those two PRs included in the one-off decision about the diagnostics module?

[mhdawson]

@ExE-Boss k, thanks I will remove from the TSC agenda instead

[ExE-Boss]

This has now shipped in v15.3.0 (#34055).

Follow‑up work to add support for node:‑prefixed imports to require(…) is being tracked in #36098.