Use Case

The Mongoose FLE work was the first time the Node team contributed non-trivially to the Mongoose codebase.  Some opportunities to improve the quality of Mongoose's codebase are noted in this ticket.

As we contribute in the future, we should consider implementing the suggestions in this ticket (if relevant).

1. Use classes instead of constructor functions

Mongoose uses classes in some places but not others - it does seem that this is the direction they're moving but haven't really migrated yet. Classes have better tooling support (tooling struggles to determine what `this` is, especially for any classes that inherit from a base class).

2. Document internal mongoose properties

Mongoose does not document its internal properties (honestly, mongoose's conventions for marking properties private or not is lacking). Adding doc comments that explain what internal properties are for would go a long way to improving the approachability of the codebase.

3. Add typing support

Typescript would be ideal. However, combined with 1, where the type of `this` can reliably be determined either through type inference in the IDE or jsdoc comments, adding a TSConfig with checkjs enabled would provide some type checking to Mongoose's codebase.

User Experience

n/a

Dependencies

n/a

Risks/Unknowns

• Maybe Val or other maintainers wouldn't accept these PRs?

Acceptance Criteria

Implementation Requirements

• functional reqs, potential snafus to avoid, performance targets, etc

Testing Requirements

• unit test, spec test sync, etc

Documentation Requirements

• DOCSP ticket, API docs, etc

Follow Up Requirements

• additional tickets to file, required releases, etc
• if node behavior differs/will differ from other drivers, confirm with dbx devs what standard to aim for and what plan, if any, exists to reconcile the diverging behavior moving forward