npm package.json template for quickly creating a Node.js package with all options visible at a glance with comments

package.json

{
  // WARNING: This file needs to be pure JSON, be sure to remove all comments
  //
  //====================================
  // The "author" is one person. A "person" is an object with a "name" field and optionally
  // "url" and "email" (both email and url are optional).
  //
  // This field can also be shortened to a single string that npm will parse.
  //
  //"author": "FirstName LastName <[email protected]> (http://www.company.com)",
  "author": {
    "email": "[email protected]",
    "name": "FIrstName LastName",
    "url": "http://www.company.com"
  },
  // A lot of packages have one or more executable files that they'd like to install into the
  // PATH. npm makes this pretty easy (in fact, it uses this feature to install the "npm" executable.)
  //
  // To use this, supply a bin field in your package.json which is a map of command name to local file
  // name. On install, npm will symlink that file into prefix/bin for global installs, or
  // ./node_modules/.bin/ for local installs.
  //
  // If you have a single executable, and its name should be the name of the package, then you can just
  // supply it as a string.
  //
  //"bin": "lib/mypackage.js",
  "bin": {
    "cli-bin-one", "lib/mypackage.js",
    "cli-bin-two", "lib/mypackage.js"
  },
  // The url to your project's issue tracker and / or the email address to which issues should
  // be reported. These are helpful for people who encounter issues with your package.
  //
  // You can specify either one or both values. If you want to provide only a url, you can
  // specify the value for "bugs" as a simple string instead of an object.
  //
  //If a url is provided, it will be used by the npm bugs command.
  //
  //"bugs": "http://www.github.com/user/myproject/issues",
  "bugs": {
    "email": "[email protected]",
    "url": "http://www.github.com/user/myproject/issues"
  },
  // Array of package names that will be bundled when publishing the package.
  // If this is spelled "bundleDependencies", then that is also honorable.
  "bundledDependencies": [
    "pkg1",
    "pkg2"
  ],
  // A "config" object can be used to set configuration parameters used in package scripts that
  // persist across upgrades. Config options are turned into environment variables with a name
  // that consists of npm_package_ plus the underscore concatenated names of keys leading up to
  // the value.
  "config": {
    "config" : {
      "port" : "8080" //npm_package_config_port
    },
    "name": "foo" //npm_package_name
  },
  // The "contributors" is a list persons. A "person" is an object with a "name" field and optionally
  // "url" and "email" (both email and url are optional).
  //
  // This field can also be shortened to a single string that npm will parse.
  //
  //"contributors": [ "FirstName LastName <[email protected]> (http://www.company.com)" ],
  "contributors": [
    {
      "email": "[email protected]",
      "name": "FIrstName LastName",
      "url": "http://www.company.com"
    }
  ],
  // If your code only runs on certain cpu architectures, you can specify which ones.
  // Like the os option, you can also blacklist architectures.
  "cpu": [
    "x64",
    "ia32",
    "!arm",
    "!mips"
  ],
  // Dependencies are specified in a simple object that maps a package name to a version range.
  // The version range is a string which has one or more space-separated descriptors. Dependencies can
  // also be identified with a tarball or git URL.
  //
  // Allowed version strings:
  // * version  : Must match version exactly
  // * >version  : Must be greater than version
  // * >=version  : etc
  // * <version
  // * <=version
  // * ~version  : "Approximately equivalent to version" See semver(7)
  // * ^version  : "Compatible with version" See semver(7)
  // * 1.2.x  : 1.2.0, 1.2.1, etc., but not 1.3.0
  // * http://...  : URL of tarball to be installed locally at install time
  // * *  : Matches any version
  // * ""  : (just an empty string) Same as *
  // * version1 - version2  : Same as >=version1 <=version2.
  // * range1 || range2  : Passes if either range1 or range2 are satisfied.
  // * git...  : Standard GIT URL to be checked out and installed locally at install time
  // * user/repo  : Short hand for GIT URL
  // * tag  : A specific version tagged and published as tag See npm-tag(1)
  // * file:path/path/path  : Local path to package to be installed locally at install time
  //
  "dependencies" : {
    "foo": "1.0.0 - 2.9999.9999",
    "bar": ">=1.0.2 <2.1.2",
    "baz": ">1.0.2 <=2.3.4",
    "boo": "2.0.1",
    "qux": "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0",
    "asd": "http://asdf.com/asdf.tar.gz",
    "til": "~1.2",
    "elf": "~1.2.3",
    "two": "2.x",
    "thr": "3.3.x",
    "lat": "latest",
    "dyl": "file:../dyl"
  },
  // Put a description in it. It's a string. This helps people discover your package, as it's
  // listed in npm search.
  "description": "My package description",
  // If someone is planning on downloading and using your module in their program, then they
  // probably don't want or need to download and build the external test or documentation framework that
  // you use.
  //
  // In this case, it's best to map these additional items in a devDependencies object.
  //
  // These things will be installed when doing npm link or npm install from the root of a package, and
  // can be managed like any other npm configuration param. See npm-config(7) for more on the topic.
  //
  // For build steps that are not platform-specific, such as compiling CoffeeScript or other languages to
  // JavaScript, use the prepublish script to do this, and make the required package a devDependency.
  //
  // The prepublish script will be run before publishing, so that users can consume the functionality without
  // requiring them to compile it themselves. In dev mode (ie, locally running npm install), it'll run this script
  // as well, so that you can test it easily.
  "devDependencies": {
    "coffee-script": "~1.6.3"
  },
  // The CommonJS Packages spec details a few ways that you can indicate the structure of your package
  // using a directories object. If you look at npm's package.json, you'll see that it has directories for doc, lib, and man.
  //
  // CommonJS Packages spec: http://wiki.commonjs.org/wiki/Packages/1.0
  //
  // In the future, this information may be used in other creative ways.
  "directories": {
    "bin": "./bin",
    "doc": "./doc",
    "jars": "./jars",
    "lib": "./lib",
    "man": "./man",
    "src": "./src",
    "test": "./test"
  },
  // Specify the version of node that your stuff works on:
  // Like with dependencies, if you don't specify the version (or if you specify "*" as the version), then any version of
  // node will do.
  //
  // If you specify an "engines" field, then npm will require that "node" be somewhere on that list. If "engines" is omitted,
  // then npm will just assume that it works on node.
  //
  // You can also use the "engines" field to specify which versions of npm are capable of properly installing your
  // program. Note that, unless the user has set the engine-strict config flag, the npm field is advisory only.
  "engines": {
    "node" : ">=0.10.3 <0.12",
    "npm" : "~1.0.20"
  },
  // NOTE: This feature is deprecated and will be removed in npm 3.0.0.
  //
  // If you are sure that your module will definitely not run properly on versions of Node/npm other than those specified
  // in the engines object, then you can set "engineStrict": true in your package.json file. This will override the user's
  // engine-strict config setting.
  //
  // Please do not do this unless you are really very very sure. If your engines object is something overly restrictive, you
  // can quite easily and inadvertently lock yourself into obscurity and prevent your users from updating to new versions of
  // Node. Consider this choice carefully.
  "engineStrict": false,
  // The "files" field is an array of files to include in your project. If you name a folder
  // in the array, then it will also include the files inside that folder. (Unless they would be ignored
  // by another rule.)
  //
  // You can also provide a ".npmignore" file in the root of your package, which will keep files from
  // being included, even if they would be picked up by the files array. The ".npmignore" file works just
  // like a ".gitignore".
  "files": [ 
    "app",
    "assets",
    "bin",
    "controllers",
    "doc",
    "models",
    "public",
    "spec",
    "src",
    "test",
    "tests",
    "views"
  ],
  // The url to the project homepage.
  //
  // NOTE: This is not the same as "url". If you put a "url" field, then the registry will think
  // it's a redirection to your package that has been published somewhere else, and spit at you.
  "homepage": "http://www.github.com/user/myproject",
  // Put keywords in it. It's an array of strings. This helps people discover your package
  // as it's listed in npm search.
  "keywords": [ "some", "keyword" ],
  // You should specify a license for your package so that people know how they are permitted to
  // use it, and any restrictions you're placing on it. Use a current SPDX license identifier for
  // the license you're using.
  //
  // If you are using a license that hasn't been assigned an SPDX identifier, or if you are using a
  // custom license, use the 'LicenseRef-' expression.
  // 
  // SPDX License List: https://spdx.org/licenses/
  // SPDX Licsense Expression Syntax 2.0: http://npmjs.com/package/spdx
  //
  //"license" : "(ISC OR GPL-3.0)",
  //"license" : "LicenseRef-LICENSE",
  "license": "Apache-2.0",
  // The main field is a module ID that is the primary entry point to your program.
  // That is, if your package is named foo, and a user installs it, and then does
  // require("foo"), then your main module's exports object will be returned.
  //
  // This should be a module ID relative to the root of your package folder.
  //
  // For most modules, it makes the most sense to have a main script and often not much else.
  "main": "lib/mypackage.js",
  // Specify either a single file or an array of filenames to put in place for the man program to find.
  //
  // If only a single file is provided, then it's installed such that it is the result from man <pkgname>,
  // regardless of its actual filename.
  //
  // Man files must end with a number, and optionally a .gz suffix if they are compressed. The number
  // dictates which man section the file is installed into.
  //
  //"man": "man/mypackage.1",
  "man": [
    "man/one.1",
    "man/two.1"
  ],
  // The name is what your thing is called. [REQUIRED FIELD]
  //
  // Some rules:
  //
  // * The name must be shorter than 214 characters. This includes the scope for scoped
  // packages.
  // * The name can't start with a dot or an underscore.
  // * New packages must not have uppercase letters in the name.
  // * The name ends up being part of a URL, an argument on the command line, and a folder name.
  //   Therefore, the name can't contain any non-URL-safe characters.
  //
  // Some tips:
  //
  // * Don't use the same name as a core Node module.
  // * Don't put "js" or "node" in the name. It's assumed that it's js, since you're writing a package.json
  //   file, and you can specify the engine using the "engines" field. (See below.)
  // * The name will probably be passed as an argument to require(), so it should be something short,
  //   but also reasonably descriptive.
  // * You may want to check the npm registry to see if there's something by that name already, before you get
  //   too attached to it. https://www.npmjs.com/
  //
  // A name can be optionally prefixed by a scope, e.g. @myorg/mypackage. See npm-scope(7) for more detail.
  "name": "my-package-name",
  // If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install,
  // then you may put it in the optionalDependencies object. This is a map of package name to version or url,
  // just like the dependencies object. The difference is that build failures do not cause installation to fail.
  //
  // Entries in optionalDependencies will override entries of the same name in dependencies, so it's usually best
  // to only put in one place.
  "optionalDependencies": {
    "foo": "1.0.0 - 2.9999.9999"
  },
  // Specify which operating systems your module will run on. You can also blacklist instead of whitelist operating
  // systems, just prepend the blacklisted os with a '!'
  // The host operating system is determined by process.platform .
  "os": [
    "aix",
    "freebsd",
    "linux",
    "macos",
    "solaris",
    "vxworks",
    "windows",
    "!windows"
  ],
  // In some cases, you want to express the compatibility of your package with an host tool or library,
  // while not necessarily doing a require of this host. This is usually referred to as a plugin. Notably,
  // your module may be exposing a specific interface, expected and specified by the host documentation.
  "peerDependencies": {
    "package_my_package_is_a_plugin_for": "2.x"
  },
  // If your package is primarily a command-line application that should be installed globally, then set
  // this value to true to provide a warning if it is installed locally.
  //
  // It doesn't actually prevent users from installing it locally, but it does help prevent some confusion if it
  // doesn't work as expected.
  "preferGlobal": false,
  // If you set "private": true in your package.json, then npm will refuse to publish it.
  //
  // This is a way to prevent accidental publication of private repositories. If you would like to ensure that
  // a given package is only ever published to a specific registry (for example, an internal registry), then use
  // the publishConfig dictionary described below to override the registry config param at publish-time.
  "private": false,
  // This is a set of config values that will be used at publish-time. It's especially handy if you want to set
  // the tag or registry, so that you can ensure that a given package is not tagged with "latest" or published
  // to the global public registry by default.
  //
  // Any config values can be overridden, but of course only "tag" and "registry" probably matter for the purposes
  // of publishing.
  //
  // See npm-config(7) to see the list of config options that can be overridden.
  "publishConfig": {
    "registry": "https://registry.npmjs.org/",
    "tag": "latest"
  },
  // Specify the place where your code lives. This is helpful for people who want to contribute. If the git
  // repo is on GitHub, then the npm docs command will be able to find you.
  // The URL should be a publicly available (perhaps read-only) url that can be handed directly to a VCS
  // program without any modification. It should not be a url to an html project page that you put in your
  // browser. It's for computers.
  //
  // For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same shortcut syntax you use
  // for npm install:
  //
  //"repository": "npm/npm"
  //"repository": "gist:11081aaa281"
  //"repository": "bitbucket:example/repo"
  //"repository": "gitlab:another/repo"
  "repository": {
    "type": "git",
    "url": "https://github.com/npm/npm.git"
  },
  // The "scripts" property is a dictionary containing script commands that are run at various times in the
  // lifecycle of your package. The key is the lifecycle event, and the value is the command to run at that point.
  //
  // npm supports the "scripts" property of the package.json script, for the following scripts:
  //
  // * prepublish: Run BEFORE the package is published. (Also run on local npm install without any arguments.)
  // * publish, postpublish: Run AFTER the package is published.
  // * preinstall: Run BEFORE the package is installed
  // * install, postinstall: Run AFTER the package is installed.
  // * preuninstall, uninstall: Run BEFORE the package is uninstalled.
  // * postuninstall: Run AFTER the package is uninstalled.
  // * preversion, version: Run BEFORE bump the package version.
  // * postversion: Run AFTER bump the package version.
  // * pretest, test, posttest: Run by the npm test command.
  // * prestop, stop, poststop: Run by the npm stop command.
  // * prestart, start, poststart: Run by the npm start command.
  // * prerestart, restart, postrestart: Run by the npm restart command. Note: npm restart will run the stop and start
  //   scripts if no restart script is provided.
  //
  // Additionally, arbitrary scripts can be executed by running npm run-script <pkg> <stage>. Pre and post commands
  // with matching names will be run for those as well (e.g. premyscript, myscript, postmyscript).
  //
  // See https://docs.npmjs.com/misc/scripts for more details
  "scripts": {
    "preinstall": "node-waf clean || true; node-waf configure build",
    "start": "node server.js"
  },
  // Version must be parseable by node-semver, which is bundled with npm as a dependency. [REQUIRED FIELD]
  // (npm install semver to use it yourself.)
  //
  // More on version numbers and ranges at semver(7).
  "version": "0.0.0"
}