redyetidev

By the way, this PR should be backported to 18 and 20, I'm not sure if the labels I applied are correct.

Thanks @richardlau, I'm new to backporting. For the future, what would be the appropriate labels?

> Possibly `lts-watch-*`, although strictly speaking it shouldn't be necessary for a release line in active LTS (e.g. 20.x). > > Refer to [`main`/doc/contributing/backporting-to-release-lines.md](https://github.com/nodejs/node/blob/main/doc/contributing/backporting-to-release-lines.md?rgh-link-date=2024-05-08T18%3A50%3A11Z) Okay, thanks. Should I add `lts-watch`...

@targos, is there anything in particular I need to do for the backport?

IMO if it's a breaking change it should be semver-minor or notable-change (But as a triage member, this isn't my decision, nor my place)

"Label PRs / label" appears to have crashed, so I manually labeled the PR. @nodejs/actions > GitHub Actions has encountered an internal error when running your job.

@nodejs/documentation Personally, I'm -1 on the change in its current form, but I'm just a triage member, and I'd be curious to see one of your reviews.

Yes, the project tends to try and keep one PR per chance (hence the one commit per change)

I'm on the side that this is more than a single change, and should be split into multiple PRs.

I'm sorry for overstepping, I'll make sure to not sound like a code owner in the future. Sorry for my repeated misunderstandings, I'm trying my best to learn the works...