handle initially null driver when instantiating Mongoose for Rollup support #14577
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #12335
Summary
lib/index.js
andlib/mongoose.js
contain the significant changes here. The issue is that, because of how Rollup hoists imports when you don't setstrictRequires: true
, thesetDriver()
call inlib/mongoose.js
will always run after the Mongoose singleton is initialized inlib/index.js
. So the Mongoose constructor needs to handle null driver case, andlib/mongoose.js
needs to callsetDriver()
to make sure the driver change propagates to the newly created Mongoose singleton.In regular Node.js, that second
setDriver()
call is a no-op becausesetDriver()
checks to see if new driver is===
old driver.On a related note, I also cleaned up some circular imports in
lib/error/*.js
.lib/error/index.js
importslib/error/cast.js
andlib/error/cast.js
importslib/error/index.js
. I was trying to see if cleaning up circular imports would help with Rollup support, but experimentation and further reading convinced me that it wasn't necessary for Rollup support. But still a nice to have since fixing the circular import is a bunch of one-liners.Examples