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

• TBD
  • We probably want to also bundle the driver into a single file as well, potentially reuse what we have in BSON using rollup.

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.