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.

As a Node driver engineer,
I want to ship an esmodule version of our driver,
So that we are keeping up with the direction that the community is moving.

User Experience

• n/a

Dependencies

• n/a

Open Questions

• To bundle the driver as an esmodule bundle - what tooling do we need / should we use?  What additional configuration is needed to support an ESM bundle?
• Should we bundle the driver into a single file?
• How will we handle optional dependencies?
• Can we only ship an esmodule bundle of the driver?  (consider: Node supports `require` of esmodules with no additional flags as of Node 22.12: https://nodejs.org/docs/latest-v22.x/api/modules.html#loading-ecmascript-modules-using-require:~:text=v23.0.0%2C%20v22.12.0,module%20CLI%20flag.  Should we wait to make this change until Node22 is our lowest supported Node version?).
  • If we ship esmodule only for the driver - should we also make this change for our supporting packages?
• 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.
• How will the proposed solution impact package size?
• What will our testing strategy be for an esmodule bundle?  This likely depends on whether or not we ship both cjs and esm. We want to make sure our code coverage tooling continues working, too.
• Are there any impacts of shipping ESM / only shipping ESM on devtools? 

Acceptance Criteria

Implementation Requirements

• Implement a POC that bundles the driver as an ESM module and ships it as a part of the package (confirm with npm pack + local install from tarball).  The POC should demonstrate:
  • general configuration (i.e., tooling and configuration needed to bundle)
  • handling of optional dependencies and lazy imports (suggestion: choose one optional dependency and focus on making it work as a POC)
  • confirm that the esmodule bundle is imported in esmodule environments and the dual package hazard is avoided with an esmodule bundle.
• In addition to the POC, investigate the open questions in this ticket and put together recommendations for the team.
• Discuss the POC and findings with the team and determine a path forward.

Testing Requirements

• n/a

Documentation Requirements

• n/a

Follow Up Requirements

• n/a