Uploaded image for project: 'Node.js Driver'
  1. Node.js Driver
  2. NODE-6453

POC: Ship an es module formatted driver

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • 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?

      Use Case

      As a Node.js user of ES Modules
      I want my tree of dependencies to resolve consistently (avoid dual module hazard)
      So that when I import a module that has already been loaded it resolves to the same code making instanceOf work and constructors equal as expected.

      User Experience

      • What is the desired/expected outcome for the user once this ticket is implemented?
        • I can import 'bson' and import 'mongodb' and expect to have the same instance of ObjectId exported from both.
      • If bug: What is the number of impacted customers? How severe is the impact? Is anyone blocked or broken?
        • Anyone using es modules and importing the driver and bson separately

      Dependencies

      • A build tool.

      Risks/Unknowns

      • What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
        • Changing the import conditions of a package can be considered breaking, mongodb/lib/xxx.js will stop working unless we provide path conditions. However, haven't hesitated to change filenames or directory structures in the past, generally I believe we consider paths internal.
        • Doubling the size of the package potentially. Depends on the solution.
      • Is there an opportunity for better cross-driver alignment or testing in this area?
        • No, node specific.
      • Is there an opportunity to improve existing documentation on this subject?
        • Yes, we should have a docs page that helps cover this, or at least link to the Node docs on dual module hazard somewhere discoverable.

      Acceptance Criteria

      Implementation Requirements

      • POC and capture findings / path forward in a follow up ticket
        • We probably want to also bundle the driver into a single file as well, potentially reuse what we have in BSON using rollup.
      • Answer all open questions, in particular, determine whether this can be done efficiently in a nonbreaking way or if we want to wait for V7

      Testing Requirements

      • We should add tests to check the import expectations are met
      • We will continue to run our tests against the src code loaded by ts-node and the special require hack that supplants our current src with mongodb-legacy's dependence on the driver.

      Documentation Requirements

      • Add an FAQ section about salient details

      Follow Up Requirements

      • One day in the distant future, think about removing CJS.

            Assignee:
            Unassigned Unassigned
            Reporter:
            neal.beeken@mongodb.com Neal Beeken
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: