Fix 654 Support Alternative URLs with Production/Staging/Development Hosts Options

Overview

This pull request enables the use of alternative s3 urls (path style) and s3-compatible backends (e.g. min.io) in conjunction with the development_host, staging_host and production_host options. It fixes #654.

The change in this pull request is non-breaking. It is fully backwards compatible with current way of defining hosts (as string) and bucket/region (as properties of binary).

This pull request comes "on top" of (i.e. includes changes from) #655 (which in turn comes "on top" of #652, which is "on top" of #651, which is "on top" of #648, #649, #650. It's pull requests all the ay down 🐢🐢🐢🐢😉).

Change

Moving forward hosts will be defined as an object with one required property endpoint and additional optional properties: bucket region and s3ForcePathStyle.

Example 1: (S3 Virtual Host URL)

{
  "binary": {
    "host": {
      "endpoint": "https://a-bucket.s3.us-east-1.amazonaws.com",
    }
  }
}

Example 2: (Path Style alternative host)

{
  "binary": {
    "host": {
      "endpoint": "https://play.min.io",
      "bucket": "node-pre-gyp-production",
      "region": "us-east-1",
      "s3ForcePathStyle": true
    }
  }
}

Example 3: (Utilizing Staging/Development)

{
  "binary": {
    "host": {
      "endpoint": "https://my-production-bucket.s3.us-east-1.amazonaws.com",
    },
    "staging_host": {
      "endpoint": "https://play.min.io",
      "bucket": "node-pre-gyp-staging",
      "region": "us-east-1",
      "s3ForcePathStyle": true
    },
  }
}

{
  "binary": {
    "host": {
      "endpoint": "https://dns.over.some.bucket.example.com",
      "bucket": "the.real.bucket.name",
      "region": "us-east-1",
      "s3ForcePathStyle": true
    },
    "staging_host": {
      "endpoint": "https://my-staging-bucket.s3.us-east-1.amazonaws.com",
    },
    "development_host": {
      "endpoint": "https://play.min.io",
      "bucket": "temp-dev-bucket",
      "region": "us-east-1",
      "s3ForcePathStyle": true
    }
  }
}

Note: the object keys are the same as the ones passed to the AWS sdk.

Backwards compatibility

Existing string definitions and existing keys are still supported.

Example 1: (S3 Virtual Host URL)

{
  "binary": {
    "host": "https://a-bucket.s3.us-east-1.amazonaws.com",
  }
}

Example 2: (Alternative S3 URL)

{
  "binary": {
    "host": "https://play.min.io",
    "bucket": "node-pre-gyp-production",
    "region": "us-east-1",
    "s3ForcePathStyle": true
  }
}

Example 3: (Utilizing Staging/Production for S3 Virtual Host URL)

{
  "binary": {
    "staging_host": "https://npg-bucket-staging.s3.us-east-1.amazonaws.com",
    "production_host": "https://npg-bucket-production.s3.us-east-1.amazonaws.com"
  }
}

Implementation

Implementation attempts to limit code changes. There was no refactoring done, not even in the vicinity of changed code.
Backwards compatibility is archived by adding standarize_config function to versioning. The function is called by validate_config (exported) and mutates the object holding the parsed package.json, so that any hosts (host, staging_host, development_host) are defined as objects with an endpoint key, rather than strings.
versioning.evaluate (exported) was adapted to work with object format of the hosts.

Tests

Added app1.3 - identical to app1 but using host, staging_host and development_host configuration with an object.
Testing of versioning was expanded and refactored.
All tests pass

mapbox / node-pre-gyp