-
-
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
findByIdAndUpdate() type error #10981
Comments
What does |
The
Here's a scaled-down version of my codebase. If you look at the Thanks for the reply. Hopefully the sandbox above clears things. I really don't know what to even look for here. |
Yeah I'm seeing this issue now too. Any help would be great. Below is my setup. Error is almost identical. It built fine yesterday, now today it doesnt. The build locally works fine, its just when building in Docker on our Github Actions that it fails. Schema File:import mongoose, { Document } from "mongoose";
import { BaseDocument } from "../@types";
export interface IProduct extends BaseDocument {
name: string,
code: string,
description: string,
price: Number
}
// -----------------------------
export default mongoose.model<IProduct>('Product', ProductSchema); Types File:import { Document } from 'mongoose';
export interface BaseDocument extends Document {
createdBy: string;
updatedBy: string;
} |
Strange, upgrading to 6.1.1 for me actually removed the error. I can confirm it now runs fine from both my codebase (local and live) and codesandbox without any casting. I guess I still can't close this one then. |
If it works in 6.1.1 then this issue should be ok to close |
Do you want to request a feature or report a bug? bug
What is the current behavior?
There seems to be a type error when using the interface pattern described here:
Complete guide for Typescript with Mongoose for Node.js
If the current behavior is a bug, please provide the steps to reproduce.
Here's how I actually implemented it:
The
TSchema
used is from #9715 in courtesy of #9715 (comment). TheIBrandDoc
is just something similar toIProductDoc
but on another model. I made my own working base document as stated in Mongoose Docs on TypeScript Support.There's nothing really wrong with the inheritance pattern described in the blogpost. It does work when an interface has no references to another model and the typesetting is sufficiently strong. However, when it is used in
findByIdAndUpdate()
, it creates the type error above. As far as I know,findOneAndUpdate()
,updateOne()
, andupdateMany()
also produces similar errors.My
tsconfig.json
:What is the expected behavior?
I don't really know if I'm doing something wrong there, but it should work as is given that the
IProduct
interface works perfectly with the other model methods. Interfaces without references to other models work like a charm.A temporary workaround would be to cast the
data
object above toany
(e.g.,<any>data
) when using it as an argument infindByIdAndUpdate()
, but I don't know the future implications for this. I wonder if the blogpost is outdated now that Mongoose v6 is out.What are the versions of Node.js, Mongoose and MongoDB you are using? Note that "latest" is not a version.
Node: v17.1.0
Mongoose: v6.0.12
MongoDB: v4.1.4 (did not explicitly install, it is a dep from when Mongoose was installed)
Update:Took a little breather and it turns out I just needed to use the
IProductDoc
instead of just theIProduct
since updating meant that it assumes it's already a saved document. In other words, it already has an_id
and such. No errors ever since. My bad. I guess the takeaway here is that when the going gets tough, just don't forget to take a break sometimes.Update 11/20/21:
I retract my earlier revelation. I do in fact need
data
to be just the plainIProduct
instead of theIProductDoc
. I just found out I can't append the_id
in theupdate
params for use infindByIdAndUpdate()
as it gives theexpected "_id" to be unique
error, so usingIProductDoc
gives object creation type errors. Found something similar on #10689.The text was updated successfully, but these errors were encountered: