Upgrade mongodb (bson) dependency to avoid BSONVersionError with newer mongodb driver versions

Node version: 20.20.2 Sails version (sails): - ORM hook version (sails-hook-orm): - Sockets hook version (sails-hook-sockets): - Organics hook version (sails-hook-organics): - Grunt hook version (sails-hook-grunt): - Uploads hook version (sails-hook-uploads): - DB adapter & version (e.g. [email protected]): "sails-mongo": "2.1.2" Skipper adapter & version (e.g. [email protected]): - mongodb version (app-level, alongside sails-mongo's bundled driver): "mongodb": "7.6.0"

Hi all !

Here is the problem:

[email protected] still pins its own copy of the MongoDB driver to "mongodb": "6.3.0", which resolves bson to 6.10.4. In a Node.js app that also depends directly on a newer mongodb driver (e.g. [email protected], which resolves [email protected]) for code that doesn't go through Waterline, we end up with two different major versions of bson in the dependency tree at the same time.

Since bson v6, every BSON type (ObjectId, etc.) is tagged with the version of bson that created it, and the driver validates that tag at runtime. When a BSON value created via the app-level mongodb/bson package is passed into a query that gets executed through sails-mongo's Waterline adapter (bundling its own older bson), the version check fails:

09/09/2026, 3:33:42 PM   ERROR [Errors.GET] Error when calling /api/someroute by some@user: Unsupported BSON version, bson types must be from bson 6.x.x
BSONVersionError: Unsupported BSON version, bson types must be from bson 6.x.x

This is easy to hit in any project that uses Waterline/sails-mongo for its models but also imports mongodb directly elsewhere (a very common pattern once a project outgrows plain Waterline queries, e.g. to build native ObjectIds, run aggregations, or use driver features Waterline doesn't expose). Because npm/yarn will happily hoist two different majors of bson side by side, this doesn't show up until the two code paths interact on the same BSON value.

Workaround on our side for now: avoid constructing ObjectId via the app-level mongodb package for anything that flows through a Waterline model, and let sails-mongo cast plain string ids itself. But that's fragile and easy to reintroduce by accident.

Would it be possible to bump sails-mongo's mongodb dependency to track a current driver major (7.x)? Happy to help test against our app, or to contribute a PR bumping the dependency and running the adapter test suite against it if that's welcome.

Thank you and regards