-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
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.
- is depended on by
-
NODE-6443 instanceof checks don't work when mongodb and bson are used together in ESM project
- Blocked