Hi,
we figured out there is a problem with last change in common.sh. If you call the warning function with only one argument the deployment will fail without any usefull error message. (See deployment log)

2015-06-09T12:25:54.82+0200 [API/0]      OUT Created app with guid b3b6da11-22db-4836-a8aa-88b36b93a906
2015-06-09T12:25:55.14+0200 [API/0]      OUT Updated app with guid b3b6da11-22db-4836-a8aa-88b36b93a906 ({"route"=>"76889ae0-f8df-4796-8ed9-6d26fcfafdd6"})
2015-06-09T12:26:01.33+0200 [DEA/19]     OUT Got staging request for app with id b3b6da11-22db-4836-a8aa-88b36b93a906
2015-06-09T12:26:02.61+0200 [API/0]      OUT Updated app with guid b3b6da11-22db-4836-a8aa-88b36b93a906 ({"state"=>"STARTED"})
2015-06-09T12:26:02.88+0200 [STG/19]     OUT -----> Downloaded app package (12K)
2015-06-09T12:26:03.33+0200 [STG/0]      OUT -------> Buildpack version 1.3.3
2015-06-09T12:26:03.36+0200 [STG/0]      OUT        Node.js Buildpack v64
2015-06-09T12:26:03.36+0200 [STG/0]      OUT -----> Reading application state
2015-06-09T12:26:03.36+0200 [STG/0]      OUT        package.json...
2015-06-09T12:26:03.37+0200 [STG/0]      OUT        build directory...
2015-06-09T12:26:03.37+0200 [STG/0]      OUT        cache directory...
2015-06-09T12:26:03.38+0200 [STG/0]      OUT        environment variables...
2015-06-09T12:26:03.38+0200 [STG/0]      OUT        Node engine range:   0.12
2015-06-09T12:26:03.38+0200 [STG/0]      OUT        Npm engine:          1.3
2015-06-09T12:26:03.38+0200 [STG/0]      OUT        Start mechanism:     server.js
2015-06-09T12:26:03.38+0200 [STG/0]      OUT        node_modules source: package.json
2015-06-09T12:26:03.38+0200 [STG/0]      OUT        node_modules cached: false
2015-06-09T12:26:03.43+0200 [STG/0]      OUT        NPM_CONFIG_PRODUCTION=true
2015-06-09T12:26:03.43+0200 [STG/0]      OUT        NODE_MODULES_CACHE=true
2015-06-09T12:26:03.60+0200 [STG/0]      OUT        Downloading and installing node 0.12.2...
2015-06-09T12:26:04.20+0200 [STG/0]      OUT        Resolving npm version 1.3 via semver.io...
2015-06-09T12:26:05.61+0200 [STG/0]      OUT        Downloading and installing npm 1.3.26 (replacing version 2.7.4)...
2015-06-09T12:26:07.56+0200 [STG/0]      OUT        npm WARN engine [email protected]: wanted: {"node":">=0.6","npm":"1"} (current: {"node":"0.12.2","npm":"2.7.4"})
2015-06-09T12:26:11.10+0200 [STG/0]      OUT        npm WARN package.json [email protected] No repository field.
2015-06-09T12:26:11.38+0200 [STG/0]      OUT        npm WARN installMany normalize-package-data was bundled with [email protected], but bundled package wasn't found in unpacked tree
2015-06-09T12:26:13.24+0200 [API/0]      ERR encountered error: App staging failed in the buildpack compile phase
2015-06-09T12:26:13.27+0200 [STG/0]      ERR /var/vcap/data/dea_next/admin_buildpacks/1a1f295c-51eb-4cc5-8845-8c256b6b2d51_d87a71ee0a07ca073c20a295c9777a099ff01a5a/lib/common.sh: line 19: $2: unbound variable
2015-06-09T12:26:13.27+0200 [STG/0]      OUT Staging failed: Buildpack compilation step failed

I expect it is related to calls in warnings.sh but I don't know where the function is used too. We fixed our actual problem by using the latest buildpack version. But I guess others might struggle with this too so it might be fixed. If you like I can try to provide a fix but I got some trouble to test / reproduce the issue based on the current master.

Hi there!

It was recently brought to our attention in issue #54 that the nodejs buildpack attempts to download npm if the version specified in package.json does not match the version shipped with nodejs. According to heroku this feature exists for historical reasons that no longer apply. We would like to remove this functionality, specifically for use in offline environments and plan on scheduling work on 4/25.

If you rely on this feature or have an objection to this change please let us know.

The README states to use bin/package [ online | offline ] to compile this buildpack, but there is no package command in bin/ anymore.

Hi Team,

We are trying to have nodejs application monitored on appdynamics controller once application are deployed on PCF.
Currently i am facing an issue where i am writing value of VCAP_SERVICES and VCAP_APPLICATION into a file. Later that file is being used by node in the start of application execution.

Do we have any other way of using VCAP variable values without writing into a file.

Thanks,
Pranjal

Hi All,

Long-term support for Node.js 0.10.x provided by the Node.js LTS Working Group will end on October 31, 2016. Therefore, the Node.js 0.10.x binary dependency provided by the Node.js buildpack will no longer be available in the first release of the buildpack made after October 31st. Please adjust your Node.js CF applications to use a supported version of Node.js by that time.

Please see the Node.js Long-term Support Schedule for more detailed information.

Thank you,
Stephen Levine
CF Buildpacks PM

The latest stable probably now means that latest LTS, which is 4.3.0. Or non LTS is 5.6.0.

However here's what it brings down:

-----> Installing binaries
       engines.node (package.json):  unspecified
       engines.npm (package.json):   unspecified (use default)
       Resolving node version (latest stable) via semver.io...
       Downloading and installing node 0.12.9...
       Downloaded [https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/node/node-0.12.9-linux-x64.tgz]
       Using default npm version: 2.14.9

Tested against tag 1.5.8

Pushing an app with the engine block set to:

  "engines": {
    "node": "4.3"
  },

Results in:

-------> Buildpack version 1.5.8
-----> Creating runtime environment
       NPM_CONFIG_LOGLEVEL=error
       NPM_CONFIG_PRODUCTION=true
       NODE_ENV=production
       NODE_MODULES_CACHE=true
-----> Installing binaries
       engines.node (package.json):  4.3
       engines.npm (package.json):   unspecified (use default)
       Downloading and installing node undefined...
DEPENDENCY MISSING IN MANIFEST:
Unfortunately, we are unable to resolve the dependency into
a binary and version number. Please replace this URL with a valid link.
-----> Build failed
       We're sorry this build is failing! You can troubleshoot common issues here:
       https://devcenter.heroku.com/articles/troubleshooting-node-deploys
       Some possible problems:
       - node_modules checked into source control
       https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git
       Love,
       Heroku
Staging failed: Buildpack compilation step failed

FAILED
BuildpackCompileFailed

Pushing an app with the engine block set to:

  "engines": {
    "node": "4.3.0"
  },

Results in:

-------> Buildpack version 1.5.8
-----> Creating runtime environment
       NPM_CONFIG_LOGLEVEL=error
       NPM_CONFIG_PRODUCTION=true
       NODE_ENV=production
       NODE_MODULES_CACHE=true
-----> Installing binaries
       engines.node (package.json):  4.3.0
       engines.npm (package.json):   unspecified (use default)
       Downloading and installing node 4.3.0...
DEPENDENCY MISSING IN MANIFEST: node 4.3.0
It looks like you're trying to use node 4.3.0.
Unfortunately, that version of node is not supported by this buildpack.
The versions of node supported in this buildpack are:
- 5.8.0
- 4.4.0
- 0.12.12
- 0.12.11
- 0.10.43
- 0.10.42
If you need further help, start by reading: http://github.com/cloudfoundry/node-buildpack/releases.
-----> Build failed
       We're sorry this build is failing! You can troubleshoot common issues here:
       https://devcenter.heroku.com/articles/troubleshooting-node-deploys
       Some possible problems:
       - node_modules checked into source control
       https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git
       Love,
       Heroku
Staging failed: Buildpack compilation step failed

FAILED

The error messaging for the first case could be much better.

Pushing with the engine block set as follows:

"engines": {
    "node": "4.4"
  },

does succeed (it infers 4.4.0: Downloading and installing node 4.4.0...), so in some cases the buildpack can infer the .0.

Hello,

Not really sure this is the best place to post this issue I'm having with my node.js application, but I can't find any resource on this subject. My application is a HTTP API built with node.js and pushed on a Cloud Foundry server (Bluemix) using this buildpack.

When I send GET or POST requests everything is fine, but when I send PUT or DELETE requests I receive 405 Not Allowed response.

Here is my manifest.yml:

applications:
- name: api
  buildpack: https://github.com/cloudfoundry/buildpack-nodejs.git
  env:
    NODE_MODULES_CACHE: false

And this is the response body:

<html>
<head><title>405 Not Allowed</title></head>
<body bgcolor="white">
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx</center>
</body>
</html>

• Am I missing something?
• Is there a way to configure the Nginx server?

Thanks for reading!

RFC: Node.js® 4.x support

This issue is intended to describe the current challenges around supporting Node.js 4.x in the nodejs-buildpack, and introduces several potential tracks of work, along with the Buildpack PM's preferred solution.

The Challenge

Node.js 4.x depends on openssl 1.0.2

OpenSSL is not infrequently updated in response to security vulnerabilities (CVEs), and as such the Buildpacks team has been dynamically linking the Node binaries against the rootfs openssl library. This allows applications to be patched with a rootfs update (i.e., applications don't need to be restaged).

The cflinuxfs2 rootfs packages Debian's openssl v1.0.1, which is the version depended upon by Node 0.12.x and earlier.

As of Node 4.x, though, the dependency is on openssl 1.0.2. We've opened a Github Issue reporting this as a bug, but have not made much progress in convincing the Node core team to support openssl 1.0.1.

The Proposal

Full explanation and context are below, but in short the proposal is:

1. nodejs-buildpack would ship binaries for node 4.x that statically link the vendored openssl 1.0.2; with the downside that openssl patches will require app restaging.
2. Based on usage and feedback, we may decide later to maintain openssl 1.0.2 on the cflinuxfs2 rootfs; but would defer this decision for now.

What We've Tried So Far

Compile against openssl 1.0.2 and dynamically link against 1.0.1

We attempted to take advantage of the ABI backwards-compatibility between 1.0.2 and 1.0.1 by compiling against the former, then dynamically loading the latter.

Unsurprisingly, this didn't work, as Node 4.x is actually using new methods corresponding to new features in openssl 1.0.2.

Install openssl 1.0.2 into cflinuxfs2

We attempted to install 1.0.2 from upstream (backported) Ubuntu Wily on the same system as 1.0.1, but unfortunately the .deb packages clobber each other, as they have the same package name: openssl.

Remaining Possible Solutions

Introduce a wily-based stack

wily ships with openssl 1.0.2, and so we could introduce a new stack based on this Ubuntu distribution.

This is an extraordinarily heavyweight solution, which I'm extremely hesitant to even suggest, given an absence of compelling reasons to introduce this level of complexity to the product.

Let's pretend I didn't even bring this up.

Maintain our own openssl 1.0.2 for dynamic linking

We could build our own CF-specific openssl 1.0.2 package to install alongside the rootfs's openssl 1.0.1.

Pros:

• This isn't totally crazy,
• and would allow us to continue to patch applications via rootfs updates (not restaging)

Cons:

• This is a little bit crazy.
• It would add complexity to our build system,
• and would take a significant upfront investment to make sure it was done right and automated properly,
• to add support for an interpreter that we're not yet sure anyone actually wants to use.

Statically link the Node-vendored openssl 1.0.2

The final option is to follow the Node team's advice, and just take the Node-vendored openssl 1.0.2 as it is, and statically link it into the interpreter binary.

This solution requires the Node team make prompt releases after openssl vulnerabilities. The 0.12.x (and previous) release cycles were not great, but the io.js team running the release cycle for 3.x and 4.x appear to really have their act together, making nearly-weekly feature and bugfix releases.

Pros:

• Very little work for the Buildpacks team,
• allowing us to ship something and validate the need for Node 4.x support.

Cons:

• Restaging would be required to patch apps for future openssl CVEs.
• Requires relying on the Node team for prompt updates.

Related Issues

Worth noting that this bug filed against node 0.12.x is related, in that the stock openssl 1.0.1.f shipped with Ubuntu Trusty doesn't contain an upstream patch that is applied in the vendored openssl (1.0.1.k, it looks like) in the 0.12.x official build.

In Summary, or, How You Can Help

Given the fact that I've seen very little demand for Node 4.x support, I hereby propose to choose the most expedient solution, "Statically Link v1.0.2", in order to be able to quickly validate whether CF users actually even care about Node 4.

If we see real demand for production Node 4.x support, either in this ticket or after we implement static linking of v1.0.2, then I'm open to moving to the "Maintain Our Own Dynamically Linked Openssl v1.0.2" solution.

How You Can Help

Comment on this issue.

If you want to see Node 4.x support, let us know!

If you prefer one solution or the other, let us know!

If you have any other ideas on how to accomplish our goal of Node 4.x support, let us know!

The default behavior for restoring cache and "pruning" is not consistent with Heroku or legacy behavior. When a user checks in node_modules, the buildpack will still run npm prune as part of restore_npm_cache.

If I want to push some dependencies in node_modules with my application (even though it's an anti-pattern), the buildpack will wipe them out if I don't have them explicitly listed in my package.json. This is not how it worked before.

We should really only run npm prune if there is a npm-shrinkwrap.json or package.json AND no node_modules in the application. The behavior in the past was that if node_modules is checked in, we completely skip the caching process because we cannot ensure that a user has explicitly declared those dependencies in their package.json/shrinkwrap.

See here:
https://github.com/cloudfoundry/nodejs-buildpack/blob/master/lib/build.sh#L162
and
https://github.com/heroku/heroku-buildpack-nodejs/blob/master/lib/build.sh#L186

EDIT: I opened PR #21 to address this issue and Issue #22

In buildpack v1.5.1, binary data is emitted to STDOUT if the version of node I'm trying to use isn't in the manifest.

Related, if I try to deploy using cf push <appname> -b https://github.com/cloudfoundry/nodejs-buildpack, without a version specified, it similarly will throw up all over itself.

Hi,

I'm not sure if this is a buildpack or gorouter/ha_proxy issue. However, I would like to give more time to my app to send a response to the requests before getting a timeout. When the app is taking time to send a response (say 3 mins), I get a 502 from CF.

Any ideas please?

Steps to reproduce:

1.) Create a project folder and add a file package.json, use these contents.

{
  "name": "node-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "engines": {
    "node": "0.10.42",
    "npm": "2.14.12"
  },
  "author": "Daniel Mikusa",
  "license": "ISC"
}

2.) It doesn't really matter, but you can add this small test app in the file index.js.

var http = require('http');

http.createServer(function (req, res) {
      res.writeHead(200, {'Content-Type': 'text/plain'});
      for (var env in process.env) {
          res.write(env + '=' + process.env[env] + '\n');
      }
      res.end();
}).listen(process.env.PORT || 3000);

3.) Push the application to a CF installation that does not have Internet access. An easy way to simulate this is by unbinding all the staging security groups.

Staging will fail as the build pack runs npm to install the requested version of NPM, and NPM needs the Internet to do that.

https://github.com/cloudfoundry/nodejs-buildpack/blob/master/lib/binaries.sh#L61-L62

$ cf push node-test-2 -i 1 -m 128M -b node_js_buildpack_v157
Updating app node-test-2 in org lab / space dmikusa as admin...
OK

Uploading node-test-2...
Uploading app files from: /Users/danielmikusa/Downloads/node-test
Uploading 783B, 2 files
Done uploading
OK

Starting app node-test-2 in org lab / space dmikusa as admin...
Downloading node_js_buildpack_v157...
Downloaded node_js_buildpack_v157
Creating container
Successfully created container
Downloading app package...
Downloaded app package (663B)
Staging...
-------> Buildpack version 1.5.7
-----> Creating runtime environment

       NPM_CONFIG_LOGLEVEL=error
       NPM_CONFIG_PRODUCTION=true
       NODE_ENV=production
       NODE_MODULES_CACHE=true
-----> Installing binaries
       engines.node (package.json):  0.10.42
       engines.npm (package.json):   2.14.12

       Downloading and installing node 0.10.42...
       Downloaded [file:///tmp/buildpacks/4885c7f3934d5c1fd6e86a7a917058b5/dependencies/https___pivotal-buildpacks.s3.amazonaws.com_concourse-binaries_node_node-0.10.42-linux-x64.tgz]
       Downloading and installing npm 2.14.12 (replacing version 1.4.29)...
       npm WARN deprecated This version of npm lacks support for important features,
       npm WARN deprecated such as scoped packages, offered by the primary npm
       npm WARN deprecated registry. Consider upgrading to at least npm@2, if not the
       npm WARN deprecated latest stable version. To upgrade to npm@2, run:
       npm WARN deprecated
       npm WARN deprecated   npm -g install npm@latest-2
       npm WARN deprecated
       npm WARN deprecated To upgrade to the latest stable version, run:
       npm WARN deprecated
       npm WARN deprecated   npm -g install npm@latest
       npm WARN deprecated
       npm WARN deprecated (Depending on how Node.js was installed on your system, you
       npm WARN deprecated may need to prefix the preceding commands with `sudo`, or if
       npm WARN deprecated on Windows, run them from an Administrator prompt.)
       npm WARN deprecated
       npm WARN deprecated If you're running the version of npm bundled with
       npm WARN deprecated Node.js 0.10 LTS, be aware that the next version of 0.10 LTS
       npm WARN deprecated will be bundled with a version of npm@2, which has some small
       npm WARN deprecated backwards-incompatible changes made to `npm run-script` and
       npm WARN deprecated semver behavior.
       npm ERR! network getaddrinfo ENOTFOUND
       npm ERR! network This is most likely not a problem with npm itself
       npm ERR! network and is related to network connectivity.
       npm ERR! network In most cases you are behind a proxy or have bad network settings.
       npm ERR! network
       npm ERR! network If you are behind a proxy, please make sure that the
       npm ERR! network 'proxy' config is set properly.  See: 'npm help config'

       npm ERR! System Linux 3.19.0-49-generic
       npm ERR! command "/tmp/app/.heroku/node/bin/node" "/tmp/app/.heroku/node/bin/npm" "install" "--unsafe-perm" "--quiet" "-g" "[email protected]"
       npm ERR! cwd /tmp/app
       npm ERR! node -v v0.10.42
       npm ERR! npm -v 1.4.29
       npm ERR! syscall getaddrinfo
       npm ERR! code ENOTFOUND
       npm ERR! errno ENOTFOUND
       npm ERR!
       npm ERR! Additional logging details can be found in:
       npm ERR!     /tmp/app/npm-debug.log
       npm ERR! not ok code 0
-----> Build failed

       We're sorry this build is failing! You can troubleshoot common issues here:
       https://devcenter.heroku.com/articles/troubleshooting-node-deploys

       If you're stuck, please submit a ticket so we can help:
       https://help.heroku.com/

       Love,
       Heroku

Failed to compile droplet
Exit status 223
Staging failed: Exited with status 223

FAILED
BuildpackCompileFailed

TIP: use 'cf logs node-test-2 --recent' for more information

I don't believe that vendoring will help here as the build pack is trying to install NPM with the -g flag, which installs it globally and not into the vendored dependencies.

Hi,

Some of my app deps require a rebuild of native modules as seen below:

-------> Buildpack version 1.5.0
-----> Creating runtime environment
       NPM_CONFIG_LOGLEVEL=error
       NPM_CONFIG_PRODUCTION=true
       NODE_MODULES_CACHE=true
-----> Installing binaries
       engines.node (package.json):  0.12.5
       engines.npm (package.json):   2.11.2
       Downloading and installing node 0.12.5...
       npm 2.11.2 already installed with node
-----> Restoring cache
       Loading 1 from cacheDirectories (default):
       - node_modules (exists - skipping)
-----> Building dependencies
       Prebuild detected (node_modules already exists)
       Rebuilding any native modules
       > [email protected] install /tmp/staged/app/node_modules/pm2/node_modules/chokidar/node_modules/fsevents
       > node-gyp rebuild

Is there any exposed flag to prevent this on every cf push?

More of a question than an issue. I'm wondering if there's any plan to do something in the buildpack for FIPS builds? I think someone building the buildpack themselves and adding FIPS builds to the manifest.yml would run into a couple of issues.

1. One is wanting to have two node binaries in manifest.yml with the same version, say 6.0.0. One is the FIPS build and one is the non-FIPS build. The app developer needs a way to select between them, like a new environment variable?

2. The other is turning FIPS mode on/off when using the FIPS build. One way to do this is with the --enable-fips command-line option, so it could definitely be left to the app developer to include in their app's start command. The question is basically should the buildpack automatically do this if the FIPS build is selected, or leave it to the app developer to control?

Any thoughts on this?

Hi There,

Currently, the Node.js buildpack will assume that a user who has not explicitly defined a version of node.js in their package.json will want to use v0.12. As of April 2016 [1] the Node.js long term support release schedule will only support 0.12 in a maintenance capacity.

In order to provide users with a longer active LTS schedule we are proposing to change the default version from v0.12 to v4.

Our preference is to move forward with the change to the buildpack by 3/15/2016. If you have any concerns or feedback please comment on this issue.

[1] - https://raw.githubusercontent.com/nodejs/LTS/master/schedule.png

I need to create a build of Node.js (4.3) with the openssl fips module installed.

See https://github.com/nodejs/node#building-nodejs-with-fips-compliant-openssl

I've built from source on my end and would like to start drafting PR for this buildpack. However, I'm rather new with CF and it seems like the install process, I need to do, doesn't follow the standard model in this repo.

Any advice on how to construct this custom source build through the buildpack process?

Kindly include the Node Engine version 0.10.33 in this build pack.
Kindly add the respective entries in the manifest.yml at the earliest possible.

Shouldn't the 4.x.y versions be added there as well?

I'm trying to deploy an application that has engines.node: "4.2.x" in the packages.json.

bin/generate_versions seems to download 4.x, so compile-extensions#bin/is_cached returns true but the lib/version_resolver.js gives undefined since it only checks files/versions.json where only <=0.12.x are listed

Hi,

I'm not sure why the node-http-proxy web proxy module doesn't work on CF. I'm using a rule-based proxy redirect as seen at https://github.com/strongloop/strong-gateway/blob/master/server/middleware/proxy/index.js . Somehow this doesn't seem to be working.

Here's the snippet:

var express = require('express')
var app = express()
var cors = require('cors')

// start http server
var server = app.listen(process.env.VCAP_APP_PORT, function () {

  var host = server.address().address
  var port = server.address().port

  console.log('Proxying Yookore at http://%s:%s', host, port)

})

// Using strong-gateway's http-proxy wrapper for node-http-proxy
// see https://github.com/strongloop/strong-gateway/blob/master/server/middleware/proxy/index.js
var proxy = require('./strong-gateway/server/middleware/proxy/index')

app.use(cors());
app.use(proxy({
  "rules": [
    "^/auth/v1/(.*)$ http://uas.apps.cf.net/v1/$1 [P]"
}));


// App at http://uas.apps.cf.net/v1
var router = app.Router();
app.use('/v1', router);
router.get('/', function(req, res) {
  return res.status(200).send("Welcome to UAS")
})

I'm curious if there is any continued benefit to being a fork of heroku-buildpack-nodejs.
My biggest complaint is that GitHub does not support Code Search for Forked repos, and from what I can see, the two buildpacks are quite different at this point.

I am trying to deploy Kibana on bluemix PaaS.

https://www.elastic.co/downloads/kibana

Since Kibana is a NodeJs application, it can be deployed as such on bluemix. All i have to do is

1. Provide a simple manifest.yml file that details the app name and a couple of other things
2. Provide a Procfile which has just one line as web: bin/kibana --port=$PORT

and thus i can run Kibana on bluemix PaaS. Note that this is pushed via cloudfoundry.

Also, i was able to install the marvel and sense plugins for Kibana.

Now, i installed the shield plugin. This plugin requires and ssl key and an ssl cert file to run. The path to these files must be provided in the kibana.yml file.

After installation, i tested the shield plugin natively and it worked just fine.

Here is the layout of the directory structure

bin(d)
config(d)
installedPlugins(d)
node_modules(d)
sslFiles(d)
manifest.yml
Procfile

(d) represents directories. he sslFiles folder contains the ssl key and ssl cert files.

Before i could push to bluemix, i knew that the paths ti the ssl files would have to be relative to the app in bluemix, so in the kibana.yml i specified those as

kibana.ssl.key:app/sslFiles/kibana.key
kibana.ssl.cert:app/sslFiles/kibana.cert

i did this as in bluemix, i could see the following directory structure

app(d)
    bin(d)
    config(d)
    installedPlugins(d)
    node_modules(d)
    sslFiles(d)
    manifest.yml
    Procfile

Indentation represents containment. So i pushed it to bluemix PaaS using cloudfoundry, but now i get

502 Bad Gateway: Registered endpoint failed to handle the request.

error. I tried changing the paths to sslFiles/kibana.key but then i got a staging error

cannot find path sslFiles/kibana.key

What is responsible for my 502 error? Is it the path to the sslFiles? If so, how can i properly provide the paths?

here is my cloudfoundry version

cf version 6.18.1+a1103f0-2016-05-24

If there is no buildpack field in app manifest, deploy will fail:

2015-06-08T22:31:51.65-0400 [STG/0] ERR /var/vcap/data/dea_next/admin_buildpacks/6ce24da3-9ad2-49c5-ade4-08d765a01a0e_4697cf36c9216242c86270ec37c0f9622242f2fb/lib/common.sh: line 19: $2: unbound variable
2015-06-08T22:31:51.65-0400 [STG/0] OUT Staging failed: Buildpack compilation step failed
2015-06-08T22:31:51.84-0400 [API/7] ERR encountered error: App staging failed in the buildpack compile phase

In the staging container, the .npm and .node-gyp dir are not in $build_dir, but in /home/vcap, as:

root@181rrc6qa5c:/home/vcap# ll
total 32
drwxr-xr-x  5 vcap vcap 4096 Sep 23 23:17 ./
drwxr-xr-x  3 root root 4096 Sep 23 23:16 ../
-rw-r--r--  1 vcap vcap  220 Apr 19  2010 .bash_logout
-rw-r--r--  1 vcap vcap 3103 Apr 19  2010 .bashrc
drwxr-xr-x  3 vcap vcap 4096 Sep 23 23:17 .node-gyp/
drwxr-xr-x 59 vcap vcap 4096 Sep 23 23:17 .npm/
-rw-r--r--  1 vcap vcap  675 Apr 19  2010 .profile
drwxr-xr-x  2 vcap vcap 4096 Sep 23 23:19 tmp/

so, I think the remove dir code L122-L124 are waste code.

Hello,
I have a nodejs application, it can be deployed and started in CF if the version nodejs buildpack <v 1.5.9, the version of node and npm in package.json of my nodejs application is as below:

, "engines" : {
    "node" : "~0.12.7",
    "npm" : "~2.11.3"
   }

The version of CF release is v235, Diego version is v0.1467.0.

When I deployed my nodejs application to nodejs v1.5.9, there is the following error, do I need change something?

Downloading nodejs_buildpack...

Downloaded nodejs_buildpack (60.7M)

Creating container

Successfully created container

Downloading app package...

Downloaded app package (4.8M)

Staging...

-------> Buildpack version 1.5.11

-----> Creating runtime environment



       NPM_CONFIG_LOGLEVEL=error

       NPM_CONFIG_PRODUCTION=true

       NODE_ENV=production

       NODE_MODULES_CACHE=true

-----> Installing binaries

       engines.node (package.json):  ~0.12.7

       engines.npm (package.json):   ~2.11.3



       Downloading and installing node 0.12.13...

       Downloaded [file:///tmp/buildpacks/d9e57be809c47eef0c67cf7e2b84bbbe/dependencies/https___pivotal-buildpacks.s3.amazonaws.com_concourse-binaries_node_node-0.12.13-linux-x64.tgz]

       Resolving npm version ~2.11.3 via semver.io...

       Downloading and installing npm 2.11.3 (replacing version 2.15.0)...

-----> Restoring cache

       Skipping cache restore (new runtime signature)

-----> Building dependencies

       Prebuild detected (node_modules already exists)

       Rebuilding any native modules



       > [email protected] install /tmp/app/node_modules/mongoskin/node_modules/mongodb/node_modules/bson

       > (node-gyp rebuild 2> builderror.log) || (exit 0)





       > [email protected] install /tmp/app/node_modules/mongoskin/node_modules/mongodb/node_modules/kerberos

       > (node-gyp rebuild 2> builderror.log) || (exit 0)





       > [email protected] install /tmp/app/node_modules/ldapjs/node_modules/dtrace-provider

       > node-gyp rebuild



       gyp: /tmp/app/.heroku/node/common.gypi not found (cwd: /tmp/app/node_modules/ldapjs/node_modules/dtrace-provider) while reading includes of binding.gyp while trying to load binding.gyp

       gyp ERR! configure error

       gyp ERR! stack Error: `gyp` failed with exit code: 1

       gyp ERR! stack     at ChildProcess.onCpExit (/tmp/app/.heroku/node/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:355:16)

       gyp ERR! stack     at ChildProcess.emit (events.js:110:17)

       gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:1078:12)

       gyp ERR! System Linux 3.19.0-28-generic

       gyp ERR! command "node" "/tmp/app/.heroku/node/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"

       gyp ERR! cwd /tmp/app/node_modules/ldapjs/node_modules/dtrace-provider

       gyp ERR! node -v v0.12.13

       gyp ERR! node-gyp -v v2.0.1

       gyp ERR! not ok



       npm ERR! Linux 3.19.0-28-generic

       npm ERR! argv "node" "/tmp/app/.heroku/node/bin/npm" "rebuild" "--nodedir=/tmp/app/.heroku/node"

       npm ERR! node v0.12.13

       npm ERR! npm  v2.11.3

       npm ERR! code ELIFECYCLE

       npm ERR! [email protected] install: `node-gyp rebuild`

       npm ERR! Exit status 1

       npm ERR!

       npm ERR! Failed at the [email protected] install script 'node-gyp rebuild'.

       npm ERR! This is most likely a problem with the dtrace-provider package,

       npm ERR! not with npm itself.

       npm ERR! Tell the author that this fails on your system:

       npm ERR!     node-gyp rebuild

       npm ERR! You can get their info via:

       npm ERR!     npm owner ls dtrace-provider

       npm ERR! There is likely additional logging output above.



       npm ERR! Please include the following file with any support request:

       npm ERR!     /tmp/app/npm-debug.log

-----> Build failed



       We're sorry this build is failing! You can troubleshoot common issues here:

       https://devcenter.heroku.com/articles/troubleshooting-node-deploys



       Some possible problems:



       - node_modules checked into source control

       https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git



       Love,

       Heroku

Does it make sense for you to automatically set max_old_space_size ?
Is it possible to use the configured memory value (cf scale)?
the reason / use case: https://github.com/nodejs/node/wiki/Frequently-Asked-Questions

What version of Cloud Foundry are you using?

cf version 6.19.0+b29b4e0-2016-06-08

What version of the buildpack you are using?

I have reproduced this on IBM SDK for Node.js Buildpack v3.4-20160518-1653 which is based on Node.js Buildpack v1.5.4, as well as on version 1.5.15 which Pivotal uses.

If you were attempting to accomplish a task, what was it you were attempting to do?

To run a npm preinstall script which installs my GitHub deploy key in ~/.ssh while also specifying node version.

What did you expect to happen?

That the preinstall script would run.

What was the actual behavior?

It doesn’t run when I specify a node version. But if I remove the line specifying node version, the preinstall script runs just fine. The error I get when a node version is specified is that npm can’t clone the private GitHub repo in the dependences, which wouldn’t happen if the preinstall script had run.

To reproduce:

{
 "name": "test",
 "version": "0.0.1",
 "scripts": {
   "preinstall": "echo PREINSTALL"
 },
 "dependencies": {
   "convoflow": "github:monieshq/convoflow"
 },
 "engines": {
   "node": "5.11.1"
 }
}

The convoflow dependency is just a private GitHub repo. It needs to be there to reproduce the bug.

When running cf push with the above package.json, it doesn’t echo PREINSTALL.

Remove either the "node" line or the entire "engines" part, and it runs the preinstall script.

Additional comments

I have reported this to IBM Bluemix and Pivotal. Pivotal suggested it should be reported here.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

As of now the release of Node 5.1.0 is stable, even though it has no LTS. Could you please add it to the manifest?

The Heroku Node Buildpack added support for io.js with this pull request on the 14th January.

heroku/heroku-buildpack-nodejs#181

Please can you update from upstream at Heroku to enable io.js support on Cloud Foundry.
Thanks.

Node.js does not support ECMA-402 by default. Now I want to rebuild a node.js binary to include ECMA-402 support with ./configure --with-intl=full-icu --download=all. How can I have this buildpack to push the customized node.js to Bluemix as a buildpack?

I checked file nodejs-buildpack-master\lib\binaries.sh, I saw the following instructions:
echo "Downloading and installing node $version..."
local download_url="http://s3pository.heroku.com/node/v$version/node-v$version-$os-$cpu.tar.gz"
(curl translate_dependency_url $download_url -s --fail -o - | tar xzf - -C /tmp) || (echo -e "\n-----> Resource $download_url does not exist." 1>&2 ; exit 22)
mv /tmp/node-v$version-$os-$cpu/* $dir
chmod +x $dir/bin/*
Can I overwrite the instructions to the node.js with ECMA-402 support?

Intl (ECMA-402) support:

Intl support is not
enabled by default.

Build with full ICU support (all locales supported by ICU):

With the --download=all, this may download ICU if you don't
have an ICU in deps/icu.

Unix/Macintosh:

./configure --with-intl=full-icu --download=all

Opened a discussion here: https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/QXbHOuNXAt8

Currently, when installing the dependencies for a user's Node app, we run this command:
npm install --userconfig $build_dir/.npmrc --production 2>&1 | indent

Seems that it would be valuable to give users the option to disable the "--production" flag so that their "devDependencies" in package.json can be installed. One use case is for developers who want their grunt dependencies installed on production, but it's a hassle because those dependencies are generally under "devDependencies".

Heroku's Node.js bulidpack supports this functionality via NPM_CONFIG_PRODUCTION

I'd be happy to open a PR should we decide to include this support!

For AppDynamics service, in case of nodejs-buildpack I need to access system variables. So that the application can be monitored on AppDynamics Controller.

Do we need to add an extension file. What language should i prefer to write an extension for NodeJs-Buildpack.

I am running into an issue when using the buildpack version 1.5.15 and trying to use the node-oracledb module. in order to compile the native module it needs some oracle dependencies. I am getting the error below. I am struggling to figure out where I could customize the buildpack to install these dependencies. could someone guide me as to how I would customize the buildpack for this?

node-oracledb ERR! Error: Cannot find Oracle library libclntsh.so
       node-oracledb ERR! Error: See https://github.com/oracle/node-oracledb/blob/master/INSTALL.md
       gyp: Call to 'INSTURL="https://github.com/oracle/node-oracledb/blob/master/INSTALL.md"; ERR="node-oracledb ERR! Error:"; if [ -z $OCI_LIB_DIR ]; then OCI_LIB_DIR=`ls -d /usr/lib/oracle/*/client*/lib/libclntsh.* 2> /dev/null | tail -1 | sed -e 's#/libclntsh[^/]*##'`; if [ -z $OCI_LIB_DIR ]; then if [ -z "$ORACLE_HOME" ]; then if [ -f /opt/oracle/instantclient/libclntsh.so ]; then echo "/opt/oracle/instantclient/"; else echo "$ERR Cannot find Oracle library libclntsh.so" >&2; echo "$ERR See $INSTURL" >&2; echo "" >&2; fi; else if [ -f "$ORACLE_HOME/lib/libclntsh.so" ]; then echo $ORACLE_HOME/lib; else echo "$ERR Cannot find $ORACLE_HOME/lib/libclntsh.so" >&2; echo "$ERR See $INSTURL" >&2; echo "" >&2; fi; fi; else if [ -f "$OCI_LIB_DIR/libclntsh.so" ]; then echo $OCI_LIB_DIR; else echo "$ERR Cannot find $OCI_LIB_DIR/libclntsh.so" >&2; echo "$ERR See $INSTURL" >&2; echo "" >&2; fi; fi; else if [ -f "$OCI_LIB_DIR/libclntsh.so" ]; then echo $OCI_LIB_DIR; else echo "$ERR Cannot find $OCI_LIB_DIR/libclntsh.so" >&2; echo "$ERR See $INSTURL" >&2; echo "" >&2; fi; fi;' returned exit status 0 while in binding.gyp. while trying to load binding.gyp
       gyp ERR! configure error
       gyp ERR! stack Error: `gyp` failed with exit code: 1
       gyp ERR! stack     at ChildProcess.onCpExit (/tmp/staged/app/.heroku/node/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:305:16)
       gyp ERR! stack     at emitTwo (events.js:87:13)
       gyp ERR! stack     at ChildProcess.emit (events.js:172:7)
       gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
       gyp ERR! System Linux 3.19.0-51-generic
       gyp ERR! command "/tmp/staged/app/.heroku/node/bin/node" "/tmp/staged/app/.heroku/node/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
       gyp ERR! cwd /tmp/staged/app/node_modules/oracledb
       gyp ERR! node -v v4.4.5
       gyp ERR! node-gyp -v v3.3.1
       gyp ERR! not ok
       npm ERR! Linux 3.19.0-51-generic
       npm ERR! argv "/tmp/staged/app/.heroku/node/bin/node" "/tmp/staged/app/.heroku/node/bin/npm" "rebuild" "--nodedir=/tmp/staged/app/.heroku/node"
       npm ERR! node v4.4.5
       npm ERR! npm  v2.15.5
       npm ERR! code ELIFECYCLE
       npm ERR! [email protected] install: `node-gyp rebuild`
       npm ERR! Exit status 1
       npm ERR!
       npm ERR! Failed at the [email protected] install script 'node-gyp rebuild'.
       npm ERR! This is most likely a problem with the oracledb package,
       npm ERR! not with npm itself.
       npm ERR! Tell the author that this fails on your system:
       npm ERR!     node-gyp rebuild
       npm ERR! You can get information on how to open an issue for this project with:
       npm ERR!     npm bugs oracledb
       npm ERR! Or if that isn't available, you can get their info via:
       npm ERR!
       npm ERR!     npm owner ls oracledb
       npm ERR! There is likely additional logging output above.
       npm ERR! Please include the following file with any support request:
       npm ERR!     /tmp/staged/app/npm-debug.log

Seems we are missing some important logic to install any new modules when rebuilding existing dependencies

You used to have it:

We should install any new dependencies after doing the "rebuild". This allows some dependencies to be pushed with the application in "node_modules", and others to be downloaded as specified in package.json

My scenario that caused this issue:
Push fresh application (no cache) with undeclared dependencies in node_modules. This is considered prebuilt, so it rebuilds the dependencies I've included in node_modules. However, I had express in my package.json (but not in node_modules), and it never got installed.

Im trying the new 1.3 buildpack with my approach (uploading my private node_modules, see: #11 (comment))
And now you do npm prune => https://github.com/cloudfoundry/nodejs-buildpack/blob/master/lib/build.sh#L283

this breaks my approach...

PS. I call an own script as preinstall script

Steps to reproduce:

1.) Create an empty folder.
2.) Add this package.json file.

{
  "name": "bson-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "bson-ext": "^0.1.13"
  },
  "engines": {
    "node": "4.3.2"
  }
}

3.) Add this index.js file.

var bson = require('bson-ext');
var http = require('http');

http.createServer(function (req, res) {
      res.writeHead(200, {'Content-Type': 'text/plain'});
      for (var env in process.env) {
          res.write(env + '=' + process.env[env] + '\n');
      }
      res.end();
}).listen(process.env.PORT || 3000);

4.) Run npm install. That should build the library locally.

# npm rebuild --unsafe-perm

> [email protected] install /root/bson-test/node_modules/bson-ext
> (node-gyp rebuild 2> builderror.log) || (exit 0)

make: Entering directory `/root/bson-test/node_modules/bson-ext/build'
  CXX(target) Release/obj.target/bson/ext/bson.o
  SOLINK_MODULE(target) Release/obj.target/bson.node
  COPY Release/bson.node
make: Leaving directory `/root/bson-test/node_modules/bson-ext/build'

You can confirm it's built by running find . -name "*.node". You should see this.

# find . -name "*.node"
./node_modules/bson-ext/build/Release/obj.target/bson.node
./node_modules/bson-ext/build/Release/bson.node

You can also run npm start and it should start without error.

5.) Push the application to a CF installation that does not have Internet access. An easy way to simulate this is by unbinding all the staging security groups.

When pushed, staging will succeed but the module will not have been built and the application will fail to start.

The issue is that node-gyp will helpfully try to download the Node source code required to build the native module (node headers not module source code). If you point node-gyp to the existing headers it will build without needing to go to the Internet.

nodejs/node-gyp#235

The way to do that seems to be this.

npm rebuild --nodedir=$build_dir/.heroku/node 2>&1

Tested with a handful of native modules (bson-ext, libxmljs, brcypt and oracle) and they all work without needing the Internet.

The buildpack raised error when bump the version up to 4.0.0.

There's a thrid party buildpack

http://jamesthom.as/blog/2015/09/18/node-dot-js-v4-in-cloud-foundry/

I hope there's someone in CF would come up an official version soon. ES6 needed!

I noticed that almost 100 commits were pushed to master a few days back, even though the commit history makes it seem like they were being made iteratively. Is there any reason these commits are being held private and pushed all at once?

It makes it particularly hard to keep forks in-sync with the community's master branch if there are massive changes made all at once. In addition, it's painful to identify all the different changes that were made.

The last major merge happened around 6 months ago with major refactors to the compile code, caching logic and file structure. There was almost no activity in this repository since then, and now suddenly there's almost 100 new commits.

Hi,

I would like to know how to call cloud foundry API from a node.js application deployed.

From local, it is very easy to call the API using the absolute address:

https://api.MY_PUBLIC_IP.xip.io/v2/info
http://apidocs.cloudfoundry.org/214/info/get_info.html

but if I deploy a node application, I can't connect with the API.

Does exist a way to call the API from a application deployed?

Many thanks in advance

Juan Antonio

I've recently started investigating a memory issue with Node.js apps running in Cloud Foundry environments (I'm using CFv210). As an example, if I push a Node.js app with a mem leak and a 512MB memory limit, the Node.js V8 engine tries to allocate more and more memory until it passes that memory limit and the application crashes. The behavior I expect to see is that it will stop trying to allocate more memory when it reaches the limit, and instead try to GC more aggressively (and then crash at a later time). Has anyone else seen this behavior?

By default, on 64 bit machines, the Node.js v8 engine has a 1GB heap limit, so I can see why the engine tries to allocate more than is really available. There should be some way to prevent the Node.js v8 engine from trying to allocate more than is available. In Java, you can use JVM opts to set heap limits, maybe something similar?

I did find one thing that might help, --max-old-space-size. But... has any one done any investigation as to how to set that space size? "--max-old-space-size" only accounts for the v8 engine's heap, not the buffers or other processes. For example, should that limit be set to 50% of the memory_limit? 75%? Maybe that's something the Node.js buildpack should set as a reasonable default?

There is a separate issue that might be related to this. When I run 'free' or 'top' as a shell command from within the container spun up for my application, I am seeing "32gb" total. When I run commands like "os.totalmem()" from within Node.js, I'm also seeing 32gb. Although this is a problem that probably cannot be avoided due to use of cgroups, I wonder if this contributes to the memory issue.

I'm currently using the offline buildpack on my own cloudfoundry instance and i ran npm install before pushing my app to have all my dependencies already in the app. But when the app staging the compilation run npm rebuild and this command go to download nodejs source (i don't know why) from internet which is pretty annoying when you are offline :)
I know that the compile script come from heroku but Is there a way to make it not download nodejs source?

Recreate the issue by following this instruction for example:

1. Download https://github.com/cloudfoundry-community/etherpad-lite-cf/releases/download/1.4.0-cf/etherpad-lite-cf.zip (this is a nodejs app which already set for being offline)
2. Extract the archive
3. go to extracted archive
4. push the app
5. In log we can see http get from npm

hi,

We suddenly started seeing below errors in all our NodeJS apps:

2016-01-14T23:35:32.14+0200 [App/0]      ERR events.js:85
2016-01-14T23:35:32.14+0200 [App/0]      ERR       throw er; // Unhandled 'error' event
2016-01-14T23:35:32.14+0200 [App/0]      ERR             ^
2016-01-14T23:35:32.14+0200 [App/0]      ERR Error: connect ECONNREFUSED
2016-01-14T23:35:32.14+0200 [App/0]      ERR     at exports._errnoException (util.js:746:11)
2016-01-14T23:35:32.14+0200 [App/0]      ERR     at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1010:19)

No firewall setup on our CF network and I'm using v1.4.2 and v1.5.0 versions of the buildpack.

Any ideas please?

Would be beneficial to have newrelic bundled similar to the java buildpack, with configuration driven through environment variables.

http://stackoverflow.com/questions/20688914/bundle-install-fails-because-of-git-protocol

I run into the above issue, when I run "bundle" behind the http proxy.

I am trying to deploy loopback application using this buildpack. I have created a Procfile with content web: node . to start application.

build goes fine but application does not come up. Here is the log:

2015-06-12T12:40:28.97+0530 [API/0] OUT Updated app with guid 9ab51745-f6fc-4888-9a8d-7b002179cb2d ({"name"=>"spordz-dev", "buildpack"=>"https://github.com/cloudfoundry/buildpack-nodejs.git"})
2015-06-12T12:41:20.67+0530 [API/4] OUT Updated app with guid 9ab51745-f6fc-4888-9a8d-7b002179cb2d ({"state"=>"STOPPED"})
2015-06-12T12:41:24.84+0530 [DEA/36] OUT Got staging request for app with id 9ab51745-f6fc-4888-9a8d-7b002179cb2d
2015-06-12T12:41:48.43+0530 [API/8] OUT Updated app with guid 9ab51745-f6fc-4888-9a8d-7b002179cb2d ({"state"=>"STARTED"})
2015-06-12T12:41:48.68+0530 [STG/36] OUT -----> Downloaded app package (2.4M)
2015-06-12T12:41:56.96+0530 [STG/36] OUT -----> Downloaded app buildpack cache (226M)
2015-06-12T12:41:57.15+0530 [STG/0] ERR Cloning into '/tmp/buildpacks/buildpack-nodejs'...
2015-06-12T12:41:58.92+0530 [STG/0] OUT Submodule 'compile-extensions' (https://github.com/cloudfoundry-incubator/compile-extensions.git) registered for path 'compile-extensions'
2015-06-12T12:41:59.01+0530 [STG/0] ERR Cloning into 'compile-extensions'...
2015-06-12T12:41:59.79+0530 [STG/0] OUT Submodule path 'compile-extensions': checked out 'a846bb56f980a270261fb2a468af95df77d4ceac'
2015-06-12T12:41:59.87+0530 [STG/0] OUT -------> Buildpack version 1.3.4
2015-06-12T12:41:59.92+0530 [STG/0] OUT Node.js Buildpack v64
2015-06-12T12:41:59.92+0530 [STG/0] OUT -----> Reading application state
2015-06-12T12:41:59.92+0530 [STG/0] OUT package.json...
2015-06-12T12:41:59.94+0530 [STG/0] OUT build directory...
2015-06-12T12:41:59.95+0530 [STG/0] OUT cache directory...
2015-06-12T12:41:59.97+0530 [STG/0] OUT environment variables...
2015-06-12T12:41:59.97+0530 [STG/0] OUT Node engine range: 0.10.37
2015-06-12T12:41:59.97+0530 [STG/0] OUT Npm engine: 2.11.1
2015-06-12T12:41:59.97+0530 [STG/0] OUT Start mechanism: Procfile
2015-06-12T12:41:59.97+0530 [STG/0] OUT node_modules source: package.json
2015-06-12T12:41:59.97+0530 [STG/0] OUT node_modules cached: true
2015-06-12T12:41:59.99+0530 [STG/0] OUT NPM_CONFIG_PRODUCTION=true
2015-06-12T12:41:59.99+0530 [STG/0] OUT NODE_MODULES_CACHE=true
2015-06-12T12:42:00.56+0530 [STG/0] OUT Downloading and installing node 0.10.37...
2015-06-12T12:42:02.34+0530 [STG/0] OUT Downloading and installing npm 2.11.1 (replacing version 1.4.28)...
2015-06-12T12:42:11.27+0530 [STG/0] OUT -----> Building dependencies
2015-06-12T12:42:11.55+0530 [STG/0] OUT Restoring node modules from cache
2015-06-12T12:42:12.67+0530 [STG/0] OUT Pruning unused dependencies
2015-06-12T12:42:13.42+0530 [STG/0] OUT npm WARN package.json [email protected] No license field.
2015-06-12T12:42:15.06+0530 [STG/0] OUT valid
2015-06-12T12:42:15.06+0530 [STG/0] OUT Installing node modules
2015-06-12T12:42:15.86+0530 [STG/0] OUT npm WARN package.json [email protected] No license field.
2015-06-12T12:42:17.54+0530 [STG/0] OUT -----> Checking startup method
2015-06-12T12:42:17.54+0530 [STG/0] OUT Found Procfile
2015-06-12T12:42:17.54+0530 [STG/0] OUT web: node .
2015-06-12T12:42:17.55+0530 [STG/0] OUT -----> Finalizing build
2015-06-12T12:42:17.55+0530 [STG/0] OUT Creating runtime environment
2015-06-12T12:42:17.55+0530 [STG/0] OUT Cleaning previous cache
2015-06-12T12:42:18.01+0530 [STG/0] OUT Caching results for future builds
2015-06-12T12:42:19.36+0530 [STG/0] OUT -----> Build succeeded!
2015-06-12T12:42:20.04+0530 [STG/0] OUT [email protected] /tmp/staged/app
2015-06-12T12:42:20.04+0530 [STG/0] OUT ├── [email protected]
2015-06-12T12:42:20.04+0530 [STG/0] OUT ├── [email protected]
2015-06-12T12:42:20.04+0530 [STG/0] OUT ├── [email protected]
2015-06-12T12:42:20.04+0530 [STG/0] OUT ├── [email protected]
2015-06-12T12:42:20.04+0530 [STG/0] OUT ├── [email protected]
2015-06-12T12:42:20.04+0530 [STG/0] OUT ├── [email protected]
2015-06-12T12:42:20.04+0530 [STG/0] OUT ├── [email protected]
2015-06-12T12:42:20.04+0530 [STG/0] OUT └── [email protected]
2015-06-12T12:42:25.42+0530 [STG/36] OUT -----> Uploading droplet (21M)
2015-06-12T12:43:06.85+0530 [DEA/140] OUT Removing crash for app with id 9ab51745-f6fc-4888-9a8d-7b002179cb2d
2015-06-12T12:43:06.85+0530 [DEA/140] OUT Stopping app instance (index 0) with guid 9ab51745-f6fc-4888-9a8d-7b002179cb2d
2015-06-12T12:43:06.85+0530 [DEA/140] OUT Stopped app instance (index 0) with guid 9ab51745-f6fc-4888-9a8d-7b002179cb2d
2015-06-12T12:43:10.20+0530 [DEA/36] OUT Starting app instance (index 0) with guid 9ab51745-f6fc-4888-9a8d-7b002179cb2d
2015-06-12T12:43:33.27+0530 [API/3] OUT App instance exited with guid 9ab51745-f6fc-4888-9a8d-7b002179cb2d payload: {"cc_partition"=>"default", "droplet"=>"9ab51745-f6fc-4888-9a8d-7b002179cb2d", "version"=>"839845b0-04ed-4da6-9312-7ef3b53d0668", "instance"=>"81ce48aadc394fe38f0ce708d8201602", "index"=>0, "reason"=>"CRASHED", "exit_status"=>127, "exit_description"=>"app instance exited", "crash_timestamp"=>1434093213}

Any idea whats going wrong?

each node buildpacks has different node version supports like the followings.

The versions of node supported in this buildpack are:
- 4.2.2
- 0.12.7
- 0.12.6
- 0.11.16
- 0.11.15
- 0.10.40
- 0.10.38

I am wondering if there is any option to select just latest node version in buildpack.
Now according to my test result, it seems like default node version is not the latest.

the problem is when I update the node buildpack.
it node apps doesn't apply this key, all node apps running on my cf should be changed their package.json configuration.

Please let me know. Thank you :)

In order to test in the same environment with the nodejs-buildpack in concourse CI, we create the docker image including the nodejs-buildpack.
While executing the compile command, The following error was occurred in our concourse CI.

-------> Buildpack version 1.5.19
/tmp/buildpack/lib/vendor/new_relic/install.sh: line 15: VCAP_APPLICATION: unbound variable

The enviroment variable VCAP_APPLICATION becomes required from nodejs-buildpack-v1.5.19.
https://github.com/cloudfoundry/nodejs-buildpack/blob/master/bin/compile#L41

New Relic isn't necessary in most environments, so we want to disable it by settings.

What version of Cloud Foundry are you using?

What version of the buildpack you are using?
nodejs-buildpack-v1.5.19

If you were attempting to accomplish a task, what was it you were attempting to do?

What did you expect to happen?
I want to test in the same environment with the nodejs-buildpack in concourse CI.

What was the actual behavior?
The above error was occurred in our concourse CI.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction