The Power of Package.json

1. script field:
   There is script field inside the package.json through which we can hook to the npm life cycle events.

NPM life cycle events:

• prepublish: Run BEFORE the package is packed and published, as well as on local npm install without any arguments. (See below)
• prepare: Run both BEFORE the package is packed and published, and on local npm install without any arguments (See below). This is run AFTER prepublish, but BEFORE prepublishOnly.
• prepublishOnly: Run BEFORE the package is prepared and packed, ONLY on npm publish. (See below.)
• prepack: run BEFORE a tarball is packed (on npm pack, npm publish, and when installing git dependencies)
• postpack: Run AFTER the tarball has been generated and moved to its final destination.
• 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: Run BEFORE bumping the package version.
• version: Run AFTER bumping the package version, but BEFORE commit.
• postversion: Run AFTER bumping the package version, and AFTER commit.
• 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.
• preshrinkwrap, shrinkwrap, postshrinkwrap: Run by the npm shrinkwrapcommand.

2. config

A “config” object can be used to set configuration parameters used in package scripts that persist across upgrades. For instance, if a package had the following:
{ "name" : "foo"
, "config" : { "port" : "8080" } }

and then had a “start” command that then referenced thenpm_package_config_port environment variable, then the user could override that by doing npm config set foo:port 8001.

3. dependencies and devDependencies
The difference between these two, is that devDependencies are modules which are only required during development, while dependencies are modules which are also required at runtime.

Some good examples of when to install devDependencies would be Nodemon, Babel, ESLint, and testing frameworks like Chai, Mocha, Enzyme, etc…

Some good examples of dependencies which would be required at runtime include React, Redux, Express, and Axios.

4. engines
You can specify the version of node that your stuff works on:
{ "engines" : { "node" : ">=0.10.3 <0.12" } }

Note: 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. For example:
{ "engines" : { "npm" : "~1.0.20" } }

4. os(operating system)
You can specify which operating systems your module will run on:
"os" : [ "darwin", "linux" ]

5.cpu
If your code only runs on certain cpu architectures, you can specify which ones.
"cpu" : [ "x64", "ia32" ]

6.DEFAULT VALUES

npm will default some values based on package contents.

• "scripts": {"start": "node server.js"}
• If there is a server.js file in the root of your package, then npm will default the start command to node server.js.
• "scripts":{"install": "node-gyp rebuild"}
• If there is a binding.gyp file in the root of your package and you have not defined an install or preinstall script, npm will default the install command to compile using node-gyp.
• "contributors": [...]
• If there is an AUTHORS file in the root of your package, npm will treat each line as a Name <email> (url) format, where email and url are optional. Lines which start with a # or are blank, will be ignored.