Recent Changes in Node.js Modules Support

Since Cloud Foundry introduced npm support, we added several improvements that make deploying Node.js applications with dependencies easier, faster and more transparent to developers.

Easy development

When we introduced npm support in Node.js, in addition to generating “npm-shrinkwrap.json” file with locked down dependencies you were required to remove the “node_modules” folder. If this was too disruptive, you could create an “cloudfoundry.json” file with an “ignoreNodeModules” property set to ‘true’.

This wasn’t an obvious solution. So we decided to change it. Detection of native modules is now done automatically by analyzing module contents. To lock down module versions, you can simply use the “npm shrinkwrap” command and your application is ready to be pushed with or without bundled modules. With this change, we have deprecated ignoreNodeModules property.

If you want to store your application in a git repository without node modules, the next time someone clones it, he/she can just push it to CloudFoundry.com without any modifications.

Fast deployment

In addition to npm, we also improved our cache system. There are two levels of caching now — fetched and compiled modules. All modules that have been fetched from the npm registry are cached locally and pulled from that cache from that point on. If a module contains native code, it gets compiled on Cloud Foundry and the compiled version gets cached as well.

Based on the information from npm-shrinkwrap.json, Cloud Foundry checks if the module has been provided with the application itself. If it is there, and contains native code, it rebuilds it as needed. If the module hasn’t been provided with the app, Cloud Foundry checks the local cache for the given module, and if it needs compilation, provides the cached version.

As module contents can be modified by users, we are using hash of module files as a cache key.

Local modules

There may be situations when you need to customize an existing node module or move a part of your application as a reusable module. In this case, you would want your local module to be used without any modifications and be rebuilt, should it contain native code.

With automatic detection of native code – such modules will be rebuilt on Cloud Foundry and cached, based on their contents for your next push.

More informative logging

In addition to these node improvements, you can now see a detailed log of what’s going on in log files. You can get log messages by running:

vmc logs application-name

We can see if npm support is enabled (npm-shrinkwrap.json was provided) and which node version we are using:

Installing dependencies. Node version 0.6.8

For each node module we can see its installation status:

Installing express@2.5.11 from local path

In case of a failure we can see an error message and/or npm error output.:

Failed installing bcrypt@0.5.0: Node version requirement >= 0.6.0 is not compatible with the current node version 0.4.12

Node-gyp

Modules using node-gyp for the installation process are now supported on CloudFoundry.com for node08 runtime. For node06 and node04 runtimes, Cloud Foundry falls back to node-waf if the module provides the wscript file.

Git URLs

Another recent improvement is that we also support git URLs in npm-shrinkwrap.json. They can be specified in “from” or “version” fields according to npm requirements and both methods are supported. We have a separate cache for git modules and they also get compiled on Cloud Foundry if they have native extensions.

Example

In the previous blog post on auto-reconfiguration we used a Node app, “calipso”, and performed additional steps for npm support. Let’s see how pushing calipso works now.

That’s it! We didn’t need to configure our application at all. In addition, notice that staging process was faster and the preparation was effortless. When we look at the logs we can see how everything went. Try it and see how easy it is to manage your dependencies in Node.js applications now.