Create dependency container for system and users-provided modules

XMLWordPrintableJSON

    • Type: New Feature
    • Resolution: Won't Fix
    • Priority: Unknown
    • None
    • Affects Version/s: None
    • Component/s: None
    • Hide

      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?

      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?
    • None
    • None
    • None
    • None
    • None
    • None

      Use Case

      As a Node Driver Maintainer
      I want to introduce an internal dependency container that holds references to system modules and expose an experimental configuration option in MongoClient.
      So that we can prepare the driver for dependency injection without breaking existing functionality.

      User Experience

      • Users will see a new experimental property driverAdapters in MongoClientOptions types. Passing it currently has no effect on the driver's functionality (until propagation is implemented).
      • The driver (MongoClient instance) now has a centralized place (this.runtime or similar) where system modules are resolved and stored.

      Risks/Unknowns

      • Until the downstream tickets are completed, this code is technically "unused" (instantiated but not accessed anywhere), but it is a necessary foundational step.
      • Ensuring our interface definition is compatible with node system modules (such as require('net')) while still being useful for implementers.

      Acceptance Criteria

      Implementation Requirements

      • Define Interfaces for the modules and their methods, classes according to the tech design and what the driver currently uses.
        • You can use Node.js return types (e.g., net.Socket, stream.Duplex) in these definitions. You do not need to redefine the Socket class itself, just the factory methods that create it.
      • API Update: MongoClientOptions interface includes an optional, experimental property:
        /** @experimental */
        driverAdapters?: {
          net?: NetAdapter;
          tls?: TlsAdapter;
          fs?: FsAdapter;
          dns?: DnsAdapter;
          ...
        }
      • Container implementation: create a RuntimeContext class (or internal structure) to hold the resolved modules.
      • Resolution Logic:
        • Instantiate the context inside the MongoClient constructor.
        •  Check options.driverAdapters.
        • If an adapter is absent, synchronously assign the native Node.js module (e.g., require('net')) to the property.
        • Ensure this.runtime is stored privately on the client instance
      • Validation: Ensure that assigning require('net') to the new NetAdapter type does not throw TypeScript errors.
      • No Breaking Changes: The default path must result in the exact same native Node.js modules being loaded.

      Testing Requirements

      • Type Check: Create a test file verifying that a plain object matching the NetAdapter interface can be passed to driverAdapters.
      • Runtime Check:
        • Instantiate new MongoClient() (no options). Assert that client['runtime'].net is strictly equal to the native require('net') module.
        • Instantiate new MongoClient(..., { driverAdapters: { net: mockNet }}). Assert that client['runtime'].net equals mockNet.

      Documentation Requirements

      • The driverAdapters property in MongoClientOptions must include the @experimental tag and a brief description.

      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

            Assignee:
            Unassigned
            Reporter:
            Sergey Zelenov
            None
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: