Uploaded image for project: 'Node.js Driver'
  1. Node.js Driver
  2. NODE-3996

Design: Automate Node.js native package releases

    • Type: Icon: Epic Epic
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Hide
      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?
      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?
    • To Do
    • Bundle binaries in npm releases
    • 100

      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

            Assignee:
            neal.beeken@mongodb.com Neal Beeken
            Reporter:
            neal.beeken@mongodb.com Neal Beeken
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: