muhammara 1.8.0 → 2.1.0

package/CHANGELOG.md

@@ -7,6 +7,49 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 ## [Unreleased]
 
+## [2.1.0] - 2021-12-03
+
+### Added
+
+- Electron versions: 16.0, 15.3, 15.2, 14.2, 13.6, 13.3
+
+## [2.0.0] - 2021-10-22
+
+### Removed
+
+- Electron 2.0.7
+- Node 6.14.1 and 7.10.1
+
+### Added
+
+- Add Electron 13.3.0
+- Documentation (copy of  the wiki)
+- Add Electron 13.2.3
+- Add Electron 13.5.0
+- Add Electron 14.0.1
+- Add Electron 14.1.0
+- Add Electron 15.0.0
+- Add Electron 15.1.2
+- Add Node 16.11.1
+
+### Fixed
+
+- Dependency to node-pre-gyp moved from deprecated to scoped package
+
+## [1.10.0] - 2021-07-12
+
+### Added
+
+- Add Electron 13.1
+- Disable NEON on arm builds
+
+## [1.9.0] - 2021-06-30
+
+### Fixed
+
+* Yarn v2 incompatibiliy
+* Build issues on mac OS big sur
+
 ## [1.8.0] - 2021-05-28
 
 ### Added
@@ -152,7 +195,11 @@ with the following changes.
 
 * Initial release
 
-[Unreleased]: https://github.com/julianhille/MuhammaraJS/compare/1.8.0...HEAD
+[Unreleased]: https://github.com/julianhille/MuhammaraJS/compare/2.1.0...HEAD
+[2.1.0]: https://github.com/julianhille/MuhammaraJS/compare/2.0.0...2.1.0
+[2.0.0]: https://github.com/julianhille/MuhammaraJS/compare/1.10.0...2.0.0
+[1.10.0]: https://github.com/julianhille/MuhammaraJS/compare/1.9.0...1.10.0
+[1.9.0]: https://github.com/julianhille/MuhammaraJS/compare/1.8.0...1.9.0
 [1.8.0]: https://github.com/julianhille/MuhammaraJS/compare/1.7.0...1.8.0
 [1.7.0]: https://github.com/julianhille/MuhammaraJS/compare/1.6.0...1.7.0
 [1.6.0]: https://github.com/julianhille/MuhammaraJS/compare/1.5.1...1.6.0

package/README.md

@@ -17,6 +17,11 @@ Project site is [here](http://www.pdfhummus.com).
 
 If you are looking for a C++ Library go [here](https://github.com/galkahana/PDF-Writer).
 
+# Caution
+
+Version 2.0 will be incompatible with some older node and
+electron versions because we needed to upgrade node-pre-gyp.
+
 # Installation
 
 ```
@@ -37,3 +42,7 @@ With:
 ```
 let muhammara = require('muhammara')
 ```
+
+# Documentation
+
+You can find samples and documentation [here](./docs/Home.md)

package/muhammara.js

@@ -1,6 +1,6 @@
 var fs = require('fs');
 var path = require('path');
-var pregyp = require('node-pre-gyp');
+var pregyp = require('@mapbox/node-pre-gyp');
 var binding_path = pregyp.find(path.resolve(path.join(__dirname,'./package.json')));
 var muhammara = module.exports = require(binding_path);
 var EventEmitter = require('events').EventEmitter;

package/node_modules/{node-pre-gyp → @mapbox/node-pre-gyp}/CHANGELOG.md

@@ -1,5 +1,45 @@
 # node-pre-gyp changelog
 
+## 1.0.7
+- Upgraded nyc and npmlog to address https://github.com/advisories/GHSA-93q8-gq69-wqmw
+
+## 1.0.6
+- Added node v17 to the internal node releases listing
+- Upgraded various dependencies declared in package.json to latest major versions (node-fetch from 2.6.1 to 2.6.5, npmlog from 4.1.2 to 5.01, semver from 7.3.4 to 7.3.5, and tar from 6.1.0 to 6.1.11)
+- Fixed bug in `staging_host` parameter (https://github.com/mapbox/node-pre-gyp/pull/590)
+
+
+## 1.0.5
+- Fix circular reference warning with node >= v14
+
+## 1.0.4
+- Added node v16 to the internal node releases listing
+
+## 1.0.3
+- Improved support configuring s3 uploads (solves https://github.com/mapbox/node-pre-gyp/issues/571)
+  - New options added in https://github.com/mapbox/node-pre-gyp/pull/576: 'bucket', 'region', and `s3ForcePathStyle`
+
+## 1.0.2
+- Fixed regression in proxy support (https://github.com/mapbox/node-pre-gyp/issues/572)
+
+## 1.0.1
+- Switched from mkdirp@1.0.4 to make-dir@3.1.0 to avoid this bug: https://github.com/isaacs/node-mkdirp/issues/31
+
+## 1.0.0
+- Module is now name-spaced at `@mapbox/node-pre-gyp` and the original `node-pre-gyp` is deprecated.
+- New: support for staging and production s3 targets (see README.md)
+- BREAKING: no longer supporting `node_pre_gyp_accessKeyId` & `node_pre_gyp_secretAccessKey`, use `AWS_ACCESS_KEY_ID` & `AWS_SECRET_ACCESS_KEY` instead to authenticate against s3 for `info`, `publish`, and `unpublish` commands.
+- Dropped node v6 support, added node v14 support
+- Switched tests to use mapbox-owned bucket for testing
+- Added coverage tracking and linting with eslint
+- Added back support for symlinks inside the tarball
+- Upgraded all test apps to N-API/node-addon-api
+- New: support for staging and production s3 targets (see README.md)
+- Added `node_pre_gyp_s3_host` env var which has priority over the `--s3_host` option or default.
+- Replaced needle with node-fetch
+- Added proxy support for node-fetch
+- Upgraded to mkdirp@1.x
+
 ## 0.17.0
 - Got travis + appveyor green again
 - Added support for more node versions

package/node_modules/{node-pre-gyp → @mapbox/node-pre-gyp}/README.md

@@ -1,17 +1,26 @@
-# node-pre-gyp
+# @mapbox/node-pre-gyp
 
-#### node-pre-gyp makes it easy to publish and install Node.js C++ addons from binaries
+#### @mapbox/node-pre-gyp makes it easy to publish and install Node.js C++ addons from binaries
 
 [![Build Status](https://travis-ci.com/mapbox/node-pre-gyp.svg?branch=master)](https://travis-ci.com/mapbox/node-pre-gyp)
 [![Build status](https://ci.appveyor.com/api/projects/status/3nxewb425y83c0gv)](https://ci.appveyor.com/project/Mapbox/node-pre-gyp)
 
-`node-pre-gyp` stands between [npm](https://github.com/npm/npm) and [node-gyp](https://github.com/Tootallnate/node-gyp) and offers a cross-platform method of binary deployment.
+`@mapbox/node-pre-gyp` stands between [npm](https://github.com/npm/npm) and [node-gyp](https://github.com/Tootallnate/node-gyp) and offers a cross-platform method of binary deployment.
+
+### Special note on previous package
+
+On Feb 9th, 2021 `@mapbox/node-pre-gyp@1.0.0` was [released](./CHANGELOG.md). Older, unscoped versions that are not part of the `@mapbox` org are deprecated and only `@mapbox/node-pre-gyp` will see updates going forward. To upgrade to the new package do:
+
+```
+npm uninstall node-pre-gyp --save
+npm install @mapbox/node-pre-gyp --save
+```
 
 ### Features
 
  - A command line tool called `node-pre-gyp` that can install your package's C++ module from a binary.
  - A variety of developer targeted commands for packaging, testing, and publishing binaries.
- - A JavaScript module that can dynamically require your installed binary: `require('node-pre-gyp').find`
+ - A JavaScript module that can dynamically require your installed binary: `require('@mapbox/node-pre-gyp').find`
 
 For a hello world example of a module packaged with `node-pre-gyp` see <https://github.com/springmeyer/node-addon-example> and [the wiki ](https://github.com/mapbox/node-pre-gyp/wiki/Modules-using-node-pre-gyp) for real world examples.
 
@@ -27,7 +36,7 @@ See the [Frequently Ask Questions](https://github.com/mapbox/node-pre-gyp/wiki/F
 
 ## Depends
 
- - Node.js >= node v6.x
+ - Node.js >= node v8.x
 
 ## Install
 
@@ -37,7 +46,7 @@ See the [Frequently Ask Questions](https://github.com/mapbox/node-pre-gyp/wiki/F
 
 But you can also install it globally:
 
-    npm install node-pre-gyp -g
+    npm install @mapbox/node-pre-gyp -g
 
 ## Usage
 
@@ -89,7 +98,7 @@ This is a guide to configuring your module to use node-pre-gyp.
 
 #### 1) Add new entries to your `package.json`
 
- - Add `node-pre-gyp` to `dependencies`
+ - Add `@mapbox/node-pre-gyp` to `dependencies`
  - Add `aws-sdk` as a `devDependency`
  - Add a custom `install` script
  - Declare a `binary` object
@@ -98,7 +107,7 @@ This looks like:
 
 ```js
     "dependencies"  : {
-      "node-pre-gyp": "0.6.x"
+      "@mapbox/node-pre-gyp": "1.x"
     },
     "devDependencies": {
       "aws-sdk": "2.x"
@@ -122,7 +131,7 @@ Let's break this down:
  - Your `scripts` section should override the `install` target with `"install": "node-pre-gyp install --fallback-to-build"`. This allows node-pre-gyp to be used instead of the default npm behavior of always source compiling with `node-gyp` directly.
  - Your package.json should contain a `binary` section describing key properties you provide to allow node-pre-gyp to package optimally. They are detailed below.
 
-Note: in the past we recommended putting `node-pre-gyp` in the `bundledDependencies`, but we no longer recommend this. In the past there were npm bugs (with node versions 0.10.x) that could lead to node-pre-gyp not being available at the right time during install (unless we bundled). This should no longer be the case. Also, for a time we recommended using `"preinstall": "npm install node-pre-gyp"` as an alternative method to avoid needing to bundle. But this did not behave predictably across all npm versions - see https://github.com/mapbox/node-pre-gyp/issues/260 for the details. So we do not recommend using `preinstall` to install `node-pre-gyp`. More history on this at https://github.com/strongloop/fsevents/issues/157#issuecomment-265545908.
+Note: in the past we recommended putting `@mapbox/node-pre-gyp` in the `bundledDependencies`, but we no longer recommend this. In the past there were npm bugs (with node versions 0.10.x) that could lead to node-pre-gyp not being available at the right time during install (unless we bundled). This should no longer be the case. Also, for a time we recommended using `"preinstall": "npm install @mapbox/node-pre-gyp"` as an alternative method to avoid needing to bundle. But this did not behave predictably across all npm versions - see https://github.com/mapbox/node-pre-gyp/issues/260 for the details. So we do not recommend using `preinstall` to install `@mapbox/node-pre-gyp`. More history on this at https://github.com/strongloop/fsevents/issues/157#issuecomment-265545908.
 
 ##### The `binary` object has three required properties
 
@@ -154,7 +163,27 @@ Why then not require S3? Because while some applications using node-pre-gyp need
 
 It should also be mentioned that there is an optional and entirely separate npm module called [node-pre-gyp-github](https://github.com/bchr02/node-pre-gyp-github) which is intended to complement node-pre-gyp and be installed along with it. It provides the ability to store and publish your binaries within your repositories GitHub Releases if you would rather not use S3 directly. Installation and usage instructions can be found [here](https://github.com/bchr02/node-pre-gyp-github), but the basic premise is that instead of using the ```node-pre-gyp publish``` command you would use ```node-pre-gyp-github publish```.
 
-##### The `binary` object has two optional properties
+##### The `binary` object other optional S3 properties
+
+If you are not using a standard s3 path like `bucket_name.s3(.-)region.amazonaws.com`, you might get an error on `publish` because node-pre-gyp extracts the region and bucket from the `host` url. For example, you may have an on-premises s3-compatible storage  server, or may have configured a specific dns redirecting to an s3  endpoint. In these cases, you can explicitly set the `region` and `bucket` properties to tell node-pre-gyp to use these values instead of guessing from the `host` property. The following values can be used in the `binary` section:
+
+###### host
+
+The url to the remote server root location (must be `https` not `http`).
+
+###### bucket
+
+The bucket name where your tarball binaries should be located.
+
+###### region
+
+Your S3 server region.
+
+###### s3ForcePathStyle
+
+Set `s3ForcePathStyle` to true if the endpoint url should not be prefixed with the bucket name. If false (default), the server endpoint would be  constructed as `bucket_name.your_server.com`.
+
+##### The `binary` object has optional properties
 
 ###### remote_path
 
@@ -215,7 +244,7 @@ var bindings = require('./bindings')
 Change those lines to:
 
 ```js
-var binary = require('node-pre-gyp');
+var binary = require('@mapbox/node-pre-gyp');
 var path = require('path');
 var binding_path = binary.find(path.resolve(path.join(__dirname,'./package.json')));
 var binding = require(binding_path);
@@ -279,17 +308,42 @@ What will happen is this:
 
 If a a binary was not available for a given platform and `--fallback-to-build` was used then `node-gyp rebuild` will be called to try to source compile the module.
 
-## N-API Considerations
+#### 9) One more option
+
+It may be that you want to work with two s3 buckets, one for staging and one for production; this
+arrangement makes it less likely to accidentally overwrite a production binary. It also allows the production
+environment to have more restrictive permissions than staging while still enabling publishing when
+developing and testing.
+
+The binary.host property can be set at execution time. In order to do so all of the following conditions
+must be true.
+
+- binary.host is falsey or not present
+- binary.staging_host is not empty
+- binary.production_host is not empty
+
+If any of these checks fail then the operation will not perform execution time determination of the s3 target.
+
+If the command being executed is either "publish" or "unpublish" then the default is set to `binary.staging_host`. In all other cases
+the default is `binary.production_host`.
+
+The command-line options `--s3_host=staging` or `--s3_host=production` override the default. If `s3_host`
+is present and not `staging` or `production` an exception is thrown.
+
+This allows installing from staging by specifying `--s3_host=staging`. And it requires specifying
+`--s3_option=production` in order to publish to, or unpublish from, production, making accidental errors less likely.
 
-[N-API](https://nodejs.org/api/n-api.html#n_api_n_api) is an ABI-stable alternative to previous technologies such as [nan](https://github.com/nodejs/nan) which are tied to a specific Node runtime engine. N-API is Node runtime engine agnostic and guarantees modules created today will continue to run, without changes, into the future.
+## Node-API Considerations
 
-Using `node-pre-gyp` with N-API projects requires a handful of additional configuration values and imposes some additional requirements.
+[Node-API](https://nodejs.org/api/n-api.html#n_api_node_api), which was previously known as N-API, is an ABI-stable alternative to previous technologies such as [nan](https://github.com/nodejs/nan) which are tied to a specific Node runtime engine. Node-API is Node runtime engine agnostic and guarantees modules created today will continue to run, without changes, into the future.
 
-The most significant difference is that an N-API module can be coded to target multiple  N-API versions. Therefore, an N-API module must declare in its `package.json` file which N-API versions the module is designed to run against. In addition, since multiple builds may be required for a single module, path and file names must be specified in way that avoids naming conflicts.
+Using `node-pre-gyp` with Node-API projects requires a handful of additional configuration values and imposes some additional requirements.
+
+The most significant difference is that an Node-API module can be coded to target multiple  Node-API versions. Therefore, an Node-API module must declare in its `package.json` file which Node-API versions the module is designed to run against. In addition, since multiple builds may be required for a single module, path and file names must be specified in way that avoids naming conflicts.
 
 ### The `napi_versions` array property
 
-An N-API modules must declare in its `package.json` file, the N-API versions the module is intended to support. This is accomplished by including an `napi-versions` array property in the `binary` object. For example:
+A Node-API module must declare in its `package.json` file, the Node-API versions the module is intended to support. This is accomplished by including an `napi-versions` array property in the `binary` object. For example:
 
 ```js
 "binary": {
@@ -300,17 +354,17 @@ An N-API modules must declare in its `package.json` file, the N-API versions the
   }
 ```
 
-If the `napi_versions` array property is *not* present, `node-pre-gyp` operates as it always has. Including the `napi_versions` array property instructs `node-pre-gyp` that this is a N-API module build.
+If the `napi_versions` array property is *not* present, `node-pre-gyp` operates as it always has. Including the `napi_versions` array property instructs `node-pre-gyp` that this is a Node-API module build.
 
-When the `napi_versions` array property is present, `node-pre-gyp` fires off multiple operations, one for each of the N-API versions in the array. In the example above, two operations are initiated, one for N-API version 1 and second for N-API version 3. How this version number is communicated is described next.
+When the `napi_versions` array property is present, `node-pre-gyp` fires off multiple operations, one for each of the Node-API versions in the array. In the example above, two operations are initiated, one for Node-API version 1 and second for Node-API version 3. How this version number is communicated is described next.
 
 ### The `napi_build_version` value
 
-For each of the N-API module operations `node-pre-gyp` initiates, it ensures that the `napi_build_version` is set appropriately.
+For each of the Node-API module operations `node-pre-gyp` initiates, it ensures that the `napi_build_version` is set appropriately.
 
 This value is of importance in two areas:
 
-1. The C/C++ code which needs to know against which N-API version it should compile.
+1. The C/C++ code which needs to know against which Node-API version it should compile.
 2. `node-pre-gyp` itself which must assign appropriate path and file names to avoid collisions.
 
 ### Defining `NAPI_VERSION` for the C/C++ code
@@ -325,13 +379,13 @@ The `napi_build_version` value is communicated to the C/C++ code by adding this
 
 This ensures that `NAPI_VERSION`, an integer value, is declared appropriately to the C/C++ code for each build.
 
-> Note that earlier versions of this document recommended defining the symbol `NAPI_BUILD_VERSION`. `NAPI_VERSION` is prefered because it used by the N-API C/C++ headers to configure the specific N-API veriosn being requested. 
+> Note that earlier versions of this document recommended defining the symbol `NAPI_BUILD_VERSION`. `NAPI_VERSION` is preferred because it used by the Node-API C/C++ headers to configure the specific Node-API versions being requested.
 
 ### Path and file naming requirements in `package.json`
 
 Since `node-pre-gyp` fires off multiple operations for each request, it is essential that path and file names be created in such a way as to avoid collisions. This is accomplished by imposing additional path and file naming requirements.
 
-Specifically, when performing N-API builds, the `{napi_build_version}` text configuration value  *must* be present in the `module_path` property. In addition, the `{napi_build_version}` text configuration value  *must* be present in either the `remote_path` or `package_name` property. (No problem if it's in both.)
+Specifically, when performing Node-API builds, the `{napi_build_version}` text configuration value  *must* be present in the `module_path` property. In addition, the `{napi_build_version}` text configuration value  *must* be present in either the `remote_path` or `package_name` property. (No problem if it's in both.)
 
 Here's an example:
 
@@ -346,15 +400,15 @@ Here's an example:
   }
 ```
 
-## Supporting both N-API and NAN builds
+## Supporting both Node-API and NAN builds
 
-You may have a legacy native add-on that you wish to continue supporting for those versions of Node that do not support N-API, as you add N-API support for later Node versions. This can be accomplished by specifying the `node_napi_label` configuration value in the package.json `binary.package_name` property. 
+You may have a legacy native add-on that you wish to continue supporting for those versions of Node that do not support Node-API, as you add Node-API support for later Node versions. This can be accomplished by specifying the `node_napi_label` configuration value in the package.json `binary.package_name` property.
 
-Placing the configuration value `node_napi_label` in the package.json `binary.package_name` property instructs `node-pre-gyp` to build all viable N-API binaries supported by the current Node instance. If the current Node instance does not support N-API, `node-pre-gyp` will request a traditional, non-N-API build. 
+Placing the configuration value `node_napi_label` in the package.json `binary.package_name` property instructs `node-pre-gyp` to build all viable Node-API binaries supported by the current Node instance. If the current Node instance does not support Node-API, `node-pre-gyp` will request a traditional, non-Node-API build.
 
-The configuration value `node_napi_label` is set by `node-pre-gyp` to the type of build created, `napi` or `node`, and the version number. For N-API builds, the string contains the N-API version nad has values like `napi-v3`. For traditional, non-N-API builds, the string contains the ABI version with values like `node-v46`.
+The configuration value `node_napi_label` is set by `node-pre-gyp` to the type of build created, `napi` or `node`, and the version number. For Node-API builds, the string contains the Node-API version nad has values like `napi-v3`. For traditional, non-Node-API builds, the string contains the ABI version with values like `node-v46`.
 
-Here's how the `binary` configuration above might be changed to support both N-API and NAN builds:
+Here's how the `binary` configuration above might be changed to support both Node-API and NAN builds:
 
 ```js
 "binary": {
@@ -367,13 +421,13 @@ Here's how the `binary` configuration above might be changed to support both N-A
   }
 ```
 
-The C/C++ symbol `NAPI_VERSION` can be used to distinguish N-API and non-N-API builds. The value of `NAPI_VERSION` is set to the integer N-API version for N-API builds and is set to `0` for non-N-API builds. 
+The C/C++ symbol `NAPI_VERSION` can be used to distinguish Node-API and non-Node-API builds. The value of `NAPI_VERSION` is set to the integer Node-API version for Node-API builds and is set to `0` for non-Node-API builds.
 
 For example:
- 
+
 ```C
 #if NAPI_VERSION
-// N-API code goes here
+// Node-API code goes here
 #else
 // NAN code goes here
 #endif
@@ -383,7 +437,7 @@ For example:
 
 The following two configuration values, which were implemented in previous versions of `node-pre-gyp`, continue to exist, but have been replaced by the `node_napi_label` configuration value described above.
 
-1. `napi_version` If N-API is supported by the currently executing Node instance, this value is the N-API version number supported by Node. If N-API is not supported, this value is an empty string.
+1. `napi_version` If Node-API is supported by the currently executing Node instance, this value is the Node-API version number supported by Node. If Node-API is not supported, this value is an empty string.
 
 2. `node_abi_napi` If the value returned for `napi_version` is non empty, this value is `'napi'`. If the value returned for `napi_version` is empty, this value is the value returned for `node_abi`.
 
@@ -399,28 +453,37 @@ First, get setup locally and test the workflow:
 
 And have your **key** and **secret key** ready for writing to the bucket.
 
-It is recommended to create a IAM user with a policy that only gives permissions to the specific bucket you plan to publish to. This can be done in the [IAM console](https://console.aws.amazon.com/iam/) by: 1) adding a new user, 2) choosing `Attach User Policy`, 3) Using the `Policy Generator`, 4) selecting `Amazon S3` for the service, 5) adding the actions: `DeleteObject`, `GetObject`, `GetObjectAcl`, `ListBucket`, `PutObject`, `PutObjectAcl`, 6) adding an ARN of `arn:aws:s3:::bucket/*` (replacing `bucket` with your bucket name), and finally 7) clicking `Add Statement` and saving the policy. It should generate a policy like:
+It is recommended to create a IAM user with a policy that only gives permissions to the specific bucket you plan to publish to. This can be done in the [IAM console](https://console.aws.amazon.com/iam/) by: 1) adding a new user, 2) choosing `Attach User Policy`, 3) Using the `Policy Generator`, 4) selecting `Amazon S3` for the service, 5) adding the actions: `DeleteObject`, `GetObject`, `GetObjectAcl`, `ListBucket`, `HeadBucket`, `PutObject`, `PutObjectAcl`, 6) adding an ARN of `arn:aws:s3:::bucket/*` (replacing `bucket` with your bucket name), and finally 7) clicking `Add Statement` and saving the policy. It should generate a policy like:
 
 ```js
 {
-  "Version": "2012-10-17",
-  "Statement": [
-    {
-      "Sid": "Stmt1394587197000",
-      "Effect": "Allow",
-      "Action": [
-        "s3:DeleteObject",
-        "s3:GetObject",
-        "s3:GetObjectAcl",
-        "s3:ListBucket",
-        "s3:PutObject",
-        "s3:PutObjectAcl"
-      ],
-      "Resource": [
-        "arn:aws:s3:::node-pre-gyp-tests/*"
-      ]
-    }
-  ]
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Sid": "objects",
+            "Effect": "Allow",
+            "Action": [
+                "s3:PutObject",
+                "s3:GetObjectAcl",
+                "s3:GetObject",
+                "s3:DeleteObject",
+                "s3:PutObjectAcl"
+            ],
+            "Resource": "arn:aws:s3:::your-bucket-name/*"
+        },
+        {
+            "Sid": "bucket",
+            "Effect": "Allow",
+            "Action": "s3:ListBucket",
+            "Resource": "arn:aws:s3:::your-bucket-name"
+        },
+        {
+            "Sid": "buckets",
+            "Effect": "Allow",
+            "Action": "s3:HeadBucket",
+            "Resource": "*"
+        }
+    ]
 }
 ```
 
@@ -436,29 +499,12 @@ Or put the local version on your PATH
 
 #### 3) Configure AWS credentials
 
-There are several ways to do this.
+It is recommended to configure the AWS JS SDK v2 used internally by `node-pre-gyp` by setting these environment variables:
 
-You can use any of the methods described at http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/node-configuring.html.
+- AWS_ACCESS_KEY_ID
+- AWS_SECRET_ACCESS_KEY
 
-Or you can create a `~/.node_pre_gyprc`
-
-Or pass options in any way supported by [RC](https://github.com/dominictarr/rc#standards)
-
-A `~/.node_pre_gyprc` looks like:
-
-```js
-{
-    "accessKeyId": "xxx",
-    "secretAccessKey": "xxx"
-}
-```
-
-Another way is to use your environment:
-
-    export node_pre_gyp_accessKeyId=xxx
-    export node_pre_gyp_secretAccessKey=xxx
-
-You may also need to specify the `region` if it is not explicit in the `host` value you use. The `bucket` can also be specified but it is optional because `node-pre-gyp` will detect it from the `host` value.
+But also you can also use the `Shared Config File` mentioned [in the AWS JS SDK v2 docs](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/configuring-the-jssdk.html)
 
 #### 4) Package and publish your build
 
@@ -504,9 +550,9 @@ Then paste the result into your `appveyor.yml`
 
 ```yml
 environment:
-  node_pre_gyp_accessKeyId:
+  AWS_ACCESS_KEY_ID:
     secure: Dn9HKdLNYvDgPdQOzRq/DqZ/MPhjknRHB1o+/lVU8MA=
-  node_pre_gyp_secretAccessKey:
+  AWS_SECRET_ACCESS_KEY:
     secure: W1rwNoSnOku1r+28gnoufO8UA8iWADmL1LiiwH9IOkIVhDTNGdGPJqAlLjNqwLnL
 ```
 
@@ -552,8 +598,8 @@ Make sure you run this command from within the directory of your module.
 
 Use `travis-encrypt` like:
 
-    travis encrypt node_pre_gyp_accessKeyId=${node_pre_gyp_accessKeyId}
-    travis encrypt node_pre_gyp_secretAccessKey=${node_pre_gyp_secretAccessKey}
+    travis encrypt AWS_ACCESS_KEY_ID=${node_pre_gyp_accessKeyId}
+    travis encrypt AWS_SECRET_ACCESS_KEY=${node_pre_gyp_secretAccessKey}
 
 Then put those values in your `.travis.yml` like:
 
@@ -681,10 +727,16 @@ The options are visible in the code at <https://github.com/mapbox/node-pre-gyp/b
 
 S3 is broken in China for the well known reason.
 
-Using the `npm` config argument: `--{module_name}_binary_host_mirror` can download binary files through a mirror.
+Using the `npm` config argument: `--{module_name}_binary_host_mirror` can download binary files through a mirror, `-` in `module_name` will be replaced with `_`.
 
 e.g.: Install [v8-profiler](https://www.npmjs.com/package/v8-profiler) from `npm`.
 
 ```bash
 $ npm install v8-profiler --profiler_binary_host_mirror=https://npm.taobao.org/mirrors/node-inspector/
 ```
+
+e.g.: Install [canvas-prebuilt](https://www.npmjs.com/package/canvas-prebuilt) from `npm`.
+
+```bash
+$ npm install canvas-prebuilt --canvas_prebuilt_binary_host_mirror=https://npm.taobao.org/mirrors/canvas-prebuilt/
+```

package/node_modules/@mapbox/node-pre-gyp/bin/node-pre-gyp

@@ -0,0 +1,4 @@
+#!/usr/bin/env node
+'use strict';
+
+require('../lib/main');

package/node_modules/@mapbox/node-pre-gyp/lib/build.js

@@ -0,0 +1,51 @@
+'use strict';
+
+module.exports = exports = build;
+
+exports.usage = 'Attempts to compile the module by dispatching to node-gyp or nw-gyp';
+
+const napi = require('./util/napi.js');
+const compile = require('./util/compile.js');
+const handle_gyp_opts = require('./util/handle_gyp_opts.js');
+const configure = require('./configure.js');
+
+function do_build(gyp, argv, callback) {
+  handle_gyp_opts(gyp, argv, (err, result) => {
+    let final_args = ['build'].concat(result.gyp).concat(result.pre);
+    if (result.unparsed.length > 0) {
+      final_args = final_args.
+        concat(['--']).
+        concat(result.unparsed);
+    }
+    if (!err && result.opts.napi_build_version) {
+      napi.swap_build_dir_in(result.opts.napi_build_version);
+    }
+    compile.run_gyp(final_args, result.opts, (err2) => {
+      if (result.opts.napi_build_version) {
+        napi.swap_build_dir_out(result.opts.napi_build_version);
+      }
+      return callback(err2);
+    });
+  });
+}
+
+function build(gyp, argv, callback) {
+
+  // Form up commands to pass to node-gyp:
+  // We map `node-pre-gyp build` to `node-gyp configure build` so that we do not
+  // trigger a clean and therefore do not pay the penalty of a full recompile
+  if (argv.length && (argv.indexOf('rebuild') > -1)) {
+    argv.shift(); // remove `rebuild`
+    // here we map `node-pre-gyp rebuild` to `node-gyp rebuild` which internally means
+    // "clean + configure + build" and triggers a full recompile
+    compile.run_gyp(['clean'], {}, (err3) => {
+      if (err3) return callback(err3);
+      configure(gyp, argv, (err4) => {
+        if (err4) return callback(err4);
+        return do_build(gyp, argv, callback);
+      });
+    });
+  } else {
+    return do_build(gyp, argv, callback);
+  }
+}

package/node_modules/@mapbox/node-pre-gyp/lib/clean.js

@@ -0,0 +1,31 @@
+'use strict';
+
+module.exports = exports = clean;
+
+exports.usage = 'Removes the entire folder containing the compiled .node module';
+
+const rm = require('rimraf');
+const exists = require('fs').exists || require('path').exists;
+const versioning = require('./util/versioning.js');
+const napi = require('./util/napi.js');
+const path = require('path');
+
+function clean(gyp, argv, callback) {
+  const package_json = gyp.package_json;
+  const napi_build_version = napi.get_napi_build_version_from_command_args(argv);
+  const opts = versioning.evaluate(package_json, gyp.opts, napi_build_version);
+  const to_delete = opts.module_path;
+  if (!to_delete) {
+    return callback(new Error('module_path is empty, refusing to delete'));
+  } else if (path.normalize(to_delete) === path.normalize(process.cwd())) {
+    return callback(new Error('module_path is not set, refusing to delete'));
+  } else {
+    exists(to_delete, (found) => {
+      if (found) {
+        if (!gyp.opts.silent_clean) console.log('[' + package_json.name + '] Removing "%s"', to_delete);
+        return rm(to_delete, callback);
+      }
+      return callback();
+    });
+  }
+}