The package.json file holds all of the information about the package we are trying to build. It even gives us the ability to tie it into our version control system, and we can even tie it into our build system. Let's go over this now.

First, a package.json file should have the following fields filled out:

• name: This is the name of the package.
• version: This is the current version of our software package.
• type: This should either be module or commonjs. This will allow us to distinguish between legacy systems and the new ECMAScript module system.
• license: This is how we want to license our module. Most of the time, just go ahead and put the MIT license. However, if we do want to lock it down more, we could always use the GPL or LGPL license.
• author: This is an object with the name, email, and url fields. This gives attribution to the software and helps people to know who built it.
• main: This is the main entry point of the module. This will allow others to use our module and require/import it. It will also let the system know where to look for our starting point of the module.

There are many additional fields that can be used, as follows:

• man: This allows the man command to find the file that we wish to serve for our documentation.
• description: This allows us to provide more information about our module and what it does. If the description is longer than two to three sentences, it is recommended to have an accompanying README file.
• repository: This allows others to find the repository and contribute to it or submit bug reports/feature requests.

• config: This is an object that can be used by the scripts that we define in the scripts section of our package.json file. Scripts will be discussed in more detail soon.
• dependencies: This is a list of modules that our module depends on. This can range from modules that live in the public npm registry, private repositories, Git repositories, tarballs, and even local file paths for local development.
• devDependencies: This is a list of dependencies that are needed for the development of this package.
• peerDependencies: This is a list of dependencies that our package may need if someone utilizes a piece of the system. This allows our users to download the core system, and if they want to utilize other pieces, they can download the peer dependencies that these other subsystems need.
• OS: This is a list of OSes that we run on. This can also be the negative version of this, such as !darwin, meaning that this system will run on all OSes other than OS X.
• engines: The versions of Node.js that we run on. We will want to use this when we utilize a feature (such as ECMAScript modules) that has been introduced in a recent version. We may also want to utilize this feature if we're using modules that have been deprecated and want to lock the Node.js version to an older one.

There are a few more fields that are located in the package.json file, but these are the most common ones.

One specific section of the package.json file that we want to look at is the scripts section. If we go to the website of npm, about the scripts section, it states the following:

If we go to the more details section, we will see that there are life cycle hooks that we can use so that we have various scripts running through the bundling and distribution process.

Some of the specific points that we are interested in are the prepare and install sections of the packaging life cycle. Let's see what these sections cover:

• Prepare will run the script before the package is packed into a tarball and published to the remote repository. It's a great way to run compilers and bundlers to get our package ready for deployment.
• Install will run the script after the package has been installed. This is great when we pull a package and want to run something such as node-gyp or something that our package may need that's specific to the OS.

Another great thing about the scripts section is that we can put any arbitrary strings here and run npm run <script>. Whatever we decide to use as the value will be evaluated when we run the command. Let's add the following to our package.json file:

"config" : {
    "port" : 8080,
    "name" : "example",
    "testdata" : {
        "thing" : 5,
        "other" : 10
    }
},
"scripts" : {
    "example-script" : "node main.js"
}

This will give us the ability to grab configuration data. On top of this, we have added a script that can be run with the npm run example-script command. If we create a main.js file and add the following fields to it, we should get the following output:

console.log(process.env.npm_package_config_port); //8080
console.log(process.env.npm_package_config_name); //'example'
console.log(process.env.npm_package_config_testdata); //undefined

This shows that we can put primitive values inside the configuration, but we can't try to access something that is a complex object. We can do the following to get to the properties of the testdata object:

console.log(process.env.npm_package_config_testdata_thing) //5
console.log(process.env.npm_package_config_testdata_other) //10

Now that we've gained some insight into the Node.js and npm ecosystems, let's take a look at how Node.js is put together and some of the key modules that we will be utilizing in the following chapters.