Suggestion

Splitting out of#7923 (comment): we're finding it rather inconvenient to have to work withyarn patch to apply our patches to TypeScript's.d.ts file.

For context, we want to enforce a few somewhat-specific-to-use ways of using TypeScript:

• Adding in removed fields as@deprecated optionals for backwards compatibility
• @deprecating fields not present in all our supported versions

Example patch:https://github.com/typescript-eslint/typescript-eslint/blob/8ec3800d6c4eef078ec20b5434805e731242a49d/.yarn/patches/typescript-npm-5.3.0-beta-33b1e90865.patch

Unfortunately, Yarn patching presents a couple inconveniences:

• [Bug] runningpatch-commit for a package that has a builtin patch fails yarnpkg/berry#4441 gets in the way (though does not seem to fully block) patching TypeScript.
• Even ignoring ☝️, we have to manually re-apply patches every time there's a new TypeScript that changes the hash of the file. Ugh.

I'd rather we did something less getting-in-the-way-of-tooling / needing-manual-work-every-TS-version-change, such as declaration merging and/or linting.