lib: update punycode to 2.3.0

[anonrig]

Resolving 3rd item on fixing jsdoc references in punycode.

Referencing: #45524 (comment)

cc @Trott

[Trott]

Does the second commit also need to update deprecations.md to change the deprecation from documentation-only to runtime? (And if so, does that make this semver major?)

Other than sorting that out, this looks good to me. Thanks for the follow-through on this.

[anonrig]

Does the second commit also need to update deprecations.md to change the deprecation from documentation-only to runtime? (And if so, does that make this semver major?)

It is already deprecated. I just cherry picked and added the pending-deprecation code to punycode.js due to the changes on the first commit. Nothing changes, the second commit fixes the removal of the warning emit in the first commit.

[Trott]

Does the second commit also need to update deprecations.md to change the deprecation from documentation-only to runtime? (And if so, does that make this semver major?)

It is already deprecated. I just cherry picked and added the pending-deprecation code to punycode.js due to the changes on the first commit. Nothing changes, the second commit fixes the removal of the warning emit in the first commit.

Oh, right, pending deprecation, and we're just refloating the change after updating the library. Yeah, that's fine. Thanks. Sorry for my misunderstanding!

[nodejs-github-bot]

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

[aduh95]

Note that this should probably not be landed using the CQ, otherwise the commit message for 1f683af would have two PR-URL metadata which could break our automations. How do you usually do when we float patch, e.g. on top of V8?

[anonrig]

Note that this should probably not be landed using the CQ, otherwise the commit message for 1f683af would have two PR-URL metadata which could break our automations. How do you usually do when we float patch, e.g. on top of V8?

Should I remove the PR-URL from the description of the commit?

[aduh95]

If you look at how it's done in #46445, all the metadata is stripped from the commit-message. I suggest doing that here as well.

Regarding 9e9129e, we wouldn't want to land this as a separate commit:

node/doc/contributing/pull-requests.md

Lines 540 to 541 in 5af2021

	and the tests, but is still one logical change. All tests should always pass
	when each individual commit lands on one of the `nodejs/node` branches.

Instead, you can use git commit --fixup 097a2806023b5a8498f792eff97e35c04588e04b to add follow up fixup! commit(s) that the CQ can understand and squash into the correct commit without you needing to rebase.

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[tniessen]

I don't have the necessary context here, but for what it's worth, if the third commit is necessary due to the first commit, then the first commit is not self-contained and the third commit should likely be squashed into the first instead.

[anonrig]

@aduh95 @tniessen You're right. I updated the initial commit to include the test changes and force pushed to this branch. Appreciate reviewing it again. Thanks!

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[targos]

If you look at how it's done in #46445, all the metadata is stripped from the commit-message. I suggest doing that here as well.

Not really. deps: silence irrelevant V8 warning is the only commit cherry-picked from main and still has metadata. But you're right, I never land V8 updates with the commit queue and usually only keep the old metadata in cherry-picks.

[nodejs-github-bot]

Landed in d1b29b4...629a8fa