MongoDB NodeJS Driver 4.11.0 Released

The MongoDB Node.js team is pleased to announce version 4.11.0 of the mongodb package!

Release Highlights

Recursive Schema Support

Version 4.3.0 of the Node driver added Typescript support for dot notation into our Filter type but
in the process it broke support for recursive schemas. In 4.11.0, we now support recursive schemas and
provide type safety on dot notation queries up to a depth of 9. Beyond a depth of 9, code still compiles
but is no longer type checked (it falls back to a type of any).

interface CircularSchema {
    name: string;
    nestedSchema: CircularSchema;
}

// we have a collection of type Collection<CircularSchema>

// below a depth of 9, type checking is enforced
collection.findOne({ 'nestedSchema.nestedSchema.nestedSchema.name': 25 }) // compilation error - name must be a string

// at a depth greater than 9, code compiles but is not type checked (11 deep)
collection.findOne({
    'nestedSchema.nestedSchema.nestedSchema.nestedSchema.nestedSchema.nestedSchema.nestedSchema.nestedSchema.nestedSchema.nestedSchema.name': 25
}) // NO compilation error

Note that our depth limit is a product of Typescript’s recursive type limitations.

External Contributions

Many thanks to those who contributed to this release!

  • @ermik provided an extremely large schema to test compilation with, which made testing our new recursive schema support possible with large schemas straightforward.
  • @noahsilas for documentation improvements in change streams and fixing our Typescript types for read preferences.
  • @zendagin for adding Typescript support for hashed indexes.
  • @biniona-mongodb for fixing our parsing of TLS options.
  • @LinusU for removing support for server versions lower than our minimum supported server version and improving error messages for unacknowledged writes with hints.

Features

  • NODE-3651: add hashed index type (#3432) (f6b56a1)
  • NODE-3875: support recursive schema types (#3433) (26bce4a)
  • NODE-4503: throw original error when server attaches NoWritesPerformed label (#3441) (a7dab96)
  • NODE-4650: handle handshake errors with SDAM (#3426) (cbe7533)
  • NODE-4721: add aws-sdk as optional dependency (#3446) (b879cb5)

Bug Fixes

  • NODE-3712,NODE-4546: electionId should be ordered before setVersion (#3174) (ca51fec)
  • NODE-3921: error on invalid TLS option combinations (#3405) (1a550df)
  • NODE-4186: accept ReadPreferenceLike in TransactionOptions type (#3425) (dc62bcb)
  • NODE-4475: make interrupted message more specific (#3437) (5f37cb6)
  • NODE-4608: prevent parallel monitor checks (#3404) (78bcfe4)
  • NODE-4647: improve error message (#3409) (0d3c02e)
  • NODE-4649: use SDAM handling for errors from min pool size population (#3424) (ef3b55d)

Documentation

We invite you to try the mongodb library immediately, and report any issues to the NODE project.

2 Likes

There is a small limitation in type checking for recursive types in 4.11.0. Recursive types which reference themselves will compile safely but do not have type checking.

The code example in the release notes will successfully compile, but it will not type check the Filter predicate.

The following is an example that shows a scenario where type checking is enforced.

interface Author {
    name: string;
    bestBook: Book;
}

interface Book {
    title: string;
    author: Author;
}
 
let authors: Collection<Author>

// below a depth of 8, type checking is enforced
authors.findOne({ 'bestBook.author.bestBook.title': 25 }}) 
// ✅ expected compilation error is thrown: "title must be a string"

// at a depth greater than 8 code compiles but is not type checked (9 deep in this example)
authors.findOne({ 'bestBook.author.bestBook.author.bestBook.author.bestBook.author.name': 25 }) 
// ⛔️ perhaps unexpected, no compilation error is thrown because the key is too deeply nested
2 Likes

This topic was automatically closed after 90 days. New replies are no longer allowed.