Use Case

As a user of the mongodb driver I do not want the friction of managing optional dependencies so that I can spin up the driver quickly and seamlessly.

As an npm user I believe packages should avoid post-install scripts whenever possible to keep the opportunity for running code on install to a minimum.

As a driver engineer I want to remove optional dependency handling logic from our driver and enable us to manage "optional" dependency versions ourselves.

User Impact

Users would no longer need to install kerberos/FLE (or maybe zstd soon) as a separate dependency of their own project, the driver would come ready to use those native features. Those that don't work on systems that support those features would not get errors unless they enabled the features.

Dependencies

• FLE
• Kerberos
• zstd
• snappy - we don't control the snappy dependency, maybe we could ask the author what they think of this methodology, or we can distribute our own version.

Unknowns

• Is it okay if we no longer automatically compile if the system is unsupported?
  • Instead of a postinstall script that will automatically try to compile, we could provide users with a guaranteed package script that performs compilation. Seems equal friction to the previous need of managing the dependency version yourself.

Acceptance Criteria

Implementation Requirements

• CI work, each build variant needs to compile and upload a binary .node file to S3 from evergreen. A final task will download all posted binaries and run npm publish. The tar file will contain the JS code / CPP source / binaries for each system we support.
• Code work, in order to do with within a major version we can leave the existing entrypoint lib/index.js essentially the same. we can make a new one for our driver to use that will lazily import the native binary when asked (through a getter etc.). Then our driver can always depend on FLE for example but it won't throw an import error on unsupported systems if someone isn't using it.

Testing Requirements

• unit test, spec test sync, etc

Documentation Requirements

• DOCSP ticket, API docs, etc

Follow Up Requirements

• additional tickets to file, required releases, etc