Speed up type checking by explicitly annotating some type parameter variances

[akaltar]

Why

In certain cases, type inference could be slow and reach typescript depth limits. Eg #3214

How

By using typescript performance tracing on some examples from the above issue, I've manged to track down the slowness to checking the variances of various type parameters.
I used TypeSlayer's Type search to find the types where the variance was checked, and using the result data from the performance trace, I filled in the variances.

Since not all types of variance can be marked explicitly, I skipped some of them or added a different specifier. Eg in for bivariant.
I'm not 100% sure if this is correct, but many combinations produced type errors in various places, so based on my current understanding a wrong variance would cause type errors elsewhere.
I'm also not sure if this catches all common occurrences of this issue as I was using very simple examples. I will test for robustness + effectiveness by running the changes through a proprietary project and reporting the results.

I'm also not sure if this is the ideal way to solve this problem, I'd assume that there are other simplifications one could make to the types that would result in the built-in variance checking to get faster, but I couldn't find those and don't know enough about what's slow in the current version to do that

I think this could be a breaking change for some users:

• in some cases the reduced type complexity will surface existing type issues that were too complex to discover before
• In some cases the variants might cause a different breakage in client code => I'm hoping that the tests sufficiently account for this

What

• Change EndpointBuilder from a type alias to an interface
• Add in out or in out variance specifiers to some type properties

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 2ea835e:

Sandbox	Source
@examples-query-react/basic	Configuration
@examples-query-react/advanced	Configuration
@examples-action-listener/counter	Configuration
rtk-esm-cra	Configuration

[netlify]

✅ Deploy Preview for redux-starter-kit-docs ready!

Name	Link
🔨 Latest commit	2ea835e
🔍 Latest deploy log	https://app.netlify.com/projects/redux-starter-kit-docs/deploys/69455f333bbe720008004d8b
😎 Deploy Preview	https://deploy-preview-5168--redux-starter-kit-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[markerikson]

.... huh. wow.

this is already clearly over my head :)

First question is what this does to our existing type-tests, then we can go from there.

Either way, though: regardless of whether this works or not and whether we merge it, thank you for putting in serious investigation time, trying to optimize perf here, and filing this PR!

[markerikson]

well nothing obviously broke :) that's either a very good sign, or a sign that we're not testing things sufficiently :)

@akaltar can you use the PR build to do some revised perf comparisons?

Also, I'd love to see before and after flamegraphs!

[EskiMojo14]

regarding types vs interfaces, see #4467 - we found that usage of interfaces created type portability issues for the types listed.

[akaltar]

Would it be against the project conventions to export a couple of these types? If not, I'll just convert them back to type aliases. Interfaces can have much better caching characteristics according to the TypeScript performance guide, hence why I've changed them, but they might not be strictly necessary for most of the optimizations here to work, so I'll check.

Also while initially developing I was manually keeping the type files in sync, and I was seeing much better results, so I'm doing a couple more passes to see how good I can get it, while also testing in a production app to see more real-world results

[phryneas]

We try not to expose them to userland, as they are not guaranteed to be stable.
One thing that could work would be exposing them like this, maybe that will satisfy the portability requirement?

// index.ts
import {UnportableType} from "./foo"
export declare namespace InternalDoNotUse {
  export {UnportableType}
}

[akaltar]

We try not to expose them to userland, as they are not guaranteed to be stable. One thing that could work would be exposing them like this, maybe that will satisfy the portability requirement?

// index.ts
import {UnportableType} from "./foo"
export declare namespace InternalDoNotUse {
  export {UnportableType}
}

I'd rather try this if it's an acceptable solution, as for example MutationBaseLifecycleApi can't be optimized as a type alias, because it becomes an intersection, which doesn't support explicit variance specifiers.
I'll update my PR with this approach and check if that passes the tests

[akaltar]

Simple example
before:

after:

Complex real-world app:
before:

after:

Sooo that's a bit sad, in the complex app it actually ends up slowing things down. I think my simple example might be too simple or maybe different changes are required. In any case I don't think this PR would be useful to merge in its current state. I'll see if I can find time to test more thoroughly on a real-world project with various changes to see if I can find optimizations that actually help