Typescript Typedefs

[dyst5422]

Would be worth adding typescript definitions to DefinitelyTyped.

Should be easy enough to take the MongoDB typings and simply cut out the parts that aren't implemented for mongo-mock.

[Downchuck]

I'd see these working with the MongoDB typings, using extends and such.

[ricardo-cavalheiro]

One (temporary) way to solve it, is to declare your own typings.

src/@types/mongo-mock.d.ts

declare module 'mongo-mock' {
  import type { MongoClient as IMongoClient } from 'mongodb'

  export class MongoClient extends IMongoClient {}
}

src/infra/db/utils

import { MongoClient as MongoClientMock } from 'mongo-mock'

export const MongoHelper = {
  async connect(databaseUri: string) {
    this.client = await MongoClientMock.connect(databaseUri)
                                     // ^^^^^^^ intelisense here
  }
}

TS version: 4.9.3

[LinusU]

I would love to get some more background on how people are using this lib that requires typings.

Since I'd imagine most people would be mocking the mongodb module with this, I don't think that typechecking would be a problem. If we have typings, should they mirror MongoDB exactly, or just the parts that are currently implemented?

For reference, this is how we are using this library in our tests:

  require('mongodb').MongoClient = require('mongo-mock').MongoClient
  require('mongodb').ObjectId = require('mongo-mock').ObjectId

[dyst5422]

I would love to get some more background on how people are using this lib that requires typings.

Since I'd imagine most people would be mocking the mongodb module with this, I don't think that typechecking would be a problem. If we have typings, should they mirror MongoDB exactly, or just the parts that are currently implemented?

For reference, this is how we are using this library in our tests:

  require('mongodb').MongoClient = require('mongo-mock').MongoClient
  require('mongodb').ObjectId = require('mongo-mock').ObjectId

I have never seen someone do this to mock out modules. I don't know how I feel about it

[LinusU]

I have never seen someone do this to mock out modules. I don't know how I feel about it

Yeah, it's a bit hacky 😅

There is also proxyquire which is a bit cleaner.

I really like that the code being tested doesn't have to be adapted to be testable though, as that introduces more code paths and possibilities for subtle bugs.

---

How do you use mongo-mock?

[ricardo-cavalheiro]

@LinusU It kind sucks not knowing what methods the lib is exposing. I guess only the mongo-mock related typings should be added, otherwise one might end up calling a method which is not supported by lib.

[LinusU]

It kind sucks not knowing what methods the lib is exposing.

Yes that is unfortunate.

I guess only the mongo-mock related typings should be added, otherwise one might end up calling a method which is not supported by lib.

How are you using mongo-mock? I'd imagine that one would write the code to target the real mongodb, since otherwise the code wouldn't do anything, so I'm not sure that having partial typings in this project would solve the above problem?

[ricardo-cavalheiro]

@LinusU Right now I'm just testing the business logic via integration tests. In practice, I only use insertOne, findOne, db().collection(), etc to make sure the data is being saved/retrieved. I'm not testing more advanced features like aggregation and stuff like that. The main reason I'm using this lib is because it's an in-memory copy of MongoDB and so I don't need to have a MongoDB instance running somewhere.

[LinusU]

@ricardo-passos how is your business logic typed? Are you passing a MongoClient instance to it? In that case, what would you want to do with types in this library? If we only typed the functions actually supported by this library you'd get a type error trying to pass it to your business logic? 🤔