The TypeScript type definition of Mongoose are not fully correct!<\/p>\n
I inspected (or debugged) a nodejs server project of Little Gengsha<\/a>‘s, where he’s using koa as the server and mongodb as the data store. The project seems called “Writer’s Platform”, which seemed very primitive then. There were only two routes, a <\/p>\n At the first sight\u00a0I discovered that Then I thought it could be due to the chaos of the versions of the koa ecosystem. The versions of koa and koa-router are all mixed. They both defaulted to the old version while people would like to use the new, under-development version. Koa advanced afterwards, while koa-router still defaults to the older version. I once encountered a problem caused by such incompatibility and solved it for someone.<\/p>\n But this time it’s not the case. We switched from promise to\u00a0 (However, we discovered that \u00a0 I was then upset with the signatures of the various functions (like what should be returned in the callback of We began to suspect that\u00a0\u00a0 So we specially inspected the TypeScript type definition of mongoose, in hope of finding any misuse. The \u00a0 and (taken from the result of\u00a0 Since TypeScript was not reliable then, we could only resort to the source code. Directly searching for\u00a0\u00a0 It returns the result of We thought of another ultimate measure: inspecting the call stack\u3002We used Suddenly, I thought about directly Without May, 4, 2017<\/p>\n <\/p>","protected":false},"excerpt":{"rendered":" The TypeScript type definition of Mongoose are not fully correct! I inspected (or debugged) a nodejs server project of Little Gengsha‘s, where he’s using koa as the server and mongodb as the data store. The project seems called “Writer’s Platform”, which seemed very primitive then. There were only two routes, a get, a post, the … Continue reading “An incident caused by an incorrect TypeScrpit type definition of Mongoose”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":318,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[15,16],"tags":[17,20,19,18,21],"_links":{"self":[{"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/posts\/298"}],"collection":[{"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/comments?post=298"}],"version-history":[{"count":10,"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/posts\/298\/revisions"}],"predecessor-version":[{"id":398,"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/posts\/298\/revisions\/398"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/media\/318"}],"wp:attachment":[{"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/media?parent=298"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/categories?post=298"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/colliot.org\/en\/wp-json\/wp\/v2\/tags?post=298"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}get<\/code>, a post<\/code>, the latter of which is used to submit an article<\/code>\u00a0to mongodb. During the test he discovered a problem — the body of the response should be changed in the callback of the save<\/code>\u00a0function, but the action response is “OK”, which is the default response of koa.<\/p>\nrouter.post('\/path', (ctx, next) => {\r\n const article = new Article( \/* something *\/ );\r\n article.save((err, article) => {\r\n if (err){\r\n ctx.body = err;\r\n } else {\r\n ctx.body = \"success\";\r\n }\r\n });\r\n})<\/pre>\nnext()<\/code>\u00a0is not returned in \/* body *\/<\/code> of\u00a0router.post('\/path', (ctx, next) => { \/* body *\/ });<\/code>This may cause the response to return early before the save<\/code>\u00a0action calls back. But simply return a next()<\/code>\u00a0did not help.<\/p>\nasync\/await<\/code>, but the problem persists.<\/p>\nrouter.post('\/path', (ctx, next) => {\r\n const article = new Article( \/* something *\/ );\r\n return article.save((err, saved) => {\r\n if (err){\r\n ctx.body = err;\r\n } else {\r\n console.log(saved);\r\n ctx.body = \"success\";\r\n }\r\n \/\/ or `return next();` here.\r\n }).then((thing) => {\r\n console.log(thing);\r\n return next();\r\n });\r\n})<\/pre>\nthing<\/code>\u00a0is undefined<\/code>,\u00a0which turns out to be the key)<\/p>\nrouter.get()<\/code>, or what is the type of next<\/code>), so I proposed using TypeScript for auxiliary checks.<\/p>\narticle.save<\/code>\u00a0is not working as expected. The function, which is similar to the only sample code from koa regarding async operations, is expected to work as demonstrated by the doc\uff1a<\/p>\nrouter.get(\r\n '\/users\/:id',\r\n function (ctx, next) {\r\n return User.findOne(ctx.params.id).then(function(user) {\r\n ctx.user = user;\r\n return next();\r\n\r\n });\r\n },\r\n function (ctx) {\r\n console.log(ctx.user);\r\n \/\/ => { id: 17, name: \"Alex\" }\r\n }\r\n);<\/pre>\narticle<\/code>\u00a0is an instance of Article<\/code>, while Article<\/code>\u00a0is actually a class (not only a instance, but also a class itself) dynamically constructed by\u00a0mongoose. It is reflected in the type system:<\/p>\ninterface Model<T extends Document> extends NodeJS.EventEmitter, ModelProperties {\r\n new(doc?: Object): T;\r\n \/* other things *\/\r\n}<\/pre>\narticle<\/code> is just the\u00a0<T extends Document><\/code>\uff0c\u00a0Document<\/code>‘s save<\/code>method is written as follows\uff1a<\/p>\n \/**\r\n * Saves this document.\r\n * @param options options optional options\r\n * @param options.safe overrides schema's safe option\r\n * @param options.validateBeforeSave set to false to save without validating.\r\n * @param fn optional callback\r\n *\/\r\n save(options?: SaveOptions, fn?: (err: any, product: this, numAffected: number) => void): Promise<this>;\r\n save(fn?: (err: any, product: this, numAffected: number) => void): Promise<this>;<\/pre>\n
npm install @types\/mongoose<\/code>, which somehow differs from that on the github repo of\u00a0DefinitelyTyped .) \u00a0Seeing the Promise<this><\/code>, I was convinced that our use of the function is valid. But the fact is the thing<\/code>\u00a0returned above is undefined<\/code>. So are there any peculiarities?<\/p>\n.prototype.save<\/code>\u00a0will yield us the relevant code. It’s actually here<\/a>.\u00a0But seeing it makes me more desperate:<\/p>\nModel.prototype.save = function(options, fn) {\r\n if (typeof options === 'function') {\r\n fn = options;\r\n options = undefined;\r\n }\r\n\r\n if (!options) {\r\n options = {};\r\n }\r\n\r\n if (fn) {\r\n fn = this.constructor.$wrapCallback(fn);\r\n }\r\n\r\n return this.$__save(options, fn);\r\n};<\/pre>\nthis.$__save<\/code>, but\u00a0that function<\/a>\u00a0does not return actually! How could it return a promise from a function that returns nothing\uff1f<\/span><\/p>\nconsole.trace<\/code>\u00a0for it. Although no direct clue shown, it still gave us some hint\u2014\u2014save<\/code>\u00a0is not called directly, but wrapped with some hook<\/code>.<\/p>\nconsole.log(article.save)<\/code>, which told us that article.save<\/code>\u00a0is actually the result of a\u00a0wrappedPointCut<\/code>\u00a0function! Searching for wrappedPointCut <\/code>in the code almost revealed the answer. The crucial part is\u00a0here<\/a>:<\/p>\nmodel.prototype[pointCut] = (function(_newName) {\r\n return function wrappedPointCut() {\r\n var Promise = PromiseProvider.get();\r\n\r\n var _this = this;\r\n \/* something omitted for simplicity *\/\r\n var promise = new Promise.ES6(function(resolve, reject) {\r\n args.push(function(error) {\r\n if (error) {\r\n \/* something omitted for simplicity *\/\r\n reject(error);\r\n return;\r\n }\r\n $results = Array.prototype.slice.call(arguments, 1);\r\n resolve.apply(promise, $results);\r\n });\r\n _this[_newName].apply(_this, args);\r\n });\r\n if (fn) {\r\n \/* something omitted for simplicity *\/\r\n return promise.then(\r\n function() {\r\n process.nextTick(function() {\r\n fn.apply(null, [null].concat($results));\r\n });\r\n },\r\n function(error) {\r\n process.nextTick(function() {\r\n fn(error);\r\n });\r\n });\r\n }\r\n return promise;\r\n };\r\n })(newName);<\/pre>\nfn<\/code>\uff0c a promise defined on line 7 will be returned on line 33, while with afn<\/code>\u00a0in the parameter, the promise defined would be chained with a then<\/code>\u00a0on line 21, which returns nothing — In this case, the return value should be\u00a0Promise<undefined><\/code>\u00a0instead of Promise<this><\/code>\u2014\u2014 We were fooled by such sloppy type definition! How I wish it could be annotated correctly from the beginning, just like this:<\/p>\n save(options: SaveOptions, fn: (err: any, product: this, numAffected: number) => void): Promise<undefined>;\r\n save(fn: (err: any, product: this, numAffected: number) => void): Promise<undefined>;\r\n save(options?: SaveOptions): Promise<this>;\r\n save(): Promise<this>;<\/pre>\n