typings: remove deprecated and unused string methods from primordials

[rayark1]

This Pull Request (PR) aims to clean up the primordials module by removing methods that are deprecated and no longer used within the Node.js codebase. This update follows the latest JavaScript standards and helps to maintain consistency and improve the maintainability of the codebase.

Changes

The following methods have been removed from the primordials.d.ts file:

• StringPrototypeTrimLeft
• StringPrototypeTrimRight
• StringPrototypeSup
• StringPrototypeStrike
• StringPrototypeSub
• StringPrototypeSubstr
• StringPrototypeSmall
• StringPrototypeFontcolor
• StringPrototypeFontsize
• StringPrototypeFixed
• StringPrototypeItalics
• StringPrototypeAnchor
• StringPrototypeBig
• StringPrototypeBlink
• StringPrototypeBold
• RegExpPrototypeCompile

Reasons for Changes

Deprecated Status:

• These methods are deprecated and replaced by more modern and standardized alternatives.
• Examples include trimLeft and trimRight, which are replaced by trimStart and trimEnd respectively.

Codebase Cleanup:

• Removing unused and deprecated methods simplifies the codebase, making it easier to maintain and less error-prone.

Compatibility Issues:

• Deprecated methods may no longer be supported in future versions of JavaScript engines and browsers, potentially causing compatibility issues.

[aduh95]

I don't really get this, those methods exist, I'd expect if someone opens a PR in the future adding them back, that might be accepted; ideally we would not land something that can be reverted immediately. Also, why would we remove those and keep e.g. RegExpPrototypeTest despite we have a lint rule forbidding its use?

[aduh95]

Let's instead mark them as deprecated, keeping the types correct.

Suggested change

	export const RegExpPrototypeCompile: UncurryThis<typeof RegExp.prototype.compile>
	/** @deprecated A legacy feature for browser compatibility **/
	export const RegExpPrototypeCompile: UncurryThis<typeof RegExp.prototype.compile>

[rayark1]

I understand your concerns. I have a few questions based on your feedback @aduh95 :

1. Does Node.js have a process for reviewing and removing deprecated methods in major release cycles?
2. Your idea to mark these methods as deprecated is indeed practical, but eventually, deprecated methods need to be removed. Wouldn’t it be more effective to implement lint rules in the primordials.d.ts file to prevent the addition of deprecated methods?

I would appreciate your thoughts on this.

[aduh95]

Does Node.js have a process for reviewing and removing deprecated methods in major release cycles?

Node.js has a deprecation cycle that's defined in

node/doc/contributing/collaborator-guide.md

Lines 487 to 495 in 27f1306

	A _deprecation cycle_ is a major release during which an API has been in one of
	the three Deprecation levels. Documentation-Only Deprecations can land in a
	minor release. They can not change to a Runtime Deprecation until the next major
	release.
	No API can change to End-of-Life without going through a Runtime Deprecation
	cycle. There is no rule that deprecated code must progress to End-of-Life.
	Documentation-Only and Runtime Deprecations can remain in place for an unlimited
	duration.

However, the methods you list in the OP do not apply, because:

• they are not Node.js APIs, they are defined by the ECMAScript spec and implemented by V8.
• they are not deprecated by us.
• the file you're modifying is only used for internal development, and deprecation only apply to public APIs.

eventually, deprecated methods need to be removed

I don't think that's correct, a deprecated feature can stay around forever.

Wouldn’t it be more effective to implement lint rules in the primordials.d.ts file to prevent the addition of deprecated methods?

I very much doubt so, regardless if those methods are defined in primordials.d.ts, they exist, and therefor can be used in .js files. If you do add @deprecated flag to them, IMO that would be more effective because folks who use an IDE with TS support would see those methods as underlined if they try to use it – if you remove it, it would only remove the autocompletion and the documentation.

[targos]

Another option is to actually delete these methods (or not add them in the first place) from the primordials object. Then it would be correct to remove the typings.

[joyeecheung]

I'd expect if someone opens a PR in the future adding them back, that might be accepted

From a look of the list it doesn't seem likely that we'll accept a PR that actually makes use of the deprecated methods, so I guess we should just...not accept a PR that adds them to the types files?

Also, why would we remove those and keep e.g. RegExpPrototypeTest despite we have a lint rule forbidding its use?

We do have existing usage of RegExpPrototypeTest to avoid performance regressions of RegExpPrototypeExec and silence the linter with eslint-disable comments. Also there isn't anything terribly wrong with RegExpPrototypeTest, it's only forbidden to avoid prototype pollution which is something that we have agreed can be sacrificed for better performance - if anything we probably want more exceptions of this in performance-sensitive paths. The same can't really be said for the deprecated methods here (it's hard to think why we would want to make an exception to use any of these deprecated methods that have better alternatives).