name

The unique name of your package and should be down in lowercase. This property is required and your package will not install without it.

This also indicates the name of you package in the public node module registry (if you choose to publish it)

If you deploy your application on Nodejitsu, this property will represent the name of your application.

version

The version of the package is specified by Semantic Versioning. Which assumes that a version number is written as MAJOR.MINOR.PATCH and you increment the:

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards-compatible manner
PATCH version when you make backwards-compatible bug fixes

description

The description of the project. Try to keep it short and concise.

author

The author of this package. Hopefully one day soon, it will be your name!

contributors

An array of objects representing contributors to the project. Each object in the array represents one contributor.

bin

A object which is used to expose binary scripts from your package. The object assumes that the key is the name of the binary script and the value a relative path to the script.

This property is used by packages that contain a contain a CLI (command line interface).

script

A object which exposes addition npm commands. The object assumes that the key is the npm command and the value is the script path. These scripts can get executed when you run npm run {command name} or npm run-script {command name}.

Packages that contain a command line interface and are installed locally can be called without a relative path. So instead of doing ./node-modules/.bin/mocha you can directly call mocha.

test

The test script for this package. When running npm test this script will be called.

start

The start-up script for the package. When running npm start this script will be called.

If you've deployed your application to Nodejitsu this property will be required and can be a relative path to the script that should be started.

predeploy

The pre-deploy script for this application. This script will run before a snapshot of your package has been created. It can therefor be used to compile and optimize assets before it's uploaded to your application.

postdeploy

The post-deploy script for this application. This script will run after the application has been deployed.

prepublish

This pre-publish script is called before your package is published to the npm registry. If you are using a programming language that compiles to JavaScript you can put the compilation step here and add the required package to your devDependencies.

main

The main entry point to your package. When calling require('{module name}') in node, this will be the actual file that is required.

It's highly advised that requiring the main file does not generate any side affects. For instance, requiring the main file should not start up an HTTP server or connect to a database. Instead, you should create something like a exports.init = function () {} in your main script.

repository

An object which is used to the specify the URL and type of source code repository. This is helpful for people who want to contribute to your module.

In our case we specify a git repository as our code is hosted on GitHub

bugs

The URL and/or email address where bugs should be reported.

keywords

An Array of keywords which describe your package. This will help people find your package.

dependencies

An object which contain the dependencies of your package. This will be automatically installed when people install your package. The key of the object is the name of the package and the value is a valid semver range.

dependencies.primus

Require the Primus module as a dependency with a wildcard (*) version. Using a wildcard version is usually NOT recommended as the latest version of this module is installed which could contain breaking API changes.

dependencies.async

Require the async module as a dependency. The ~ in this version is basically a shorthand for >= 0.8.0 < 0.9.0.

The hope here, is that the package author has followed best-practices and patch versions of the package will NOT be breaking.

dependencies.express

Require the express module as a dependency. The ^ in this version is a shorthand for >=4.2.0 < 5.0.0.

The hope here, is that the package author has followed best-practices and patch versions of the package will NOT be breaking.

dependencies.winston

Require the winston module as a dependency directly from GitHub as git repository. The #master specifies which branch or SHA should be installed.

dependencies.bigpipe

Require the bigpipe module as a dependency directly from GitHub. Please note that this will install the master branch of the repository. It's great for development but not recommended for production usage.

dependencies.plates

Require the plates module as a dependency directly from GitHub. Links take the form of https://github.com/:username/:reponame/tarball/:branchname

devDependencies

These are the dependencies that are only intended for development and testing of your module. The dependencies will be installed automatically unless the NODE_ENV=production environment variable has been set. If this is the case you can still these packages using npm install --dev

devDependencies.vows

Require the vowsmodule as development dependency. The ^ in the version is a shorthand for >=0.7.0 < 1.0.0.

devDependencies.assume

Require the assume module as development dependency. The version that gets installed has to satisfy the given semver range.

devDependencies.pre-commit

Require the pre-commit module as development dependency using a wildcard version. Using * as wildcard is usually NOT recommended. The pre-commit module is unique as it's API will never change and only interacts with git hooks when installed.

preferGlobal

A property that indicates that this page prefers to be installed globally using npm install -g {module-name}. This property is used by packages that contain a CLI (command line interface).

In all other situations you should NOT use this property.

private

By setting private to true, npm will refuse to publish it. This prevents accidental publishes to the public npm registry.

Keeping modules unpublished because they are private is really painful to manage and deploy. A better option might be to use the publishConfig property to publish your private modules to your private npm

publishConfig

The publishConfig is an object with configuration values that will be used for publishing modules. The configuration values that are set override your default npm configuration.

The most common use of the publishConfig is to publish your package to a private npm registry so you still have the benifits of npm but for private packages. This is done by simply setting URL of your private npm as value for the registry key.

If you don't have a private npm registry, you can get one over at Nodejitsu. https://www.nodejitsu.com/try/private-npm/

subdomain

Specifies the subdomain for your application. It should only include the subdomain not the root domain and is limited to one level.

analyze

At Nodejitsu, we will automatically attempt to scan packages for missing dependencies, bugs, and syntax errors. If you are confident your package is correct you can set analyze to false.

license

Under which Open Source you code has been released.

MIT is a good choice.

package.json An interactive guide