- "deprecated": "This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.",
-- Upgraded minimist to 1.2.6 to address dependabot alert [CVE-2021-44906](https://nvd.nist.gov/vuln/detail/CVE-2021-44906)
-
-## 1.0.9
-- Upgraded node-fetch to 2.6.7 to address [CVE-2022-0235](https://www.cve.org/CVERecord?id=CVE-2022-0235)
-- Upgraded detect-libc to 2.0.0 to use non-blocking NodeJS(>=12) Report API
-
-## 1.0.8
-- Downgraded npmlog to maintain node v10 and v8 support (https://github.com/mapbox/node-pre-gyp/pull/624)
-
-## 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
-
-## 0.16.0
-
-- Added Node 15 support in the local database (https://github.com/mapbox/node-pre-gyp/pull/520)
-
-## 0.15.0
-
-- Bump dependency on `mkdirp` from `^0.5.1` to `^0.5.3` (https://github.com/mapbox/node-pre-gyp/pull/492)
-- Bump dependency on `needle` from `^2.2.1` to `^2.5.0` (https://github.com/mapbox/node-pre-gyp/pull/502)
-- Added Node 14 support in the local database (https://github.com/mapbox/node-pre-gyp/pull/501)
-
-## 0.14.0
-
-- Defer modules requires in napi.js (https://github.com/mapbox/node-pre-gyp/pull/434)
-- Bump dependency on `tar` from `^4` to `^4.4.2` (https://github.com/mapbox/node-pre-gyp/pull/454)
-- Support extracting compiled binary from local offline mirror (https://github.com/mapbox/node-pre-gyp/pull/459)
-- Added Node 13 support in the local database (https://github.com/mapbox/node-pre-gyp/pull/483)
-
-## 0.13.0
-
-- Added Node 12 support in the local database (https://github.com/mapbox/node-pre-gyp/pull/449)
-
-## 0.12.0
-
-- Fixed double-build problem with node v10 (https://github.com/mapbox/node-pre-gyp/pull/428)
-- Added node 11 support in the local database (https://github.com/mapbox/node-pre-gyp/pull/422)
-- Now will use `request` over `needle` if request is installed. By default `needle` is used for `https`. This should unbreak proxy support that regressed in v0.9.0
-
-## 0.10.2
-
-- Fixed rc/deep-extent security vulnerability
-- Fixed broken reinstall script do to incorrectly named get_best_napi_version
-
-## 0.10.1
-
-- Fix needle error event (@medns)
-
-## 0.10.0
-
-- Allow for a single-level module path when packing @allenluce (https://github.com/mapbox/node-pre-gyp/pull/371)
-- Log warnings instead of errors when falling back @xzyfer (https://github.com/mapbox/node-pre-gyp/pull/366)
-- Add Node.js v10 support to tests (https://github.com/mapbox/node-pre-gyp/pull/372)
-- Remove retire.js from CI (https://github.com/mapbox/node-pre-gyp/pull/372)
-- Remove support for Node.js v4 due to [EOL on April 30th, 2018](https://github.com/nodejs/Release/blob/7dd52354049cae99eed0e9fe01345b0722a86fde/schedule.json#L14)
-- Update appveyor tests to install default NPM version instead of NPM v2.x for all Windows builds (https://github.com/mapbox/node-pre-gyp/pull/375)
-
-## 0.9.1
-
-- Fixed regression (in v0.9.0) with support for http redirects @allenluce (https://github.com/mapbox/node-pre-gyp/pull/361)
-
-## 0.9.0
-
-- Switched from using `request` to `needle` to reduce size of module deps (https://github.com/mapbox/node-pre-gyp/pull/350)
-
-## 0.8.0
-
-- N-API support (@inspiredware)
-
-## 0.7.1
-
-- Upgraded to tar v4.x
-
-## 0.7.0
-
- - Updated request and hawk (#347)
- - Dropped node v0.10.x support
-
-## 0.6.40
-
- - Improved error reporting if an install fails
-
-## 0.6.39
-
- - Support for node v9
- - Support for versioning on `{libc}` to allow binaries to work on non-glic linux systems like alpine linux
-
-
-## 0.6.38
-
- - Maintaining compatibility (for v0.6.x series) with node v0.10.x
-
-## 0.6.37
-
- - Solved one part of #276: now now deduce the node ABI from the major version for node >= 2 even when not stored in the abi_crosswalk.json
- - Fixed docs to avoid mentioning the deprecated and dangerous `prepublish` in package.json (#291)
- - Add new node versions to crosswalk
- - Ported tests to use tape instead of mocha
- - Got appveyor tests passing by downgrading npm and node-gyp
-
-## 0.6.36
-
- - Removed the running of `testbinary` during install. Because this was regressed for so long, it is too dangerous to re-enable by default. Developers needing validation can call `node-pre-gyp testbinary` directory.
- - Fixed regression in v0.6.35 for electron installs (now skipping binary validation which is not yet supported for electron)
-
-## 0.6.35
-
- - No longer recommending `npm ls` in `prepublish` (#291)
- - Fixed testbinary command (#283) @szdavid92
-
-## 0.6.34
-
- - Added new node versions to crosswalk, including v8
- - Upgraded deps to latest versions, started using `^` instead of `~` for all deps.
-
-## 0.6.33
-
- - Improved support for yarn
-
-## 0.6.32
-
- - Honor npm configuration for CA bundles (@heikkipora)
- - Add node-pre-gyp and npm versions to user agent (@addaleax)
- - Updated various deps
- - Add known node version for v7.x
-
-## 0.6.31
-
- - Updated various deps
-
-## 0.6.30
-
- - Update to npmlog@4.x and semver@5.3.x
- - Add known node version for v6.5.0
-
-## 0.6.29
-
- - Add known node versions for v0.10.45, v0.12.14, v4.4.4, v5.11.1, and v6.1.0
-
-## 0.6.28
-
- - Now more verbose when remote binaries are not available. This is needed since npm is increasingly more quiet by default
- and users need to know why builds are falling back to source compiles that might then error out.
-
-## 0.6.27
-
- - Add known node version for node v6
- - Stopped bundling dependencies
- - Documented method for module authors to avoid bundling node-pre-gyp
- - See https://github.com/mapbox/node-pre-gyp/tree/master#configuring for details
-
-## 0.6.26
-
- - Skip validation for nw runtime (https://github.com/mapbox/node-pre-gyp/pull/181) via @fleg
-
-## 0.6.25
-
- - Improved support for auto-detection of electron runtime in `node-pre-gyp.find()`
- - Pull request from @enlight - https://github.com/mapbox/node-pre-gyp/pull/187
- - Add known node version for 4.4.1 and 5.9.1
-
-## 0.6.24
-
- - Add known node version for 5.8.0, 5.9.0, and 4.4.0.
-
-## 0.6.23
-
- - Add known node version for 0.10.43, 0.12.11, 4.3.2, and 5.7.1.
-
-## 0.6.22
-
- - Add known node version for 4.3.1, and 5.7.0.
-
-## 0.6.21
-
- - Add known node version for 0.10.42, 0.12.10, 4.3.0, and 5.6.0.
-
-## 0.6.20
-
- - Add known node version for 4.2.5, 4.2.6, 5.4.0, 5.4.1,and 5.5.0.
-
-## 0.6.19
-
- - Add known node version for 4.2.4
-
-## 0.6.18
-
- - Add new known node versions for 0.10.x, 0.12.x, 4.x, and 5.x
-
-## 0.6.17
-
- - Re-tagged to fix packaging problem of `Error: Cannot find module 'isarray'`
- - Support custom binary hosting mirror (https://github.com/mapbox/node-pre-gyp/pull/170)
- - Added known version in crosswalk for 4.2.2.
-
-## 0.6.14
-
- - Added node 5.x version
-
-## 0.6.13
-
- - Added more known node 4.x versions
-
-## 0.6.12
-
- - Added support for [Electron](http://electron.atom.io/). Just pass the `--runtime=electron` flag when building/installing. Thanks @zcbenz
-
-## 0.6.11
-
- - Added known node and io.js versions including more 3.x and 4.x versions
-
-## 0.6.10
-
- - Added known node and io.js versions including 3.x and 4.x versions
- - Upgraded `tar` dep
-
-## 0.6.9
-
- - Upgraded `rc` dep
- - Updated known io.js version: v2.4.0
-
-## 0.6.8
-
- - Upgraded `semver` and `rimraf` deps
- - Updated known node and io.js versions
-
-## 0.6.7
-
- - Fixed `node_abi` versions for io.js 1.1.x -> 1.8.x (should be 43, but was stored as 42) (refs https://github.com/iojs/build/issues/94)
-
-## 0.6.6
-
- - Updated with known io.js 2.0.0 version
-
-## 0.6.5
-
- - Now respecting `npm_config_node_gyp` (https://github.com/npm/npm/pull/4887)
- - Updated to semver@4.3.2
- - Updated known node v0.12.x versions and io.js 1.x versions.
-
-## 0.6.4
-
- - Improved support for `io.js` (@fengmk2)
- - Test coverage improvements (@mikemorris)
- - Fixed support for `--dist-url` that regressed in 0.6.3
-
-## 0.6.3
-
- - Added support for passing raw options to node-gyp using `--` separator. Flags passed after
- the `--` to `node-pre-gyp configure` will be passed directly to gyp while flags passed
- after the `--` will be passed directly to make/visual studio.
- - Added `node-pre-gyp configure` command to be able to call `node-gyp configure` directly
- - Fix issue with require validation not working on windows 7 (@edgarsilva)
-
-## 0.6.2
-
- - Support for io.js >= v1.0.2
- - Deferred require of `request` and `tar` to help speed up command line usage of `node-pre-gyp`.
-
-## 0.6.1
-
- - Fixed bundled `tar` version
-
-## 0.6.0
-
- - BREAKING: node odd releases like v0.11.x now use `major.minor.patch` for `{node_abi}` instead of `NODE_MODULE_VERSION` (#124)
- - Added support for `toolset` option in versioning. By default is an empty string but `--toolset` can be passed to publish or install to select alternative binaries that target a custom toolset like C++11. For example to target Visual Studio 2014 modules like node-sqlite3 use `--toolset=v140`.
- - Added support for `--no-rollback` option to request that a failed binary test does not remove the binary module leaves it in place.
- - Added support for `--update-binary` option to request an existing binary be re-installed and the check for a valid local module be skipped.
- - Added support for passing build options from `npm` through `node-pre-gyp` to `node-gyp`: `--nodedir`, `--disturl`, `--python`, and `--msvs_version`
-
-## 0.5.31
-
- - Added support for deducing node_abi for node.js runtime from previous release if the series is even
- - Added support for --target=0.10.33
-
-## 0.5.30
-
- - Repackaged with latest bundled deps
-
-## 0.5.29
-
- - Added support for semver `build`.
- - Fixed support for downloading from urls that include `+`.
-
-## 0.5.28
-
- - Now reporting unix style paths only in reveal command
-
-## 0.5.27
-
- - Fixed support for auto-detecting s3 bucket name when it contains `.` - @taavo
- - Fixed support for installing when path contains a `'` - @halfdan
- - Ported tests to mocha
-
-## 0.5.26
-
- - Fix node-webkit support when `--target` option is not provided
-
-## 0.5.25
-
- - Fix bundling of deps
-
-## 0.5.24
-
- - Updated ABI crosswalk to incldue node v0.10.30 and v0.10.31
-
-## 0.5.23
-
- - Added `reveal` command. Pass no options to get all versioning data as json. Pass a second arg to grab a single versioned property value
- - Added support for `--silent` (shortcut for `--loglevel=silent`)
-
-## 0.5.22
-
- - Fixed node-webkit versioning name (NOTE: node-webkit support still experimental)
-
-## 0.5.21
-
- - New package to fix `shasum check failed` error with v0.5.20
-
-## 0.5.20
-
- - Now versioning node-webkit binaries based on major.minor.patch - assuming no compatible ABI across versions (#90)
-
-## 0.5.19
-
- - Updated to know about more node-webkit releases
-
-## 0.5.18
-
- - Updated to know about more node-webkit releases
-
-## 0.5.17
-
- - Updated to know about node v0.10.29 release
-
-## 0.5.16
-
- - Now supporting all aws-sdk configuration parameters (http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/node-configuring.html) (#86)
-
-## 0.5.15
-
- - Fixed installation of windows packages sub directories on unix systems (#84)
-
-## 0.5.14
-
- - Finished support for cross building using `--target_platform` option (#82)
- - Now skipping binary validation on install if target arch/platform do not match the host.
- - Removed multi-arch validing for OS X since it required a FAT node.js binary
-
-## 0.5.13
-
- - Fix problem in 0.5.12 whereby the wrong versions of mkdirp and semver where bundled.
-
-## 0.5.12
-
- - Improved support for node-webkit (@Mithgol)
-
-## 0.5.11
-
- - Updated target versions listing
-
-## 0.5.10
-
- - Fixed handling of `-debug` flag passed directory to node-pre-gyp (#72)
- - Added optional second arg to `node_pre_gyp.find` to customize the default versioning options used to locate the runtime binary
- - Failed install due to `testbinary` check failure no longer leaves behind binary (#70)
-
-## 0.5.9
-
- - Fixed regression in `testbinary` command causing installs to fail on windows with 0.5.7 (#60)
-
-## 0.5.8
-
- - Started bundling deps
-
-## 0.5.7
-
- - Fixed the `testbinary` check, which is used to determine whether to re-download or source compile, to work even in complex dependency situations (#63)
- - Exposed the internal `testbinary` command in node-pre-gyp command line tool
- - Fixed minor bug so that `fallback_to_build` option is always respected
-
-## 0.5.6
-
- - Added support for versioning on the `name` value in `package.json` (#57).
- - Moved to using streams for reading tarball when publishing (#52)
-
-## 0.5.5
-
- - Improved binary validation that also now works with node-webkit (@Mithgol)
- - Upgraded test apps to work with node v0.11.x
- - Improved test coverage
-
-## 0.5.4
-
- - No longer depends on external install of node-gyp for compiling builds.
-
-## 0.5.3
-
- - Reverted fix for debian/nodejs since it broke windows (#45)
-
-## 0.5.2
-
- - Support for debian systems where the node binary is named `nodejs` (#45)
- - Added `bin/node-pre-gyp.cmd` to be able to run command on windows locally (npm creates an .npm automatically when globally installed)
- - Updated abi-crosswalk with node v0.10.26 entry.
-
-## 0.5.1
-
- - Various minor bug fixes, several improving windows support for publishing.
-
-## 0.5.0
-
- - Changed property names in `binary` object: now required are `module_name`, `module_path`, and `host`.
- - Now `module_path` supports versioning, which allows developers to opt-in to using a versioned install path (#18).
- - Added `remote_path` which also supports versioning.
- - Changed `remote_uri` to `host`.
-
-## 0.4.2
-
- - Added support for `--target` flag to request cross-compile against a specific node/node-webkit version.
- - Added preliminary support for node-webkit
- - Fixed support for `--target_arch` option being respected in all cases.
-
-## 0.4.1
-
- - Fixed exception when only stderr is available in binary test (@bendi / #31)
-
-## 0.4.0
-
- - Enforce only `https:` based remote publishing access.
- - Added `node-pre-gyp info` command to display listing of published binaries
- - Added support for changing the directory node-pre-gyp should build in with the `-C/--directory` option.
- - Added support for S3 prefixes.
-
-## 0.3.1
-
- - Added `unpublish` command.
- - Fixed module path construction in tests.
- - Added ability to disable falling back to build behavior via `npm install --fallback-to-build=false` which overrides setting in a depedencies package.json `install` target.
-
-## 0.3.0
-
- - Support for packaging all files in `module_path` directory - see `app4` for example
- - Added `testpackage` command.
- - Changed `clean` command to only delete `.node` not entire `build` directory since node-gyp will handle that.
- - `.node` modules must be in a folder of there own since tar-pack will remove everything when it unpacks.
-`@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('@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.
-
-## Credits
-
- - The module is modeled after [node-gyp](https://github.com/Tootallnate/node-gyp) by [@Tootallnate](https://github.com/Tootallnate)
- - Motivation for initial development came from [@ErisDS](https://github.com/ErisDS) and the [Ghost Project](https://github.com/TryGhost/Ghost).
- - Development is sponsored by [Mapbox](https://www.mapbox.com/)
-
-## FAQ
-
-See the [Frequently Ask Questions](https://github.com/mapbox/node-pre-gyp/wiki/FAQ).
-
-## Depends
-
- - Node.js >= node v8.x
-
-## Install
-
-`node-pre-gyp` is designed to be installed as a local dependency of your Node.js C++ addon and accessed like:
-
- ./node_modules/.bin/node-pre-gyp --help
-
-But you can also install it globally:
-
- npm install @mapbox/node-pre-gyp -g
-
-## Usage
-
-### Commands
-
-View all possible commands:
-
- node-pre-gyp --help
-
-- clean - Remove the entire folder containing the compiled .node module
-- install - Install pre-built binary for module
-- reinstall - Run "clean" and "install" at once
-- build - Compile the module by dispatching to node-gyp or nw-gyp
-- rebuild - Run "clean" and "build" at once
-- package - Pack binary into tarball
-- testpackage - Test that the staged package is valid
-- publish - Publish pre-built binary
-- unpublish - Unpublish pre-built binary
-- info - Fetch info on published binaries
-
-You can also chain commands:
-
- node-pre-gyp clean build unpublish publish info
-
-### Options
-
-Options include:
-
- - `-C/--directory`: run the command in this directory
- - `--build-from-source`: build from source instead of using pre-built binary
- - `--update-binary`: reinstall by replacing previously installed local binary with remote binary
- - `--runtime=node-webkit`: customize the runtime: `node`, `electron` and `node-webkit` are the valid options
- - `--fallback-to-build`: fallback to building from source if pre-built binary is not available
- - `--target=0.4.0`: Pass the target node or node-webkit version to compile against
- - `--target_arch=ia32`: Pass the target arch and override the host `arch`. Any value that is [supported by Node.js](https://nodejs.org/api/os.html#osarch) is valid.
- - `--target_platform=win32`: Pass the target platform and override the host `platform`. Valid values are `linux`, `darwin`, `win32`, `sunos`, `freebsd`, `openbsd`, and `aix`.
-
-Both `--build-from-source` and `--fallback-to-build` can be passed alone or they can provide values. You can pass `--fallback-to-build=false` to override the option as declared in package.json. In addition to being able to pass `--build-from-source` you can also pass `--build-from-source=myapp` where `myapp` is the name of your module.
-
-For example: `npm install --build-from-source=myapp`. This is useful if:
-
- - `myapp` is referenced in the package.json of a larger app and therefore `myapp` is being installed as a dependency with `npm install`.
- - The larger app also depends on other modules installed with `node-pre-gyp`
- - You only want to trigger a source compile for `myapp` and the other modules.
-
-### Configuring
-
-This is a guide to configuring your module to use node-pre-gyp.
-For a full example see [node-addon-examples's package.json](https://github.com/springmeyer/node-addon-example/blob/master/package.json).
-
-Let's break this down:
-
- - Dependencies need to list `node-pre-gyp`
- - Your devDependencies should list `aws-sdk` so that you can run `node-pre-gyp publish` locally or a CI system. We recommend using `devDependencies` only since `aws-sdk` is large and not needed for `node-pre-gyp install` since it only uses http to fetch binaries
- - 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 `@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
-
-###### module_name
-
-The name of your native node module. This value must:
-
- - Match the name passed to [the NODE_MODULE macro](http://nodejs.org/api/addons.html#addons_hello_world)
- - Must be a valid C variable name (e.g. it cannot contain `-`)
- - Should not include the `.node` extension.
-
-###### module_path
-
-The location your native module is placed after a build. This should be an empty directory without other Javascript files. This entire directory will be packaged in the binary tarball. When installing from a remote package this directory will be overwritten with the contents of the tarball.
-
-Note: This property supports variables based on [Versioning](#versioning).
-
-###### host
-
-A url to the remote location where you've published tarball binaries (must be `https` not `http`).
-
-It is highly recommended that you use Amazon S3. The reasons are:
-
- - Various node-pre-gyp commands like `publish` and `info` only work with an S3 host.
- - S3 is a very solid hosting platform for distributing large files.
- - We provide detail documentation for using [S3 hosting](#s3-hosting) with node-pre-gyp.
-
-Why then not require S3? Because while some applications using node-pre-gyp need to distribute binaries as large as 20-30 MB, others might have very small binaries and might wish to store them in a GitHub repo. This is not recommended, but if an author really wants to host in a non-S3 location then it should be possible.
-
-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 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
-
-It **is recommended** that you customize this property. This is an extra path to use for publishing and finding remote tarballs. The default value for `remote_path` is `""` meaning that if you do not provide it then all packages will be published at the base of the `host`. It is recommended to provide a value like `./{name}/v{version}` to help organize remote packages in the case that you choose to publish multiple node addons to the same `host`.
-
-Note: This property supports variables based on [Versioning](#versioning).
-
-###### package_name
-
-It is **not recommended** to override this property unless you are also overriding the `remote_path`. This is the versioned name of the remote tarball containing the binary `.node` module and any supporting files you've placed inside the `module_path` directory. Unless you specify `package_name` in your `package.json` then it defaults to `{module_name}-v{version}-{node_abi}-{platform}-{arch}.tar.gz` which allows your binary to work across node versions, platforms, and architectures. If you are using `remote_path` that is also versioned by `./{module_name}/v{version}` then you could remove these variables from the `package_name` and just use: `{node_abi}-{platform}-{arch}.tar.gz`. Then your remote tarball will be looked up at, for example, `https://example.com/your-module/v0.1.0/node-v11-linux-x64.tar.gz`.
-
-Avoiding the version of your module in the `package_name` and instead only embedding in a directory name can be useful when you want to make a quick tag of your module that does not change any C++ code. In this case you can just copy binaries to the new version behind the scenes like:
-Note: This property supports variables based on [Versioning](#versioning).
-
-#### 2) Add a new target to binding.gyp
-
-`node-pre-gyp` calls out to `node-gyp` to compile the module and passes variables along like [module_name](#module_name) and [module_path](#module_path).
-
-A new target must be added to `binding.gyp` that moves the compiled `.node` module from `./build/Release/module_name.node` into the directory specified by `module_path`.
-
-Add a target like this at the end of your `targets` list:
-For a full example see [node-addon-example's binding.gyp](https://github.com/springmeyer/node-addon-example/blob/2ff60a8ded7f042864ad21db00c3a5a06cf47075/binding.gyp).
-
-#### 3) Dynamically require your `.node`
-
-Inside the main js file that requires your addon module you are likely currently doing:
-For a full example see [node-addon-example's index.js](https://github.com/springmeyer/node-addon-example/blob/2ff60a8ded7f042864ad21db00c3a5a06cf47075/index.js#L1-L4)
-
-#### 4) Build and package your app
-
-Now build your module from source:
-
- npm install --build-from-source
-
-The `--build-from-source` tells `node-pre-gyp` to not look for a remote package and instead dispatch to node-gyp to build.
-
-Now `node-pre-gyp` should now also be installed as a local dependency so the command line tool it offers can be found at `./node_modules/.bin/node-pre-gyp`.
-
-#### 5) Test
-
-Now `npm test` should work just as it did before.
-
-#### 6) Publish the tarball
-
-Then package your app:
-
- ./node_modules/.bin/node-pre-gyp package
-
-Once packaged, now you can publish:
-
- ./node_modules/.bin/node-pre-gyp publish
-
-Currently the `publish` command pushes your binary to S3. This requires:
-
- - You have installed `aws-sdk` with `npm install aws-sdk`
- - You have created a bucket already.
- - The `host` points to an S3 http or https endpoint.
- - You have configured node-pre-gyp to read your S3 credentials (see [S3 hosting](#s3-hosting) for details).
-
-You can also host your binaries elsewhere. To do this requires:
-
- - You manually publish the binary created by the `package` command to an `https` endpoint
- - Ensure that the `host` value points to your custom `https` endpoint.
-
-#### 7) Automate builds
-
-Now you need to publish builds for all the platforms and node versions you wish to support. This is best automated.
-
- - See [Appveyor Automation](#appveyor-automation) for how to auto-publish builds on Windows.
- - See [Travis Automation](#travis-automation) for how to auto-publish builds on OS X and Linux.
-
-#### 8) You're done!
-
-Now publish your module to the npm registry. Users will now be able to install your module from a binary.
-
-What will happen is this:
-
-1. `npm install <your package>` will pull from the npm registry
-2. npm will run the `install` script which will call out to `node-pre-gyp`
-3. `node-pre-gyp` will fetch the binary `.node` module and unpack in the right place
-4. Assuming that all worked, you are done
-
-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.
-
-#### 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.
-
-## Node-API Considerations
-
-[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.
-
-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
-
-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:
-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 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 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 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
-
-The `napi_build_version` value is communicated to the C/C++ code by adding this code to the `binding.gyp` file:
-
-```
-"defines": [
- "NAPI_VERSION=<(napi_build_version)",
-]
-```
-
-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 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 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.)
-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 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 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 Node-API and NAN 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
-// Node-API code goes here
-#else
-// NAN code goes here
-#endif
-```
-
-### Two additional configuration values
-
-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 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`.
-
-These values are present for use in the `binding.gyp` file and may be used as `{napi_version}` and `{node_abi_napi}` for text substituion in the `binary` properties of the `package.json` file.
-
-## S3 Hosting
-
-You can host wherever you choose but S3 is cheap, `node-pre-gyp publish` expects it, and S3 can be integrated well with [Travis.ci](http://travis-ci.org) to automate builds for OS X and Ubuntu, and with [Appveyor](http://appveyor.com) to automate builds for Windows. Here is an approach to do this:
-
-First, get setup locally and test the workflow:
-
-#### 1) Create an S3 bucket
-
-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`, `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": "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": "*"
- }
- ]
-}
-```
-
-#### 2) Install node-pre-gyp
-
-Either install it globally:
-
- npm install node-pre-gyp -g
-
-Or put the local version on your PATH
-
- export PATH=`pwd`/node_modules/.bin/:$PATH
-
-#### 3) Configure AWS credentials
-
-It is recommended to configure the AWS JS SDK v2 used internally by `node-pre-gyp` by setting these environment variables:
-
-- AWS_ACCESS_KEY_ID
-- AWS_SECRET_ACCESS_KEY
-
-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
-
-Install the `aws-sdk`:
-
- npm install aws-sdk
-
-Then publish:
-
- node-pre-gyp package publish
-
-Note: if you hit an error like `Hostname/IP doesn't match certificate's altnames` it may mean that you need to provide the `region` option in your config.
-
-## Appveyor Automation
-
-[Appveyor](http://www.appveyor.com/) can build binaries and publish the results per commit and supports:
-
- - Windows Visual Studio 2013 and related compilers
- - Both 64 bit (x64) and 32 bit (x86) build configurations
- - Multiple Node.js versions
-
-For an example of doing this see [node-sqlite3's appveyor.yml](https://github.com/mapbox/node-sqlite3/blob/master/appveyor.yml).
-
-Below is a guide to getting set up:
-
-#### 1) Create a free Appveyor account
-
-Go to https://ci.appveyor.com/signup/free and sign in with your GitHub account.
-
-#### 2) Create a new project
-
-Go to https://ci.appveyor.com/projects/new and select the GitHub repo for your module
-
-#### 3) Add appveyor.yml and push it
-
-Once you have committed an `appveyor.yml` ([appveyor.yml reference](http://www.appveyor.com/docs/appveyor-yml)) to your GitHub repo and pushed it AppVeyor should automatically start building your project.
-
-#### 4) Create secure variables
-
-Encrypt your S3 AWS keys by going to <https://ci.appveyor.com/tools/encrypt> and hitting the `encrypt` button.
-NOTE: keys are per account but not per repo (this is difference than Travis where keys are per repo but not related to the account used to encrypt them).
-
-#### 5) Hook up publishing
-
-Just put `node-pre-gyp package publish` in your `appveyor.yml` after `npm install`.
-
-#### 6) Publish when you want
-
-You might wish to publish binaries only on a specific commit. To do this you could borrow from the [Travis CI idea of commit keywords](http://about.travis-ci.org/docs/user/how-to-skip-a-build/) and add special handling for commit messages with `[publish binary]`:
-
- SET CM=%APPVEYOR_REPO_COMMIT_MESSAGE%
- if not "%CM%" == "%CM:[publish binary]=%" node-pre-gyp --msvs_version=2013 publish
-
-If your commit message contains special characters (e.g. `&`) this method might fail. An alternative is to use PowerShell, which gives you additional possibilities, like ignoring case by using `ToLower()`:
-Remember this publishing is not the same as `npm publish`. We're just talking about the binary module here and not your entire npm package.
-
-## Travis Automation
-
-[Travis](https://travis-ci.org/) can push to S3 after a successful build and supports both:
-
- - Ubuntu Precise and OS X (64 bit)
- - Multiple Node.js versions
-
-For an example of doing this see [node-add-example's .travis.yml](https://github.com/springmeyer/node-addon-example/blob/2ff60a8ded7f042864ad21db00c3a5a06cf47075/.travis.yml).
-
-Note: if you need 32 bit binaries, this can be done from a 64 bit Travis machine. See [the node-sqlite3 scripts for an example of doing this](https://github.com/mapbox/node-sqlite3/blob/bae122aa6a2b8a45f6b717fab24e207740e32b5d/scripts/build_against_node.sh#L54-L74).
-
-Below is a guide to getting set up:
-
-#### 1) Install the Travis gem
-
- gem install travis
-
-#### 2) Create secure variables
-
-Make sure you run this command from within the directory of your module.
-See [Travis OS X Gotchas](#travis-os-x-gotchas) for why we replace `language: node_js` and `node_js:` sections with `language: cpp` and a custom matrix.
-
-Also create platform specific sections for any deps that need install. For example if you need libpng:
-
-```yml
-- if [ $(uname -s) == 'Linux' ]; then apt-get install libpng-dev; fi;
-- if [ $(uname -s) == 'Darwin' ]; then brew install libpng; fi;
-```
-
-For detailed multi-OS examples see [node-mapnik](https://github.com/mapnik/node-mapnik/blob/master/.travis.yml) and [node-sqlite3](https://github.com/mapbox/node-sqlite3/blob/master/.travis.yml).
-
-##### Travis OS X Gotchas
-
-First, unlike the Travis Linux machines, the OS X machines do not put `node-pre-gyp` on PATH by default. To do so you will need to:
-
-```sh
-export PATH=$(pwd)/node_modules/.bin:${PATH}
-```
-
-Second, the OS X machines do not support using a matrix for installing different Node.js versions. So you need to bootstrap the installation of Node.js in a cross platform way.
-You can easily recreate the previous behavior of this matrix:
-
-```yml
-node_js:
- - "4"
- - "6"
-```
-
-#### 4) Publish when you want
-
-You might wish to publish binaries only on a specific commit. To do this you could borrow from the [Travis CI idea of commit keywords](http://about.travis-ci.org/docs/user/how-to-skip-a-build/) and add special handling for commit messages with `[publish binary]`:
- if [[ ${COMMIT_MESSAGE} =~ "[publish binary]" ]]; then node-pre-gyp publish; fi;
-
-Then you can trigger new binaries to be built like:
-
- git commit -a -m "[publish binary]"
-
-Or, if you don't have any changes to make simply run:
-
- git commit --allow-empty -m "[publish binary]"
-
-WARNING: if you are working in a pull request and publishing binaries from there then you will want to avoid double publishing when Travis CI builds both the `push` and `pr`. You only want to run the publish on the `push` commit. See https://github.com/Project-OSRM/node-osrm/blob/8eb837abe2e2e30e595093d16e5354bc5c573575/scripts/is_pr_merge.sh which is called from https://github.com/Project-OSRM/node-osrm/blob/8eb837abe2e2e30e595093d16e5354bc5c573575/scripts/publish.sh for an example of how to do this.
-
-Remember this publishing is not the same as `npm publish`. We're just talking about the binary module here and not your entire npm package. To automate the publishing of your entire package to npm on Travis see http://about.travis-ci.org/docs/user/deployment/npm/
-
-# Versioning
-
-The `binary` properties of `module_path`, `remote_path`, and `package_name` support variable substitution. The strings are evaluated by `node-pre-gyp` depending on your system and any custom build flags you passed.
-
- - `node_abi`: The node C++ `ABI` number. This value is available in Javascript as `process.versions.modules` as of [`>= v0.10.4 >= v0.11.7`](https://github.com/joyent/node/commit/ccabd4a6fa8a6eb79d29bc3bbe9fe2b6531c2d8e) and in C++ as the `NODE_MODULE_VERSION` define much earlier. For versions of Node before this was available we fallback to the V8 major and minor version.
- - `platform` matches node's `process.platform` like `linux`, `darwin`, and `win32` unless the user passed the `--target_platform` option to override.
- - `arch` matches node's `process.arch` like `x64` or `ia32` unless the user passes the `--target_arch` option to override.
- - `libc` matches `require('detect-libc').family` like `glibc` or `musl` unless the user passes the `--target_libc` option to override.
- - `configuration` - Either 'Release' or 'Debug' depending on if `--debug` is passed during the build.
- - `module_name` - the `binary.module_name` attribute from `package.json`.
- - `version` - the semver `version` value for your module from `package.json` (NOTE: ignores the `semver.build` property).
- - `major`, `minor`, `patch`, and `prelease` match the individual semver values for your module's `version`
- - `build` - the sevmer `build` value. For example it would be `this.that` if your package.json `version` was `v1.0.0+this.that`
- - `prerelease` - the semver `prerelease` value. For example it would be `alpha.beta` if your package.json `version` was `v1.0.0-alpha.beta`
-
-
-The options are visible in the code at <https://github.com/mapbox/node-pre-gyp/blob/612b7bca2604508d881e1187614870ba19a7f0c5/lib/util/versioning.js#L114-L127>
-
-# Download binary files from a mirror
-
-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, `-` in `module_name` will be replaced with `_`.
-
-e.g.: Install [v8-profiler](https://www.npmjs.com/package/v8-profiler) from `npm`.
- - [Post data using a file stream](#post-data-using-a-file-stream)
- - [Post with form-data (detect multipart)](#post-with-form-data-detect-multipart)
- - [Request cancellation with AbortSignal](#request-cancellation-with-abortsignal)
-- [API](#api)
- - [fetch(url[, options])](#fetchurl-options)
- - [Options](#options)
- - [Class: Request](#class-request)
- - [Class: Response](#class-response)
- - [Class: Headers](#class-headers)
- - [Interface: Body](#interface-body)
- - [Class: FetchError](#class-fetcherror)
-- [License](#license)
-- [Acknowledgement](#acknowledgement)
-
-<!-- /TOC -->
-
-## Motivation
-
-Instead of implementing `XMLHttpRequest` in Node.js to run browser-specific [Fetch polyfill](https://github.com/github/fetch), why not go from native `http` to `fetch` API directly? Hence, `node-fetch`, minimal code for a `window.fetch` compatible API on Node.js runtime.
-
-See Matt Andrews' [isomorphic-fetch](https://github.com/matthew-andrews/isomorphic-fetch) or Leonardo Quixada's [cross-fetch](https://github.com/lquixada/cross-fetch) for isomorphic usage (exports `node-fetch` for server-side, `whatwg-fetch` for client-side).
-
-## Features
-
-- Stay consistent with `window.fetch` API.
-- Make conscious trade-off when following [WHATWG fetch spec][whatwg-fetch] and [stream spec](https://streams.spec.whatwg.org/) implementation details, document known differences.
-- Use native promise but allow substituting it with [insert your favorite promise library].
-- Use native Node streams for body on both request and response.
-- Decode content encoding (gzip/deflate) properly and convert string output (such as `res.text()` and `res.json()`) to UTF-8 automatically.
-- Useful extensions such as timeout, redirect limit, response size limit, [explicit errors](ERROR-HANDLING.md) for troubleshooting.
-
-## Difference from client-side fetch
-
-- See [Known Differences](LIMITS.md) for details.
-- If you happen to use a missing feature that `window.fetch` offers, feel free to open an issue.
-- Pull requests are welcomed too!
-
-## Installation
-
-Current stable release (`2.x`)
-
-```sh
-$ npm install node-fetch
-```
-
-## Loading and configuring the module
-We suggest you load the module via `require` until the stabilization of ES modules in node:
-```js
-const fetch = require('node-fetch');
-```
-
-If you are using a Promise library other than native, set it through `fetch.Promise`:
-```js
-const Bluebird = require('bluebird');
-
-fetch.Promise = Bluebird;
-```
-
-## Common Usage
-
-NOTE: The documentation below is up-to-date with `2.x` releases; see the [`1.x` readme](https://github.com/bitinn/node-fetch/blob/1.x/README.md), [changelog](https://github.com/bitinn/node-fetch/blob/1.x/CHANGELOG.md) and [2.x upgrade guide](UPGRADE-GUIDE.md) for the differences.
-`URLSearchParams` is available in Node.js as of v7.5.0. See [official documentation](https://nodejs.org/api/url.html#url_class_urlsearchparams) for more usage methods.
-
-NOTE: The `Content-Type` header is only set automatically to `x-www-form-urlencoded` when an instance of `URLSearchParams` is given as such:
-NOTE: 3xx-5xx responses are *NOT* exceptions and should be handled in `then()`; see the next section for more information.
-
-Adding a catch to the fetch promise chain will catch *all* exceptions, such as errors originating from node core libraries, network errors and operational errors, which are instances of FetchError. See the [error handling document](ERROR-HANDLING.md) for more details.
-
-```js
-fetch('https://domain.invalid/')
- .catch(err => console.error(err));
-```
-
-#### Handling client and server errors
-It is common to create a helper function to check that the response contains no client (4xx) or server (5xx) error responses:
-`url` should be an absolute url, such as `https://example.com/`. A path-relative URL (`/file/under/root`) or protocol-relative URL (`//can-be-http-or-https.com/`) will result in a rejected `Promise`.
-
-<a id="fetch-options"></a>
-### Options
-
-The default values are shown after each option key.
-
-```js
-{
- // These properties are part of the Fetch Standard
- method: 'GET',
- headers: {}, // request headers. format is the identical to that accepted by the Headers constructor (see below)
- body: null, // request body. can be null, a string, a Buffer, a Blob, or a Node.js Readable stream
- redirect: 'follow', // set to `manual` to extract redirect headers, `error` to reject redirect
- signal: null, // pass an instance of AbortSignal to optionally abort requests
-
- // The following properties are node-fetch extensions
- follow: 20, // maximum redirect count. 0 to not follow redirect
- timeout: 0, // req/res timeout in ms, it resets on redirect. 0 to disable (OS limit applies). Signal is recommended instead.
- compress: true, // support gzip/deflate content encoding. false to disable
- size: 0, // maximum response body size in bytes. 0 to disable
- agent: null // http(s).Agent instance or function that returns an instance (see below)
-}
-```
-
-##### Default Headers
-
-If no values are set, the following request headers will be sent automatically:
-Note: when `body` is a `Stream`, `Content-Length` is not set automatically.
-
-##### Custom Agent
-
-The `agent` option allows you to specify networking related options which are out of the scope of Fetch, including and not limited to the following:
-
-- Support self-signed certificate
-- Use only IPv4 or IPv6
-- Custom DNS Lookup
-
-See [`http.Agent`](https://nodejs.org/api/http.html#http_new_agent_options) for more information.
-
-If no agent is specified, the default agent provided by Node.js is used. Note that [this changed in Node.js 19](https://github.com/nodejs/node/blob/4267b92604ad78584244488e7f7508a690cb80d0/lib/_http_agent.js#L564) to have `keepalive` true by default. If you wish to enable `keepalive` in an earlier version of Node.js, you can override the agent as per the following code sample.
-
-In addition, the `agent` option accepts a function that returns `http`(s)`.Agent` instance given current [URL](https://nodejs.org/api/url.html), this is useful during a redirection chain across HTTP and HTTPS protocol.
-
-```js
-const httpAgent = new http.Agent({
- keepAlive: true
-});
-const httpsAgent = new https.Agent({
- keepAlive: true
-});
-
-const options = {
- agent: function (_parsedURL) {
- if (_parsedURL.protocol == 'http:') {
- return httpAgent;
- } else {
- return httpsAgent;
- }
- }
-}
-```
-
-<a id="class-request"></a>
-### Class: Request
-
-An HTTP(S) request containing information about URL, method, headers, and the body. This class implements the [Body](#iface-body) interface.
-
-Due to the nature of Node.js, the following properties are not implemented at this moment:
-
-- `type`
-- `destination`
-- `referrer`
-- `referrerPolicy`
-- `mode`
-- `credentials`
-- `cache`
-- `integrity`
-- `keepalive`
-
-The following node-fetch extension properties are provided:
-
-- `follow`
-- `compress`
-- `counter`
-- `agent`
-
-See [options](#fetch-options) for exact meaning of these extensions.
-
-#### new Request(input[, options])
-
-<small>*(spec-compliant)*</small>
-
-- `input` A string representing a URL, or another `Request` (which will be cloned)
-- `options` [Options][#fetch-options] for the HTTP(S) request
-
-Constructs a new `Request` object. The constructor is identical to that in the [browser](https://developer.mozilla.org/en-US/docs/Web/API/Request/Request).
-
-In most cases, directly `fetch(url, options)` is simpler than creating a `Request` object.
-
-<a id="class-response"></a>
-### Class: Response
-
-An HTTP(S) response. This class implements the [Body](#iface-body) interface.
-
-The following properties are not implemented in node-fetch at this moment:
-
-- `Response.error()`
-- `Response.redirect()`
-- `type`
-- `trailer`
-
-#### new Response([body[, options]])
-
-<small>*(spec-compliant)*</small>
-
-- `body` A `String` or [`Readable` stream][node-readable]
-- `options` A [`ResponseInit`][response-init] options dictionary
-
-Constructs a new `Response` object. The constructor is identical to that in the [browser](https://developer.mozilla.org/en-US/docs/Web/API/Response/Response).
-
-Because Node.js does not implement service workers (for which this class was designed), one rarely has to construct a `Response` directly.
-
-#### response.ok
-
-<small>*(spec-compliant)*</small>
-
-Convenience property representing if the request ended normally. Will evaluate to true if the response status was greater than or equal to 200 but smaller than 300.
-
-#### response.redirected
-
-<small>*(spec-compliant)*</small>
-
-Convenience property representing if the request has been redirected at least once. Will evaluate to true if the internal redirect counter is greater than 0.
-
-<a id="class-headers"></a>
-### Class: Headers
-
-This class allows manipulating and iterating over a set of HTTP headers. All methods specified in the [Fetch Standard][whatwg-fetch] are implemented.
-
-#### new Headers([init])
-
-<small>*(spec-compliant)*</small>
-
-- `init` Optional argument to pre-fill the `Headers` object
-
-Construct a new `Headers` object. `init` can be either `null`, a `Headers` object, an key-value map object or any iterable object.
-
-```js
-// Example adapted from https://fetch.spec.whatwg.org/#example-headers-class
-
-const meta = {
- 'Content-Type': 'text/xml',
- 'Breaking-Bad': '<3'
-};
-const headers = new Headers(meta);
-
-// The above is equivalent to
-const meta = [
- [ 'Content-Type', 'text/xml' ],
- [ 'Breaking-Bad', '<3' ]
-];
-const headers = new Headers(meta);
-
-// You can in fact use any iterable objects, like a Map or even another Headers
-const meta = new Map();
-meta.set('Content-Type', 'text/xml');
-meta.set('Breaking-Bad', '<3');
-const headers = new Headers(meta);
-const copyOfHeaders = new Headers(headers);
-```
-
-<a id="iface-body"></a>
-### Interface: Body
-
-`Body` is an abstract interface with methods that are applicable to both `Request` and `Response` classes.
-
-The following methods are not yet implemented in node-fetch at this moment:
-
-- `formData()`
-
-#### body.body
-
-<small>*(deviation from spec)*</small>
-
-* Node.js [`Readable` stream][node-readable]
-
-Data are encapsulated in the `Body` object. Note that while the [Fetch Standard][whatwg-fetch] requires the property to always be a WHATWG `ReadableStream`, in node-fetch it is a Node.js [`Readable` stream][node-readable].
-
-#### body.bodyUsed
-
-<small>*(spec-compliant)*</small>
-
-* `Boolean`
-
-A boolean property for if this body has been consumed. Per the specs, a consumed body cannot be used again.
-
-#### body.arrayBuffer()
-#### body.blob()
-#### body.json()
-#### body.text()
-
-<small>*(spec-compliant)*</small>
-
-* Returns: <code>Promise</code>
-
-Consume the body and return a promise that will resolve to one of these formats.
-
-#### body.buffer()
-
-<small>*(node-fetch extension)*</small>
-
-* Returns: <code>Promise<Buffer></code>
-
-Consume the body and return a promise that will resolve to a Buffer.
-
-#### body.textConverted()
-
-<small>*(node-fetch extension)*</small>
-
-* Returns: <code>Promise<String></code>
-
-Identical to `body.text()`, except instead of always converting to UTF-8, encoding sniffing will be performed and text converted to UTF-8 if possible.
-
-(This API requires an optional dependency of the npm package [encoding](https://www.npmjs.com/package/encoding), which you need to install manually. `webpack` users may see [a warning message](https://github.com/bitinn/node-fetch/issues/412#issuecomment-379007792) due to this optional dependency.)
-
-<a id="class-fetcherror"></a>
-### Class: FetchError
-
-<small>*(node-fetch extension)*</small>
-
-An operational error in the fetching process. See [ERROR-HANDLING.md][] for more info.
-
-<a id="class-aborterror"></a>
-### Class: AbortError
-
-<small>*(node-fetch extension)*</small>
-
-An Error thrown when the request is aborted in response to an `AbortSignal`'s `abort` event. It has a `name` property of `AbortError`. See [ERROR-HANDLING.MD][] for more info.
-
-## Acknowledgement
-
-Thanks to [github/fetch](https://github.com/github/fetch) for providing a solid implementation reference.
-
-`node-fetch` v1 was maintained by [@bitinn](https://github.com/bitinn); v2 was maintained by [@TimothyGu](https://github.com/timothygu), [@bitinn](https://github.com/bitinn) and [@jimmywarting](https://github.com/jimmywarting); v2 readme is written by [@jkantr](https://github.com/jkantr).
- 'add clem burke in my playlist Pre-Party R&B Jams',
- 'Add Live from Aragon Ballroom to Trapeo',
- 'add Unite and Win to my night out',
- 'Add track to my Digster Future Hits',
- 'add the piano bar to my Cindy Wilson',
- 'Add Spanish Harlem Incident to cleaning the house',
- 'add The Greyest of Blue Skies in Indie Español my playlist',
- 'Add the name kids in the street to the plylist New Indie Mix',
- 'add album radar latino',
- 'Add Tranquility to the Latin Pop Rising playlist.',
- 'play something from the twenties',
- 'Play The View From The Afternoon by Malese Jow on Last Fm',
- 'play songs by Sammy Fain',
- 'Play music from the year 1964',
- 'Play the heinz strobl ep from 2016 on Groove Shark',
- 'Play me Leonid Soybelman on Vimeo.',
- 'Play a song from my workout playlist on Groove Shark',
- 'play some Alte Kameraden music',
- 'Will it be warm 1 week from now in DC',
- 'what is the forecast for temperate conditions in Thailand in Lopeno',
- 'Is the weather colder in Costa Rica',
- 'Will it be colder in Delaware?',
- '"I need to know the weather for Hamorton, TN"',
- 'What will the weather be in Albania at 11:56.',
- 'Is it going to hail in Mount San Jacinto State Park',
- 'What\'s the forecast for Walker Bay Nature Reserve for next year ? ',
- 'is it supposed to be sunny here?',
- 'in California will it be cold in East Trenton Heights',
- 'What is the weather like in Wallis and Futuna? What will the weather be in Romania at 4?',
- 'What is the weather going to be like in Reidland New Mexico next Jun.?',
- 'How cold is it in Cargray, Argentina?',
- 'Is the forecast chillier in 1 hour in Mali',
- 'Tell me if there will be wind in NE Will it be cloudy not far from Allenton Will there be a blizzard in AR what is the New Caledonia forecast for Bagnell on sep. the 5th Weather for apr. the thirteenth in Djibouti',
- 'Can you give me the weather forecast in Tajikistan? How cold is it going to be in San Marcial, AK in one second? What will the weather be in a month from now at my current location?',
- 'What is the weather like in IA in april How windy is it in Anderson Lake State Fish and Wildlife Area? Is it going to be stormy in Austin Creek State Recreation Area at 09:42?',
- 'When will the weather be temperate like it is now in Stansbury Park in Tuvalu, What is the weather in neighboring OH, What\'s the weather forecast for Spain ? ',
- 'Play the music Hands Up',
- 'Play some twenties theme music on Google Music.',
- 'How will the weather be in New Mexico around 00:09:07 am?',
- 'What will the humidity be in AR in 49 weeks and a half from now',
- 'Is it humid in Parc national de Killarney',
- 'is it supposed to get colder here on 12/28/2019',
- 'How is the forecast for OK?',
- 'what is the Posey Island State Park forecast for colder temps at meal time',
- 'Is it supposed to be chilly in Kuwait?',
- 'Tell me if it\'ll be chilly here at 0 pm',
- 'what is the forecast for colder conditions within the same area of this current place',
- 'Will it hail today in West Point at 11:36:48',
- 'Is it overcast in South Carolina',
- 'Will the sun be out close-by Admiralty Island National Monument?',