Fix: Mongoose slows down performance of VSCode (TSServer) by a lot #1…

[traverse1984]

Addressing issue: Mongoose slows down performance of VSCode (TSServer) by a lot #10349

Changing Schema<any> to Schema<T> in model seems to solve this problem. The other model overload already uses the generic in the schema parameter.

Examples:
Gists show two simple schemas based on the mongoose documentation: https://gist.github.com/traverse1984/ee57740a87374188851b30b4286a47fa

• When the schema has it's document type specified only, VSCode intellisense slows down for the whole project to around 3 seconds.
• When the schema has it's document type and model type specified, the issue does not arise.

Notes:
Without trying to get to grips with the entire set of mongoose typings, it seems that mismatched Schema/Model types cause the slowdown. I believe (but am not certain), that the Schema<any> in the function parameter was causing this to happen, despite the return type being correct. I noted that the Schema interface creates a model with 'any' types, but the defaults for the Model interface generics are {}.

[vkarpov15]

From what I can tell, this PR makes TS slower, not faster. --extendedDiagnostics on with-document.ts from https://gist.github.com/traverse1984/ee57740a87374188851b30b4286a47fa before this change:

Files:                         101
Lines of Library:            28888
Lines of Definitions:        46012
Lines of TypeScript:            31
Lines of JavaScript:             0
Lines of JSON:                   0
Lines of Other:                  0
Nodes of Library:           120787
Nodes of Definitions:       126446
Nodes of TypeScript:           100
Nodes of JavaScript:             0
Nodes of JSON:                   0
Nodes of Other:                  0
Identifiers:                 87417
Symbols:                    185949
Types:                      102252
Instantiations:             265476
Memory used:               200431K
Assignability cache size:    58789
Identity cache size:           125
Subtype cache size:             75
Strict subtype cache size:       0
I/O Read time:               0.01s
Parse time:                  0.80s
ResolveModule time:          0.06s
ResolveTypeReference time:   0.00s
Program time:                0.91s
Bind time:                   0.37s
Check time:                  3.91s
transformTime time:          0.03s
commentTime time:            0.00s
I/O Write time:              0.00s
printTime time:              0.06s
Emit time:                   0.06s
Total time:                  5.26s

After this change:

Files:                         101
Lines of Library:            28888
Lines of Definitions:        46012
Lines of TypeScript:            31
Lines of JavaScript:             0
Lines of JSON:                   0
Lines of Other:                  0
Nodes of Library:           120787
Nodes of Definitions:       126447
Nodes of TypeScript:           100
Nodes of JavaScript:             0
Nodes of JSON:                   0
Nodes of Other:                  0
Identifiers:                 87418
Symbols:                    185719
Types:                      102185
Instantiations:             265355
Memory used:               200925K
Assignability cache size:    58784
Identity cache size:           125
Subtype cache size:              0
Strict subtype cache size:       0
I/O Read time:               0.02s
Parse time:                  0.78s
ResolveModule time:          0.06s
ResolveTypeReference time:   0.01s
Program time:                0.90s
Bind time:                   0.38s
Check time:                  4.05s
transformTime time:          0.04s
commentTime time:            0.01s
I/O Write time:              0.00s
printTime time:              0.07s
Emit time:                   0.07s
Total time:                  5.41s

Furthermore, it breaks our tests because we need to support new Schema<IPerson & Document, Model<IPerson & Document>>() + model<IPerson>() for backwards compat.

Although I'm unable to confirm that this improves performance in any way, I don't see much harm to merging this as long as you can confirm that changing Schema<T> to Schema<T> | Schema<T & Document> still works for you.

[traverse1984]

Schema<T> | Schema<T & Document> has the same in-editor improvement for me as the original change to Schema. It makes sense to me that Schema would be slower on paper, but the performance improvement for me in VSCode is significant. It seems #10349 (comment) confirms this in a different way (by avoiding that definition).

[vkarpov15]

We'll try this out and see if it helps. I honestly haven't been able to confirm the performance degradation by eyeballing VS Code, but I don't see any harm in merging this.

[xhacker5000]

Use yarn` instead of npm ``

And use 5.10.11 version , everything is cool ~