[v14.x] stream: runtime deprecate Transform._transformState

[ronag]

stream: runtime deprecate Transform._transformState

Transform._transformState is removed in future version as part of a refactoring.

Refs: #32763
Refs: #33105 (comment)

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

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

[jasnell]

@nodejs/releasers @nodejs/tsc ... This is one that the TSC will definitely need to weigh in on. Semver-major PR #32763 landed recently but not in 14.x. It removed the _transformState property off the stream.Transform object without a deprecation. Strictly speaking it is private API but it's been around for so long, and it has been publicly accessible for so long, that it would ideally go through a runtime deprecation. However, since runtime deprecations are technically semver-major and 14.0.0 has already been released, we would need to make an exception to land this runtime deprecation in 14.x.

[lpinca]

Should we add a test?

[ronag]

Should we add a test?

Do we do that for runtime deprecations?

[lpinca]

I don't remember or I wouldn't have asked 😄

[lpinca]

No, it looks like it is not needed fe069cc

[jasnell]

LGTM but we need to make sure there are no objections from rest of @nodejs/tsc before landing.

[Trott]

LGTM but we need to make sure there are no objections from rest of @nodejs/tsc before landing.

In effect, this is true, but as a clarification (because I think this will still come as a surprise to some TSC members):

This is not the TSC's decision to make anymore. It once was, but for well over a year now, It has been the Release WG's decision. In the Release WG's charter, the TSC specifically delegated determining the contents of a release to them. The TSC cannot override their authority on this. The TSC would need to de-charter the Release WG to overrule the Release WG's decisions.

That said, as far as I am aware, in the very few instances where this sort of thing has come up, the Release WG has always sought guidance from TSC on these sorts of things and basically asks the TSC to make the decision.

So, in effect, it is a TSC decision. But only because the Release WG has been reluctant to make the decision and explicitly defers to TSC.

There used to be a sentence in the Collaborators Guide indicating that the TSC needed to approve landing a breaking change in the Current branch, but it was removed over a year ago to remove the contradiction between the Release WG charter and the Collaborators Guide.

[Trott]

If it helps for TSC folks to be explicit about where they stand on this one:

I have no opinion as to whether this should land now or wait for 15.x. Either is fine by me, assuming Release WG is OK with it.

[ronag]

This is waiting for TSC guidance.

[mcollina]

lgtm for the added deprecation

[BridgeAR]

I abstain.

@nodejs/releasers PTAL

[BethGriggs]

No objections - I'm okay with this change landing in v14.x.

[codebytere]

@ronag could you please rebase this?

[ronag]

rebased

[codebytere]

@ronag i think the rebase went a little sideways haha - once more and we should be good :)

[ronag]

@codebytere PTAL

[codebytere]

Landed in db2d1ca