Repo: Consider reworking our package.json typescript resolution

[JoshuaKGoldberg]

Suggestion

Forwarding @octogonz's microsoft/rushstack#4404 (comment) here (thanks again!):

In fact, looking at your branch, I think the whole problem is that your yarn resolutions are producing an incorrect installation of API Extractor:
...
your project has a wrong installation that does not respect the SemVer ranges requested by package.json files. This is most likely caused by the "resolutions" field from the package.json file in your project root folder. In trying to override some versions, those overrides are overreaching and breaking the functionality of dependencies. If you fix that problem, you can use the current API Extractor without any changes.

This is not an area I've looked into deeply, so just posting for the tracker.

[octogonz]

A quick workaround could simply be:

  "resolutions": {
    . . .
    "@microsoft/api-extractor/typescript": "~5.0.3",
    "typescript": "patch:typescript@npm%3A5.3.0-beta#./.yarn/patches/typescript-npm-5.3.0-beta-33b1e90865.patch"
  },

As far as I know Yarn does not support more expressive rewriting such as .pnpmfile.cjs, so you would need to manually adjust the "~5.0.3" string whenever @microsoft/api-extractor gets upgraded.

It's also worth mentioning: If any of these aggressive "resolutions" rules influence the versioning of dependencies of your published packages (any direct OR indirect dependencies, but not 'devDependencies), then the versions being used during development may be different from what real users would encounter when they install the shipped NPM. This can cause bugs to be overlooked during development.

[bradzacher]

The reason we use resolutions is exactly to solve the issue of multiple versions of TS being installed. Early on we ran into multiple issues due to having multiple versions within tests. Because we rely on TS internals it's a big issue for us to have multiple versions!

It has worked fine for the life of the project because the intersection of "dependencies that depend on TS internals" and "TS breaking api changes" has been tiny - this is the first instance of a breakage due to the resolution, I believe.

[JoshuaKGoldberg]

Just following up: this hasn't been an issue in a few months and Brad's comment explains why we have things set up the way they are. Closing out as wontfix. But this can be a good reference as needed. Cheers!