mongoose: Mongoose slows down performance of VSCode (TSServer) by a lot

Decided to give it one more shot by taking into consideration feedback by @TigranAvagyan18. And I got it to work!

Commands:

npm i mongoose@5.10.19 --save
npm i @types/mongoose@5.10.5 --save

Summary:

• Downgrade to last version before Mongoose’s own TS types
• Install DefinitelyTyped’s Mongoose types.

My existing code worked with these versions without issues. Code completion performance is also back! It feels so good to have the snappy completion back.

As a side note, Mongoose introduced their own types in version 5.11.0 according to this. 5.10.19 was the last version released before that according to this

I will test some more tonight to see if my current code was affected by this downgrade and update this post if I find any.

This really needs a fix… Programming is not possible like this.

Really? For me it slows all content, not just mongoose related…

I can confirm that too.

I was using @types/mongoose before and just removed it in favor of mongoose own type definitions. It was like snapping two fingers, boom, vscode was now super slow. Simple autocompletes and validations are taking now over 5 or even 10 seconds sometimes in all project files.

I can confirm that I am also experiencing a degradation in Typescript performance due to Mongoose.

Mm well I can replicate it with very little:

import { model, Model, Schema } from "mongoose";

export interface UserSH {
    username: string,
    password: string,
    maxMb: number,
    submitted: string[],
    id: string
}

export const UserSchema = new Schema<UserSH, Model<UserSH>, UserSH>({
    id: "string",
    maxMb: "number",
    username: "string",
    submitted: ["string"],
    password: "string"
})


uiyasdjklsadias //error this baby is undefined

The thing that ‘triggers’ it is creating the schema. If I just remove the schema creation, its all good

(the only files in the project are the default ones, mongoose, typescript@4.3.2, and src/index.ts, contents of which are above. Otherwise its newly created)

me too

This issue needs to be addressed urgently, it’s almost impossible to program with a delayed appearing completion menu. On the other hand, it is not my preference to have to downgrade to solve this problem, as I want to keep everything up to date to avoid problems, among others.

We made some changes in a007421 that should help. Before:

$ ./node_modules/.bin/tsc --extendedDiagnostics
Files:                         101
Lines of Library:            28888
Lines of Definitions:        46299
Lines of TypeScript:            24
Lines of JavaScript:             0
Lines of JSON:                   0
Lines of Other:                  0
Nodes of Library:           120787
Nodes of Definitions:       127027
Nodes of TypeScript:            85
Nodes of JavaScript:             0
Nodes of JSON:                   0
Nodes of Other:                  0
Identifiers:                 87606
Symbols:                    189669
Types:                      104538
Instantiations:             281981
Memory used:               201243K
Assignability cache size:    59348
Identity cache size:           127
Subtype cache size:            140
Strict subtype cache size:       0
I/O Read time:               0.01s
Parse time:                  0.67s
ResolveModule time:          0.05s
ResolveTypeReference time:   0.00s
Program time:                0.75s
Bind time:                   0.32s
Check time:                  3.45s
transformTime time:          0.01s
commentTime time:            0.00s
I/O Write time:              0.60s
printTime time:              0.61s
Emit time:                   0.61s
Total time:                  5.13s

After:

$ ./node_modules/.bin/tsc --extendedDiagnostics
Files:                         101
Lines of Library:            28888
Lines of Definitions:        46280
Lines of TypeScript:            24
Lines of JavaScript:             0
Lines of JSON:                   0
Lines of Other:                  0
Nodes of Library:           120787
Nodes of Definitions:       126806
Nodes of TypeScript:            85
Nodes of JavaScript:             0
Nodes of JSON:                   0
Nodes of Other:                  0
Identifiers:                 87527
Symbols:                    147867
Types:                       67077
Instantiations:             216148
Memory used:               172065K
Assignability cache size:    22879
Identity cache size:           124
Subtype cache size:            140
Strict subtype cache size:       0
I/O Read time:               0.01s
Parse time:                  0.59s
ResolveModule time:          0.04s
ResolveTypeReference time:   0.00s
Program time:                0.67s
Bind time:                   0.28s
Check time:                  2.76s
transformTime time:          0.01s
commentTime time:            0.00s
I/O Write time:              0.00s
printTime time:              0.01s
Emit time:                   0.01s
Total time:                  3.72s

20% reduction in check time should go a long way to making VSCode faster.

@andrewbranch has been the TS team member investigating the mongoose types.

We did some more digging and found a big improvement today. For the below script:

import { Schema, Model, model } from "mongoose";
  
interface User {
   name: string;
   email: string;
   avatar?: string;
}

interface UserModel extends Model<User> {
   fetchUser(name: string): Promise<User>;
}

const schema = new Schema<User>({
   name: { type: String, required: true },
   email: { type: String, required: true },
   avatar: String,
});

const User = model<User, UserModel>("User", schema);

With Mongoose 6.1.4, here’s the extended diagnostics output:

Instantiations:             177821
Memory used:               167866K
Check time:                  2.87s
Total time:                  3.96s

With simplifying the Schema class and avoiding using ExtractQueryHelpers and instantiating HydratedDocument in Schema, we get the below output:

Instantiations:              44568
Memory used:               135159K
Check time:                  1.99s
Total time:                  3.11s

There’s some minor upgrade friction in that you now would need to specify TQueryHelpers as a 4th generic to Schema for type checking, but I think the perf improvement is worth it.

@lorand-horvath that’s good news! Might be because we removed some legacy type aliases. One of those types used extends Document in a generic, which is similar to the issue that was fixed by #10515, so I can see that being possible.

I did some more digging, haven’t made much progress. Managed to make a token improvement by removing one of the infer paths in ObtainSchemaGeneric, but that doesn’t make much of a dent. It does seem that infer is necessary here, as @mohammad0-0ahmad indicated, so we’ll have to figure out an alternative approach to make tsc not blow up.

@vkarpov15 I have tested Mongoose 6.0.6 with the latest VSCode 1.60.1 and I am happy to report that the problem of slow intellisense/autocomplete is now completely solved!

For reference, in my controllers.js file, Mongoose 5.13.8 takes about 8 seconds to comment out a line (until it turns green) or for a hint to appear on hover, while one CPU thread is blasting at 100% for an additional few more seconds! Mongoose 5.13.9 is not much better either, it takes anywhere between 5 and 8 seconds, I’m not sure what made it a bit faster (occasionally). Perhaps some related dependencies have been upgraded when I upgraded from 5.13.8 to 5.13.9, I’m not really sure. Mongoose 6.0.6, on the other hand, takes about 1 second to do that and the CPU settles down soon afterwards - big difference in behavior.

So thank you for fixing this annoying issue and sorry for nagging at you because of it.

Update I tried some of the mongoose version installing, checking performance & 🔁 mongoose -v

• @5.11.10 works with seconds of delay 1 critical severity vulnerability
• @5.12.0 works perfectly but with 1 critical severity vulnerability
• @5.12.10 same issue slow loading
• @5.13.0 same issue slow loading
• @5.13.5 same issue slow loading
• @6.0.0 works fine but with 1 critical vulnerabilities
• @6.0.10 slow down TS/JS performance
• @6.0.5 🥇 work awesome with 0 vulnerabilities ✔️

I’ve just tested Mongoose 6.0.0 and VSCode intellisense/autocompletes seem to be a little bit faster…

@vkarpov15 There is no need to go that far to show the issue. In fact, you can test it very quickly. Initialize a new npm package with npm init and npm install mongoose@5 Then open the project folder with VSCode and add the following product schema & model in ProductModel.js

const mongoose = require(‘mongoose’);

const productSchema = new mongoose.Schema({ name: { type: String, trim: true, required: [true, ‘A product must have a name’], unique: true }, color: { type: String, required: [true, ‘A product must have a color’] }, weight: { type: Number, required: [true, ‘A product must have a weight’] }, ratingsAvg: { type: Number, default: 4.5 }, ratingsQuantity: { type: Number, default: 0 }, price: { type: Number, required: [true, ‘A product must have a price’] }, priceDiscount: Number, summary: { type: String, trim: true, required: [true, ‘A product must have a description’] }, description: { type: String, trim: true }, image: { type: String, required: [true, ‘A product must have an image’] }, images: [String], createdAt: { type: Date, default: Date.now(), select: false } });

const Product = mongoose.model(‘Product’, productSchema);

module.exports = Product;

Then just hover with the mouse over productSchema in the declaration and intellisense will show “Loading…” for several seconds while the Code.exe process blasts up to 100% CPU usage. With the latest VSCode 1.59.1 and mongoose 5.13.8 I have to wait about 5 seconds (sometimes more) every time I make any changes to the file or if I hover over one of the variables, in order to see the autocomplete results.

@andrewbranch, take a look at these commits: https://github.com/Automattic/mongoose/search?q=10349&type=commits

I think most of the perf changes made the types worse, removing features to improve performance.

Yeah I didn’t read into it yet. That solution is absolutely horrible and damaging. I mean it goes against all the work put into the types! As a typescript user myself, if mongoose’s support for types comes at a cost of slowing the tsserver down severly, it doesn’t support types. This issue shall remain open until the performance is types is ok.

Dude all i know is if you don’t extend Document and dont pass the interface/type to Schema() my auto complete and compilation is fast… Like regular speed.

@Josephvs96 I think that’s because our TypeScript definitions currently don’t support using Schema() without new. So that provides some insight into where the slowness may be coming from.

@sanmmm @lorand-horvath can you please confirm whether 6.0.6 has sped things up for you?

We made some improvements in fefebb3 that will be shipped with v5.13.7, and we’ll continue trying to find other ways to speed this up.

I am experiencing the problem since Mongoose has adopted it’s own official type definition. I have a workaround that is to delete index.d.ts of mongoose in node_module and then npm i -D -E @types/mongoose@5.10.5 to temporarily use the DefinitelyTyped type definition.

Same as @ShadiestGoat for me. Even eslint gets very slow. If I delete index.d.ts from mongoose lib inside node_modules, performance of everything becomes instant again.

I’m also having the same issue since I started rewriting my project in TypeScript, and @Chudroy 's solution seems to be the best one npm i mongoose@5.10.4 npm i @types/mongoose@5.10.4 seems to be working fine for me

Using the repro at https://github.com/Automattic/mongoose/issues/10349#issuecomment-860981794

mongoose@5.13.14:

$ npx tsc --extendedDiagnostics

Files:                         113
Lines of Library:            28686
Lines of Definitions:        45982
Lines of TypeScript:            18
Lines of JavaScript:             0
Lines of JSON:                   0
Lines of Other:                  0
Nodes of Library:           122244
Nodes of Definitions:       121403
Nodes of TypeScript:            66
Nodes of JavaScript:             0
Nodes of JSON:                   0
Nodes of Other:                  0
Identifiers:                 86420
Symbols:                    133695
Types:                       58605
Instantiations:             148743
Memory used:               171707K
Assignability cache size:    20368
Identity cache size:           133
Subtype cache size:              0
Strict subtype cache size:       0
I/O Read time:               0.19s
Parse time:                  0.68s
ResolveModule time:          0.06s
ResolveTypeReference time:   0.00s
Program time:                0.99s
Bind time:                   0.29s
Check time:                  2.56s
printTime time:              0.00s
Emit time:                   0.00s
Total time:                  3.84s

mongoose@6.4.0:

Files:                         140
Lines of Library:            28686
Lines of Definitions:        52590
Lines of TypeScript:            18
Lines of JavaScript:             0
Lines of JSON:                   0
Lines of Other:                  0
Nodes of Library:           122244
Nodes of Definitions:       141748
Nodes of TypeScript:            66
Nodes of JavaScript:             0
Nodes of JSON:                   0
Nodes of Other:                  0
Identifiers:                 93349
Symbols:                    227668
Types:                      106226
Instantiations:             532762
Memory used:               250874K
Assignability cache size:    34548
Identity cache size:          9758
Subtype cache size:              0
Strict subtype cache size:       0
I/O Read time:               0.22s
Parse time:                  0.74s
ResolveModule time:          0.05s
ResolveTypeReference time:   0.02s
Program time:                1.09s
Bind time:                   0.32s
Check time:                  4.18s
printTime time:              0.00s
Emit time:                   0.00s
Total time:                  5.59s

v6 seems to be significantly slower, at least on this base case 🤔

We’ll see what we can do for 5.x.

Latest tsserver uses ts 4.5.2 as per package.json and there’s no joy.

Dude all i know is if you don’t extend Document and dont pass the interface/type to Schema() my auto complete and compilation is fast… Like regular speed.

As said previously… doesn’t that mean you get no type information?

@lorand-horvath can you come up with an example similar to the one in #10515 (https://github.com/andreialecu/repro-mongoose-slow-ts) that demonstrates the slowdown you’re seeing using tsc --extendedDiagnostics? Seeing what the code that’s causing the slowdown would help figure out where to look.

我也能够明显感觉到，mongoose 使得 vscode 加载类型提示变慢。但是仅限于加载 mongoose 相关的内容变慢。

Confirmed, it looks like some recent changes, including #11650, caused a slowdown that our benchmarks are not picking up on surprisingly. Running tsc --extendedDiagnostics from the Mongoose repo’s benchmarks/typescript/simple repo is still fast, but once you npm install mongoose in a separate repo then tsc --extendedDiagnostics becomes very slow.

We undid some of the changes from #11650, and we’ll figure out what other issues caused perf degradations.

I tried to use @Thisura98 fix and it stopped lagging, but now I lost type checking and autocomplete on my schemas… Using tsc v4.7.4 and VScode 1.69.0

Happy to find this thread. I thought my PC was starting to die.

Same slow behaviour found on MAC and WINDOWS machines. I noticed the problem while doing tutorials to learn mongoose and somehow ended up on this thread.

Thank you @Chudroy for finding a mongoose version that is still fast. 5.10.4 is indeed not slowing down intellisense with the latest version of vscode (1.68.1).

NOTE: I’m only using native javascript. No typescript.

I was able to knock 1s off the v6 total time via the following process:

1. tsc --generateTrace .
2. npx analyze-trace .
3. Find the highest line that says Determine variance of type ...
4. Look up what type the id from (3) was referring to in types.json
5. Add variance annotations on that type (take a guess at the correct annotation and TS will tell you if you’re wrong—everything was either out [covariant] or in out [invariant])
6. Repeat

The types I modified were ObtainDocumentType (had to extract the false side of the conditional type to a new type alias and add variance annotations on that, since annotations aren’t supported on conditional type aliases), Query, and Model. After that, analyze-trace reported no more variance hot spots. It’s possible that looking at the trace in detail could uncover more types where variance annotations would help a very small amount that eventually adds up in bigger programs.

@SethWen your version of TypeScript is over a year old.

So right now the most meaningful improvement I’ve been able to find is removing SchemaDefinitionType. That further reduces instantiations from 53k to 49k. Unfortunately, that would be a breaking change, so we can’t do that until Mongoose 7.

I’m going to close this issue. https://github.com/Automattic/mongoose/commit/1141ec487b12376b2eb7ccf0123a1f6d1245a149 seems to have solved the performance issues that most people on this thread have mentioned, and reduced the number of instantiations by 4x. We’ve kept this open as a way to track our overall efforts to support TypeScript performance, but I think the biggest thing we can do for TypeScript performance now is #11615.

I’m suffering from this as well; Mongoose type definitions make the Typescript Language Server extremely slow.

Overall this seems like a real head scratcher as everyone seems to be reporting something a bit different.

@andreyvital we shipped the improvements mentioned in https://github.com/Automattic/mongoose/issues/10349#issuecomment-941439708 in v6.0.11. We’re just keeping this issue open for future improvements.

Am I the only one who gets this problem with Javascript too, not just Typescript?

Hey, I copied this example from https://mongoosejs.com/docs/typescript.html and VSCode started lagging extremely. After commenting out schema definition, lagging stops. “mongoose”: “^6.0.11”, node: v14.18.1 Linux: Ubuntu 20.04

I believe the issue may be line 103 of index.d.ts.

Change:

export function model<T>(name: string, schema?: Schema<any>, collection?: string, skipInit?: boolean): Model<T>;

to

export function model<T>(name: string, schema?: Schema<T>, collection?: string, skipInit?: boolean): Model<T>;

and the issue seems to go away for me. I’m not fully up to speed on the entire typing system in use here - so I’m not sure if there are implications to this, but the examples I provided in the gist both work with this change.

@traverse1984 I do get type information, as its passed to the model<Type>(). It shows up in the completion. @lorand-horvath Dude, why so edgy?

Edit: should clarify that type info is not available in the schema creation but it’s available when using the model. Thats better than a 3 second delay for the for the whole project.

Dude all i know is if you don’t extend Document and dont pass the interface/type to Schema() my auto complete and compilation is fast… Like regular speed.

As said previously… doesn’t that mean you get no type information?

@traverse1984 Yup, he just won’t acknowledge it and IMHO it doesn’t really make sense to use it like that. If it does make sense, please, someone genius, enlighten me.

I used Mongoose before I started using TS. I still think Mongoose is useful without the type information, but I would say if you don’t care about that then this issue is not relevant to you. For those of us that want the typings working, “JavaScript doesn’t have types” is not really a solution.

@lorand-horvath do you use types in js? Doesn’t mongoose work on js? See its simple.

Mongoose 6.0.7 VSCode speed is great as well - nice!

Thanks for your patience! We’ll do some more work to see if we can further reduce the unnecessary overhead.

One interesting behavior i noticed when i was on 6.0.5 is when i use the new keyword to initialize a new instance of schema is when the slowness started for me. When i removed the new keyword it would fix the problem, i would lose IntelliSense on the schema object itself but hey that was trade i was willing to make.

I tested 6.0.6 now and for me updating solved the speed issues i was having when creating a new schema with the new keyword.

I created a minimal repro at: https://github.com/andreialecu/repro-mongoose-slow-ts

I’m on a M1 Apple CPU so I’m not super affected by this, but I did notice a minor slowdown.

There’s an easy process to verify it:

• run yarn tsc --extendedDiagnostics in the root. I’m seeing Check time: 1.11s
• If I comment out the new Schema call, the check time is 0s.
• If I comment out the line mentioned in https://github.com/Automattic/mongoose/issues/10349#issuecomment-885927142 the check time drops to 0.6s

Something that helps a lot in case you don’t already have it enabled is to add "skipLibCheck": true to your tsconfig. Without it, the check time is double.

I created a new TypeScript Node project and it worked fine even just after installing mongoose. However, as soon as I started creating a schema and creating a model from it, things started going south.

This is what the schema + model code looks like.

import * as mongoose from 'mongoose';

export const testSchema = new mongoose.Schema({
    name: String,
    time: Number,
    age: Number
});

export const testModel = mongoose.model('TestModel', testSchema);

I also checked by importing the model and Schema individually instead of using * as but the outcome was the same.

I am a beginner to the world of Mongo and Node so unfortunately I am not knowledgable enough to debug this issue. So instead for the time being, I am going to resort to using the vanilla MongoDB Driver for Node: link.

Sorry mongoose.

----- EDIT -----

tsconfig.json

{
  "compilerOptions": {
    "target": "es5",   
    "module": "commonjs",   
    "strict": true,             
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

package versions

@types/express@4.17.13
express@4.17.1
mongodb@4.0.1
mongoose@5.13.3
node-ts@5.1.1
node@16.5.0
nodemon@2.0.12
typescript@4.3.5

I can confirm it slows down all the content for me too.

I did as @cainaf said to verify it was mongoose, I deleted index.d.ts and…, vs code was running fine as hell again. I restored index.d.ts and the performance heavily dropped down again.

@vkarpov15 In our project we also struggled with the slow performance of TS-server, today we did some tests and disabled all vscode extensions, performance improved drastically! In our case, it turned out that one particular extension affects the TS-server performance, turning it off makes everything run smoothly. Please check on your enviroment

@Chudroy’s also worked for me, you just need to add extends Document to your TS schema interfaces. Unfortunate to have to downgrade but it’s way better than working with that lag.

I also have this problem, the last version of mongoose that is fast for me is 5.10.4. Currently on VS Code 1.68.1. Everything else is up to date.

No, that’s just the difference in lib files in node_modules caused by upgrading mongoose.

Can anyone share an open source repo that has a lot of mongoose usage and seems affected by this issue? I’m hoping to try some experiments and see how they impact a codebase larger than the tiny example repro shared at the top of this thread.

I have the opposite experience. VSCode February 2022 (TS >4.6) has terrible performance, where as VSCode January 2022 (TS <4.6) shows no regression.

For now, my VSCode is March 2022, while my Intellisense server for typescript is pointed to an install of TypeScript 4.5.5

Or forcde vscode to use latest typescript.

@Uzlopak lol - latest VSCode actually has terrible “performance” https://github.com/microsoft/vscode/issues/146737 OK, to be fair, I’m not talking about typings, but perf in general.

@vkarpov15 Thank you so much! 👍

@vkarpov15 Any chance that these recent commits for performance improvements can be applied to the 5.x branch?

Thanks, Kelly

I can also confirm that 6.0.5 has near instant autocomplete on vscode while not introducing any breaking changes to my project (downgraded from 6.0.15).

6.0.5 works perfectly fine, while 6.1.2 is lagging really hard. Not sure what changed that made it so slow.

https://github.com/microsoft/TypeScript/pull/46429

It appears that a performance issue upstream in TypeScript has recently been fixed as part of 4.5.

I haven’t been able to test it yet but the issues linked to the PR are extremely familiar with the mongoose degradation.

@vkarpov15 Would it be possible to backport the VSCode-related improvements you made in 6.0.6 - 6.0.11 to Mongoose 5.x ?

🤦‍♂️

just don’t generate types on the fly … just make it save them somewhere on the module… maybe make a third party tool like the prisma one that generate d.ts types for every table once (or whenever the user changes the tables) most developers don’t change their schema that much… it’s just frustrating that types don’t update fast enough even if i’m not changing any schema

the pr fix doesnt seem to work to help performance. maybe it did, but its still slow. i stumbled upon this once trying the library and finding the types to be slow. the second overload on model() does solves the issue though.

I believe the issue may be line 103 of index.d.ts.

Can anyone else confirm this? I’m away from my setup atm. @traverse1984 if this is actually a the solution, please make a pr… Ill take a look at why this happens and see if anything is wrong

should clarify that type info is not available in the schema creation but it’s available when using the model. Thats better than a 3 second delay for the for the whole project

Ie. This is a workaround, not a solution.

@ShadiestGoat It works fine for me when using Mongoose 6.0.6 - 6.0.8 in VSCode 1.60.2, you may close the issue, if others don’t object.

I tried 6.0.7 earlier and found things to still be pretty slow. Not as bad as it was, I don’t think, but bad enough that I’d stick to the 5x release with the DT types. Is there a test case which includes typings which should work that I could run - to rule out I’m not doing it wrong?

Heya! I haven’t really been looking at this issue since I just made my own module haha, am I right to say that this issue is resolved & should be closed?

@arnav7633 nice to hear that. Btw are you using ts-node?

@arnav7633 Dude you don’t need to worry about compile time. Just use ts-node… Or tsc --watch. Incremental compilation is a hell lot faster.

@sanmmm that’s hard to believe because 6.0.6 hasn’t been released yet.

On the bright side, we did some digging and found that we can repro significant perf degradation on https://github.com/andreialecu/repro-mongoose-slow-ts if we disable TypeScript’s skipLibCheck. With Mongoose 6.0.5, we’re getting 4.1 seconds and 241k instantiations with tsc --extendedDiagnostics. With e0fb110, we’re getting 3.6 seconds and 166k instantiations. Still not all the way to where we want to be, but should help somewhat.

We’ll release 6.0.6 soon, please try it out and see if that makes things faster. We’ll keep iterating for future releases to see if we can speed things up more.

It still very slow when I upgrade to version 6.0.6

Can confirm that I’m also experience a big slowdown of my editor experience using Mongoose 6.0.4. I have gone with the suggestion from above to use an earlier version of Mongoose and the DT types, which doesn’t cause the same issue. I would much rather be using the latest version.

What was changed in the versions released up until shortly before June 13th? Because, this performance drop wasn’t noticed at first with the introduction of Mongoose’s own types. So, I’d venture to say, the issue was introduced in a change made shortly before June 13th. I mean, between November of last year, when the new types were introduced, until May (6 months) nobody had such issues, right? Just saying and trying to help. 😃

For instance, there are a couple of fixes that could be suspect here: https://github.com/Automattic/mongoose/compare/5.13.2...master

Scott

It looks like using the ‘raw’ version of the schema (UserSH in my example) in as many places as possible rather than the full document increases performance, which is to be expected. I am working on some more changes of this nature, for the 6.0 release

commenting out line 2440 alone has given me MAJOR performance improvement:

type _AllowStringsForIds<T> = {
  // [K in keyof T]: [Extract<T[K], mongodb.ObjectId>] extends [never] ? T[K] : T[K] | string;
};

it doesn’t seem to break my code. it’s not perfect, but at least I feel like I can work again now

Although returning to @types/mongoose does solve performance problem, it also may break your code. It sure did mine.

When we migrated to mongoose own types, we had to fix more than 500 typescript errors (the code was fine and would work requiring no change, it’s just the way types are implemented that vary from one to another, the requirement of methods and their return types).

If we were to fallback to @types/mongoose again, that’s what’s waiting us:

And then, when the problem here is solved, we would have to change all over again. not cool =/

So I’m looking into potential reasons for this (just started). To me it just looks like its a long build of the problem, where the types file is just too long/complex. For example, taking an older version of mongoose (eg. 3.11.18), the issue was starting to present itself, given that it decreased performance by a lot, but no where near this level. It could be that to solve this problem the types for this module need a major rework. I also believe this should be a priority.