node-pre-gyp
Advanced tools
Comparing version 0.6.30 to 0.6.31
| # node-pre-gyp changelog | ||
| ## 0.6.31 | ||
| - Updated various deps | ||
| ## 0.6.30 | ||
@@ -4,0 +8,0 @@ |
@@ -98,7 +98,5 @@ "use strict"; | ||
| badDownload = true; | ||
| if (res.statusCode == 404) { | ||
| return callback(new Error('Pre-built binary not available for your system, looked for ' + from)); | ||
| } else { | ||
| return callback(new Error(res.statusCode + ' status code downloading tarball ' + from)); | ||
| } | ||
| var err = new Error(res.statusCode + ' status code downloading tarball ' + from); | ||
| err.statusCode = res.statusCode; | ||
| return callback(err); | ||
| } | ||
@@ -121,3 +119,3 @@ // start unzipping and untaring | ||
| full_message += fallback_message; | ||
| log.error("Tried to download: " + opts.hosted_tarball); | ||
| log.error("Tried to download(" + err.statusCode + "): " + opts.hosted_tarball); | ||
| log.error(full_message); | ||
@@ -124,0 +122,0 @@ log.http(err.message); |
@@ -798,2 +798,10 @@ { | ||
| }, | ||
| "0.10.47": { | ||
| "node_abi": 11, | ||
| "v8": "3.14" | ||
| }, | ||
| "0.10.48": { | ||
| "node_abi": 11, | ||
| "v8": "3.14" | ||
| }, | ||
| "0.11.0": { | ||
@@ -931,2 +939,10 @@ "node_abi": 12, | ||
| }, | ||
| "0.12.16": { | ||
| "node_abi": 14, | ||
| "v8": "3.28" | ||
| }, | ||
| "0.12.17": { | ||
| "node_abi": 14, | ||
| "v8": "3.28" | ||
| }, | ||
| "1.0.0": { | ||
@@ -1188,2 +1204,10 @@ "node_abi": 42, | ||
| }, | ||
| "4.6.0": { | ||
| "node_abi": 46, | ||
| "v8": "4.5" | ||
| }, | ||
| "4.6.1": { | ||
| "node_abi": 46, | ||
| "v8": "4.5" | ||
| }, | ||
| "5.0.0": { | ||
@@ -1300,3 +1324,27 @@ "node_abi": 47, | ||
| "v8": "5.1" | ||
| }, | ||
| "6.6.0": { | ||
| "node_abi": 48, | ||
| "v8": "5.1" | ||
| }, | ||
| "6.7.0": { | ||
| "node_abi": 48, | ||
| "v8": "5.1" | ||
| }, | ||
| "6.8.0": { | ||
| "node_abi": 48, | ||
| "v8": "5.1" | ||
| }, | ||
| "6.8.1": { | ||
| "node_abi": 48, | ||
| "v8": "5.1" | ||
| }, | ||
| "6.9.0": { | ||
| "node_abi": 48, | ||
| "v8": "5.1" | ||
| }, | ||
| "6.9.1": { | ||
| "node_abi": 48, | ||
| "v8": "5.1" | ||
| } | ||
| } |
| { | ||
| "name": "node-pre-gyp", | ||
| "description": "Node.js native addon binary install tool", | ||
| "version" : "0.6.30", | ||
| "version" : "0.6.31", | ||
| "keywords": [ | ||
@@ -23,16 +23,16 @@ "native", | ||
| "dependencies": { | ||
| "mkdirp": "~0.5.0", | ||
| "nopt": "~3.0.1", | ||
| "npmlog": "4.x", | ||
| "rc": "~1.1.0", | ||
| "request": "2.x", | ||
| "rimraf": "~2.5.0", | ||
| "mkdirp": "~0.5.1", | ||
| "nopt": "~3.0.6", | ||
| "npmlog": "^4.0.0", | ||
| "rc": "~1.1.6", | ||
| "request": "^2.75.0", | ||
| "rimraf": "~2.5.4", | ||
| "semver": "~5.3.0", | ||
| "tar": "~2.2.0", | ||
| "tar-pack": "~3.1.0" | ||
| "tar": "~2.2.1", | ||
| "tar-pack": "~3.3.0" | ||
| }, | ||
| "devDependencies": { | ||
| "aws-sdk": "2.x", | ||
| "mocha": "2.x", | ||
| "retire": "1.1.2", | ||
| "mocha": "3.x", | ||
| "retire": "1.2.10", | ||
| "jshint": "2.x" | ||
@@ -39,0 +39,0 @@ }, |
@@ -17,3 +17,3 @@ # node-pre-gyp | ||
| - 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('node-pre-gyp').find` | ||
@@ -149,5 +149,5 @@ 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. | ||
| 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. | ||
| It should also be mentioned that there is an optional and entirely seperate 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-githib publish```. | ||
| 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```. | ||
@@ -376,11 +376,11 @@ ##### The `binary` object has two optional properties | ||
| Go to https://ci.appveyor.com/signup/free and sign in with your github 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 | ||
| 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. | ||
| 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. | ||
@@ -409,3 +409,3 @@ #### 4) Create secure variables | ||
| 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]`: | ||
| 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]`: | ||
@@ -464,3 +464,3 @@ SET CM=%APPVEYOR_REPO_COMMIT_MESSAGE% | ||
| If you want binaries for OS X in addition to linux you can enable [multi-os for travis](http://docs.travis-ci.com/user/multi-os/#Setting-.travis.yml) | ||
| If you want binaries for OS X in addition to linux you can enable [multi-os for Travis](http://docs.travis-ci.com/user/multi-os/#Setting-.travis.yml) | ||
@@ -489,3 +489,3 @@ Use a configuration like: | ||
| See [Travis OS X Gochas](#travis-os-x-gochas) for why we replace `language: node_js` and `node_js:` sections with `language: cpp` and a custom matrix. | ||
| 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. | ||
@@ -501,5 +501,5 @@ Also create platform specific sections for any deps that need install. For example if you need libpng: | ||
| ##### Travis OS X Gochas | ||
| ##### Travis OS X Gotchas | ||
| First, unlike the Travis linux machines the OS X machines do not put `node-pre-gyp` on PATH by default. So to you will need to: | ||
| 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: | ||
@@ -510,3 +510,3 @@ ```sh | ||
| 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. | ||
| 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. | ||
@@ -538,3 +538,3 @@ By doing: | ||
| 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]`: | ||
| 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]`: | ||
@@ -552,3 +552,3 @@ COMMIT_MESSAGE=$(git log --format=%B --no-merges -n 1 | tr -d '\n') | ||
| 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. | ||
| 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. | ||
@@ -555,0 +555,0 @@ 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/ |
New alerts
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
Fixed alerts
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
Improved metrics
- Total package byte prevSize
- increased by0.53%
115485
- Lines of code
- increased by1.77%
2642
Dependency changes
+ Addedtar-pack@3.3.0(transitive)
- Removedtar-pack@3.1.4(transitive)
Updatedmkdirp@~0.5.1
Updatednopt@~3.0.6
Updatednpmlog@^4.0.0
Updatedrc@~1.1.6
Updatedrequest@^2.75.0
Updatedrimraf@~2.5.4
Updatedtar@~2.2.1
Updatedtar-pack@~3.3.0