node-pre-gyp
Advanced tools
Comparing version 0.10.2 to 0.10.3
# node-pre-gyp changelog | ||
## 0.10.3 | ||
- 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 | ||
@@ -4,0 +8,0 @@ |
@@ -22,2 +22,17 @@ "use strict"; | ||
var http_get = { | ||
impl: undefined, | ||
type: undefined | ||
}; | ||
try { | ||
http_get.impl = require('request'); | ||
http_get.type = 'request'; | ||
log.warn("Using request for node-pre-gyp https download"); | ||
} catch (e) { | ||
http_get.impl = require('needle'); | ||
http_get.type = 'needle'; | ||
log.warn("Using needle for node-pre-gyp https download"); | ||
} | ||
function download(uri,opts,callback) { | ||
@@ -63,3 +78,3 @@ log.http('GET', uri); | ||
try { | ||
req = require('needle').get(requestOpts.uri, requestOpts); | ||
req = http_get.impl.get(requestOpts.uri, requestOpts); | ||
} catch (e) { | ||
@@ -99,2 +114,9 @@ return callback(e); | ||
// for request compatibility | ||
req.on('error', function(err) { | ||
badDownload = true; | ||
return callback(err); | ||
}); | ||
// for needle compatibility | ||
req.on('err', function(err) { | ||
@@ -113,4 +135,4 @@ badDownload = true; | ||
// ignore redirects, needle handles these automatically. | ||
if (res.headers.hasOwnProperty('location') && res.headers.location !== '') { | ||
return; | ||
if (http_get.type === 'needle' && res.headers.hasOwnProperty('location') && res.headers.location !== '') { | ||
return; | ||
} | ||
@@ -117,0 +139,0 @@ if (res.statusCode !== 200) { |
@@ -1777,3 +1777,7 @@ { | ||
"v8": "6.7" | ||
}, | ||
"10.6.0": { | ||
"node_abi": 64, | ||
"v8": "6.7" | ||
} | ||
} |
{ | ||
"name": "node-pre-gyp", | ||
"description": "Node.js native addon binary install tool", | ||
"version": "0.10.2", | ||
"version": "0.10.3", | ||
"keywords": [ | ||
@@ -25,3 +25,3 @@ "native", | ||
"mkdirp": "^0.5.1", | ||
"needle": "^2.2.0", | ||
"needle": "^2.2.1", | ||
"nopt": "^4.0.1", | ||
@@ -39,3 +39,2 @@ "npm-packlist": "^1.1.6", | ||
"nock": "^9.2.3", | ||
"retire": "^1.2.12", | ||
"tape": "^4.6.3" | ||
@@ -42,0 +41,0 @@ }, |
@@ -85,3 +85,3 @@ # node-pre-gyp | ||
- `myapp` is referenced in the package.json of a larger app and therefore `myapp` is being installed as a dependent with `npm install`. | ||
- `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` | ||
@@ -110,3 +110,2 @@ - You only want to trigger a source compile for `myapp` and the other modules. | ||
} | ||
"bundledDependencies":["node-pre-gyp"], | ||
"scripts": { | ||
@@ -128,8 +127,6 @@ "install": "node-pre-gyp install --fallback-to-build" | ||
- 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 | ||
- You should add `"bundledDependencies":["node-pre-gyp"]`. This ensures that when you publish your module that the correct version of node-pre-gyp will be included in the `node_modules` folder during publishing. Then when uses install your module `node-pre-gyp` will already be present. Without this your module will not be safely installable for downstream applications that have a depedency on node-pre-gyp in the npm tree (without bundling npm deduping might break the install when node-pre-gyp is moved in flight) | ||
- Your `scripts` section should optionally add `"prepublishOnly": "npm ls"` to ensure the right node-pre-gyp version is bundled before publishing your module. If node-pre-gyp is missing or an old version is present then this will catch that error before you publish a broken package. | ||
- 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 using `"preinstall": "npm install node-pre-gyp"` as an alternative method to avoid needing to bundle. But this does 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`. Instead we recommend bundling. More history on this at https://github.com/strongloop/fsevents/issues/157#issuecomment-265545908. | ||
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. | ||
@@ -162,3 +159,3 @@ ##### The `binary` object has three required properties | ||
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. | ||
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. | ||
@@ -319,3 +316,3 @@ 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```. | ||
For each of the N-API module operations `node-pre-gyp` initiates, it insures that the `napi_build_version` is set appropriately. | ||
For each of the N-API module operations `node-pre-gyp` initiates, it ensures that the `napi_build_version` is set appropriately. | ||
@@ -337,3 +334,3 @@ This value is of importance in two areas: | ||
This insures that `NAPI_BUILD_VERSION`, an integer value, is declared appropriately to the C/C++ code for each build. | ||
This ensures that `NAPI_BUILD_VERSION`, an integer value, is declared appropriately to the C/C++ code for each build. | ||
@@ -340,0 +337,0 @@ ### Path and file naming requirements in `package.json` |
Sorry, the diff of this file is not supported yet
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
140985
4
3337
659
Updatedneedle@^2.2.1