node-pre-gyp - npm Package Compare versions

Comparing version 0.2.1 to 0.2.2

lib/util/versioning.js

@@ -59,6 +59,9 @@
         if (err) return callback(err);
-        var module_version = semver.parse(package_json.version);
+        var v = package_json.version;
+        var module_version = semver.parse(v);
         var opts = {
             configuration: (options.debug === true) ? 'Debug' : 'Release'
             , module_name: package_json.binary.module_name
+            , version: module_version.version
+            , prerelease: module_version.prerelease.length ? v.slice(v.indexOf(module_version.prerelease[0])) : ''
             , major: module_version.major
@@ -65,0 +68,0 @@ , minor: module_version.minor

package.json

 {
   "name": "node-pre-gyp",
   "description": "Node.js native addon binary install tool",
-  "version": "0.2.1",
+  "version": "0.2.2",
   "keywords": [
@@ -6,0 +6,0 @@ "native",

README.md

@@ -7,6 +7,17 @@ # node-pre-gyp
 
-Developers can use `node-pre-gyp` to build, package, and publish the binary `.node` C++ module for their package.
+## Does this replace npm or node-gyp?
 
-Users can then install your module without a C++ compiler.
+No: it plays nicely with them.
 
+ - You still publish your package to the npm repository
+ - You still create a `binding.gyp` to compile your module with `node-gyp`
+
+What node-pre-gyp does is stand between `npm` and `node-gyp`.
+
+## Who uses node-pre-gyp?
+
+You: the developers of a C++ module. You use `node-pre-gyp` to package and and publish the binary `.node` right before you `npm publish` a new version.
+
+Your users: Once your package uses `node-pre-gyp` then users can `npm install` your module without a C++ compiler and `node-pre-gyp` handles the complexity behind the scenes.
+
 ## Why use node-pre-gyp?
@@ -16,7 +27,5 @@
 
- - Users can be blissfully unaware that your module is written in C++: `npm install` will just work (with no source compile).
+ - Users can be blissfully unaware that your module is written in C++
  - During development you will run `node-pre-gyp build` instead of `npm install`
  - You will take on the responsibility for providing binaries to your users
- - Luckily most Node.js users run OS X or Linux, and it is very easy to automate builds for these systems, so after some up-front effort maintaining binaries will be easy.
- - And node-pre-gyp will work just fine with no binaries, gracefully falling back to node-gyp.
 
@@ -29,3 +38,3 @@ ## Modules using `node-pre-gyp`:
 
-For more examples see also the sample apps in `test/`.
+For more examples see also the [test apps https://github.com/springmeyer/node-pre-gyp/tree/master/test].
 
@@ -56,3 +65,3 @@ ## Usage
 
-```js
+```sh
 node-pre-gyp build package
@@ -66,3 +75,3 @@ ```
  - Learn how to [host on S3](https://github.com/springmeyer/node-pre-gyp#s3-hosting).
- - See [Travis Packaging](https://github.com/springmeyer/node-pre-gyp#s3-hosting#travis-packaging) for recipes for automating publishing builds.
+ - See [Travis Packaging](https://github.com/springmeyer/node-pre-gyp#s3-hosting#travis-packaging) for recipes for automating publishing builds on OS X and Linux.
 
@@ -77,8 +86,10 @@ **4) Add a custom `install` script**
 
-Then users installing your module will get your binary, if available, instead of the default behavior of `npm` calling `node-gyp rebuild` right away. The `--fallback-to-build` option is recommended and means that if no binary is available for a given users platform then a source compile(`node-pre-gyp rebuild`) will be attempted.
+Then users installing your module will get your binary, if available, instead of the default behavior of `npm` calling `node-gyp rebuild` right away. The `--fallback-to-build` option is recommended: if no binary is available for a given users platform then a source compile (`node-pre-gyp rebuild`) will be attempted.
 
 **5) You're done!**
 
-Now you are done. Publish your package to the npm registry. Users will now be able to install your module from a binary. What will happen is this:
+Now you are done. Publish your package 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
@@ -89,7 +100,7 @@ 2. npm will run the `install` script which will call out to `node-pre-gyp`
 
-If a failure occurred and `--fallback-to-build` was used then a source compile fallback will be made calling out to `node-gyp rebuild`.
+If a failure occurred and `--fallback-to-build` was used then `node-gyp rebuild` will be called.
 
 ## S3 Hosting
 
-The usage examples above and in the tests use Amazon S3 for hosting binaries. You can host wherever you choose but S3 is easy and can be integrated well with [travis.ci](http://travis-ci.org) to automate builds for OS X and Ubuntu. Here is an approach to do this:
+The usage examples above and in the tests use Amazon S3 for hosting binaries. 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. Here is an approach to do this:
 
@@ -100,18 +111,30 @@ First, get setup locally and test the workflow:
 
-**2) Install node-pre-gyp globally**
+**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) Create an `~/.node_pre_gyprc`**
 
-This file must be json or ini and provide:
+Or pass options in any way supported by [RC](https://github.com/dominictarr/rc#standards)
 
- - `accessKeyId`
- - `secretAccessKey`
+`~/.node_pre_gyprc` looks like:
 
-These values can also be found in any way compatible with [RC](https://github.com/dominictarr/rc#standards). Another way that works well with travis is to set the variables in the environment like:
+```js
+{
+    "accessKeyId": "xxx",
+    "secretAccessKey": "xxx"
+}
+```
 
-    export node_pre_gyp_accessKeyId=<key>
-    export node_pre_gyp_secretAccessKey=<key>
+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 `remote_uri` value you use. The `bucket` can also be specified but it is optional because `node-pre-gyp` will detect it from the `remote_uri` value.
@@ -121,3 +144,3 @@
 
-Do this for every platform you wish to support:
+Do this for every platform and node version you wish to support:
 
@@ -130,4 +153,9 @@ node-pre-gyp package publish
 
-Travis can push to S3 after a successful build and supports both ubuntu precise and OS X, enabling you to cheaply build binaries for you module every commit or each tag.
+Travis can push to S3 after a successful build and supports both:
 
+ - Ubuntu precise and OS X
+ - multiple Node.js versions
+
+This enables you to cheaply auto-build and auto-publish binaries for (likely) the majority of users.
+
 **1) Install the travis gem**
@@ -139,6 +167,8 @@
 
+Make sure you run this command from within the directory of your module.
+
 Use `travis-encrypt` like:
 
-    travis encrypt node_pre_gyp_accessKeyId=<key>
-    travis encrypt node_pre_gyp_secretAccessKey=<key>
+    travis encrypt node_pre_gyp_accessKeyId=${node_pre_gyp_accessKeyId}
+    travis encrypt node_pre_gyp_secretAccessKey=${node_pre_gyp_secretAccessKey}
 
@@ -168,2 +198,27 @@ Then put those values in your `.travis.yml` like:
 
+Note: using `language: objective-c` instead of `language: nodejs` looses node.js specific travis sugar like a matrix for multiple node.js versions.
+
+You can replace:
+
+```yml
+node_js:
+  - "0.8"
+  - "0.10"
+```
+
+With:
+
+```yml
+env:
+  matrix:
+    - export NODE_VERSION="0.8"
+    - export NODE_VERSION="0.10"
+
+before_install:
+ - git clone https://github.com/creationix/nvm.git ./.nvm
+ - source ./.nvm/nvm.sh
+ - nvm install $NODE_VERSION
+ - nvm use $NODE_VERSION
+```
+
 **4) Publish when you want**
@@ -173,7 +228,7 @@
 
-    if echo $TRAVIS_COMMIT | grep -q "publish"; then
+    if echo $TRAVIS_COMMIT | grep -q "[publish]"; then
        node-pre-gyp publish
     fi
 
-Or you could automatically detect if the git branch is a tag and publish:
+Or you could automatically detect if the git branch is a tag:
 
@@ -198,3 +253,3 @@ IS_TAG=$(git describe --exact-match --tags HEAD || true)
 
-    node-pre-gyp reinstall
+    node-pre-gyp reinstall # runs "clean" and "install"
 
@@ -205,3 +260,3 @@ #### Build the module from source instead of installing from pre-built binary:
 
-This is basically the equivalent to calling `node-gyp rebuild` which is what `npm install` displatches to if you don't override (like recommended above) the `scripts/install` target in `package.json`.
+This is basically the equivalent to calling `node-gyp rebuild` which is what `npm install` call if you don't override (like recommended above) the `scripts/install` target in `package.json`.
 
@@ -221,2 +276,2 @@ ### Options
  - 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.
+ - You only want to trigger a source compile for `myapp` and the other modules.

test/app1/package.json

@@ -15,3 +15,3 @@ {
         "remote_uri": "http://node-pre-gyp-tests.s3-us-west-1.amazonaws.com",
-        "template": "{module_name}-v{major}.{minor}.{patch}-{node_abi}-{platform}-{arch}.tar.gz"
+        "template": "{module_name}-v{version}-{node_abi}-{platform}-{arch}.tar.gz"
     },
@@ -18,0 +18,0 @@ "scripts": {

test/app2/package.json

@@ -15,3 +15,3 @@ {
         "remote_uri": "http://node-pre-gyp-tests.s3-us-west-1.amazonaws.com",
-        "template": "{module_name}-v{major}.{minor}.{patch}-{node_abi}-{platform}-{arch}.tar.gz"
+        "template": "{module_name}-v{version}-{node_abi}-{platform}-{arch}.tar.gz"
     },
@@ -18,0 +18,0 @@ "scripts": {

test/app3/package.json

@@ -9,3 +9,3 @@ {
     },
-    "version": "0.1.0",
+    "version": "0.1.0-dev.4",
     "main": "./index.js",
@@ -16,3 +16,3 @@ "binary": {
         "remote_uri": "http://node-pre-gyp-tests.s3-us-west-1.amazonaws.com",
-        "template": "{module_name}-v{major}.{minor}.{patch}-{node_abi}-{platform}-{arch}.tar.gz"
+        "template": "{module_name}-v{major}.{minor}.{patch}-{prerelease}-{node_abi}-{platform}-{arch}.tar.gz"
     },
@@ -19,0 +19,0 @@ "scripts": {

todo.md

 
 ## Todo
 
-- detailed doc on versioning string
+- allow --fallback-to-build=false to turn off
+- avoid publishing on top of existing file?
 - unpublish - mainly for tests
-- shasum
-- 32 bit support: https://github.com/mapbox/node-sqlite3/blob/pre-built/bin/remake.sh
 - re-try if download or shasum failure
 - respect -C/--directory
 - leverage npm infrastructure more?
-- guide explaining basics of statically linking or otherwise ensuring external C/C++ depedencies are able to be standlone and portable
 - if run via npm dashes will become underscores - why exactly?
+
+## Node binaries
+
+- build on ancient centos: https://github.com/joyent/node/issues/6801

New alerts

License Policy Violation

License

This 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

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Major refactor

Supply chain risk

Package has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

43599

increased by2.75%

Lines of code

590

increased by0.51%

Number of lines in readme file

262

increased by27.18%

Number of medium supply chain risk alerts

8

decreased by-11.11%

No dependency changes