-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Typescript Schema definition is incorrect #9606
Comments
i had this problem and i solved it by fixing versions on my package.json: "dependencies": { i have to use old 5.10 since 5.11 is ruining my work. |
@NaturesProphet mind sharing tsconfig, we still can't build. need to release to google cloud. it's a disaster! thanks in advance. |
Mongoose 5.11.0 released it's own official types file (#8108). Are there any docs on how to migrate from using @types/mongoose to official types? |
working tsconfig you may need to change tsconfig.build.json aswell disaster here also :( |
I have this problem too. export const schemaName: Schema = new (Schema as any)(
{
started: { type: Date, required: false },
ended: { type: Date, required: false }
},
{ _id: false }
); but they are not solutions... also if I use a package that was built with the old version in an application that uses the new one I get this error Type 'Schema' is not generic.
export declare const SchemaName: Schema<any>; I think that it is caused by the same main error of the schema contracture because if I do the (schema as any) in the package and use it the error in the application does not pop up. |
Hi, I just tried to upgrade to 5.11 also and have 244 errors. I cannot build the project and need to downgrade. Is there any documentation on how to migrate from @types/mongoose to the default type definition? Regards, |
Same here tons of errors after update to 5.11.
|
Same here, any chance to get the @types/mongoose packages into the core package? I think a lot of people are relying on it, and creating new - incompatiblity - types creates a lot of (unnecessary?) pain. little excerpt:
|
I'm experiencing this one too. Have fixed my mongoose version at 15.10.3 for now while I watch this thread :) |
It probably has something to do with mongoose migrating the types, for some reason instead of taking the schema definition from @types/mongoose it goes directly to the mongoose index.d.ts which why the error is caused, I'm pretty sure because I'm running microservices with one service on a newer realease and one on an older one, both have almost similar schema definition, but one of them fails(newer) and other one(older) works perfectly |
Changing "mongoose": "^5.x.xx" to "mongoose": "~5.x.xx" in package.json will solve these problems for now I guess. |
We're working on fixes for any issues that pop up - in theory you shouldn't have any issues migrating from @types/mongoose to the new bindings. If you find any, please open a new issue with code samples, #9608 is a good example. @simllll it looks like you're experiencing a problem because you're importing both @types/mongoose and Mongoose v5.11's type bindings. Can you try removing @types/mongoose and see if you still get compiler errors? |
@vkarpov15 Yeah the thing is we actually forked this to our own needs, we have "custom"/generic object ids in our code.. e.g. ObjectId(...) or ObjectId(..). some small excerpt of this: type MongooseQuery<T> = {
[P in keyof T]?: [Extract<T[P], TypeObjectId<any> | TypeObjectId<any>[]>] extends [never] // objects can also have "typeobjectids" as properties, also we allow value of "null" for all fields
? T[P] extends {}
? mongodb.Condition<MongooseQuery<T[P] | null>>
: mongodb.Condition<T[P] | null> // otherwise we ONLY allow "correctly casted" mongodb object ids
: mongodb.Condition<mongodb.ObjectId | null>;
};
type IfAny<T, Y, N> = 0 extends 1 & T ? Y : N;
type IsAny<T> = IfAny<T, true, never>;
type MongooseUpdate<T> = {
[P in keyof T /* as Exclude<T, Function>*/]: [Extract<T[P], TypeObjectId<any>>] extends [never]
? Extract<T[P], string | number | boolean | Date> extends [never] // these types are safe to put back immeideatly
? Exclude<T[P], undefined> extends Array<any>
? MongooseUpdate<Exclude<T[P], undefined>>
: Omit<MongooseUpdate<Exclude<T[P], undefined>>, '_id'> & { _id?: mongodb.ObjectId } // if it's any kind of object though, check the properties of it too for "typeobjectid"
: T[P]
: IsAny<T[P]> extends never // extract typeobject id matches for "any", therefore check this here again
? mongodb.ObjectId
: T[P];
}; example model def
and TypeObjectId is just defined as: export type TypeObjectId<T> = string & { type: T }; and ObjectId itself is a function that checks if the id is valid, and returns a casted string to TypeObjectId. export const ObjectId = <T = never>(input: T extends never ? never : unknown): TypeObjectId<T> => {
// ... check if input is a valid object id...
return input as TypeObjectId<T>;
} I attached our definition file, in case it helps to understand or if you are willing/interested to take parts of this approach to your definitions ;-) It would be great to see this feature in the "core". Willing to help :) Anyway before this comes to much out of scope: The main issue is, I cannot upgrade mongoose now, because I'm unable to use my type "improved" defs after that. |
@vkarpov15 Has this already been released ? |
@snava10 the fix for OP's issue hasn't been released yet, but will be released within the next few hours. @simllll this is an interesting problem. Do you know if there's a way to make TypeScript use your custom bindings rather than Mongoose's for now? Or make it so that your bindings work in parallel with Mongoose's? I would love to discuss incorporating your changes, but first I want to make sure you're unblocked from upgrading. |
Yes bro it's a TOTAL DISASTER! it happens when theres no good tests when someone commit on master. this is my current tsconfig: I wont use mongoose anymore. this is a total IRRESPONSIBILITY! A DISASTER! |
Relax ;-) This is open source software and @vkarpov15 and others are doing a great job and put in a lot of time to maintain this library! It "only" breaks types for now, and there is no real sem-ver for types either, these problems occur on @types almost every day. But it's not that you are left alone, everyone here tries to find a solution and fixes are already commited :) So I recommend just downgrade to an older version in the meantime and stick to it (there are some comments alreyd how you can do this), till you find time to upgrade to the new one. And regarding tests: Mongoose has a great test suite ;) (well not for types (yet), but for the library itself)! Just be sure you use a package-lock or yarn lock file and don't do "implicit" updates. |
The only way I know of is doing declaration merging, but therefore it would need an interface. I think it will be doable by e.g. defintining the "ObjectId" in an interface, which can be overwritten from outside,.. I'm happy to look into this. But guessing on my current knowledge it's not a "quick fix"... If someone else has an idea how to "ignore" or "overwrite" type definitions, please let me know (Except from listing all types in tsconfig which I want to use, this is unfortunately not an option, as we have probaly more than 100 type defs out there ;)). |
@simllll I opened a separate issue to discuss this: #9614. OP's issue is fixed by 13140c0. If you've been affected by this issue, I'm very sorry for any inconvenience. To work around it:
If you still have issues compiling, please open a new issue and follow the issue template. If you're using a fork of @types/mongoose, follow #9614 for updates. |
version 5.11.0 mongoose
Reporting a bug
cannot pass two parameters to new Schema ();
What is the expected behavior?
Schema should accept two parameters.
What are the versions of Node.js, Mongoose and MongoDB you are using? Note that "latest" is not a version.
version 5.11.0 mongoose
version 12.18.3 node
the fault lies in mongoose/index.d.ts
the @types/mongoose/index.d.ts has the correct constructor definition.
note the "options?:SchemaOptions".
my code is picking up the mongoose/index.d.ts, not @types but that's another battle.
thanks
The text was updated successfully, but these errors were encountered: