process,doc: add missing deprecation code

[cjihrig]

Refs: #36902

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/35768/

[aduh95]

Fast-track?

[aduh95]

Landed in 4e833b6

[jasnell]

Arg... thanks. I keep forgetting that the git node tooling doesn't catch these. It does make me wonder if it could tho...

[cjihrig]

It does make me wonder if it could tho...

node/Makefile

Lines 933 to 937 in c9992a0

	@if [ "$(DISTTYPE)"="release" ] &&\
	`grep -q DEP...X doc/api/deprecations.md`;then\
	echo'Please update DEP...X in doc/api/deprecations.md (See doc/guides/releases.md)';\
	exit 1 ;\
	fi

I imagine it just needs something like this.

[aduh95]

Arg... thanks. I keep forgetting that the git node tooling doesn't catch these. It does make me wonder if it could tho...

Or maybe we could stop using DEPXXXX and put the actual deprecation code in the original PR… I tried to do that in #33433 but that didn't land.

[richardlau]

Arg... thanks. I keep forgetting that the git node tooling doesn't catch these. It does make me wonder if it could tho...

nodejs/node-core-utils#420 was supposed to detect these.

[jasnell]

Or maybe we could stop using DEPXXXX and put the actual deprecation code in the original PR… I tried to do that in #33433 but that didn't land.

Key challenge with that is maintaining the order on landing (e.g. if I open a semver-major deprecation PR today that takes three months to land, but three other semver-minor doc only deprecations happen in the meantime... which has happened before).

The one thing we could do is move away from numbered deprecation codes at all and move to a non-numeric code, e.g. DEPWHATEVER but it can be difficult to come up with good names so we'd likely just be trading one problem for another.

[aduh95]

Key challenge with that is maintaining the order on landing (e.g. if I open a semver-major deprecation PR today that takes three months to land, but three other semver-minor doc only deprecations happen in the meantime... which has happened before).

My experience with PR for deprecation that stay open for a long time is that deprecations that are added in the mean time always create a git conflict anyway. So the PR author has to rebase to fix the git conflict, they may as well update the deprecation code. If you add to that a lint rule which would pick up duplicate deprecation codes, I think we would have a way better system that we have now.