As you create a project that uses MPM modules, you'll find that your

node_modules folder is filling up with megabytes of package files.

That's fine, you're using those files in your project.

However, what if you want to share your projects on GitHub or

simply use Git to manage your project?

You certainly don't want to upload all of those packages to your GitHub account.

You also don't need Git to keep track of those files.

After all, you will be editing those package files yourself.

In addition, you'll also want to wait to make sure your packages stay up to date.

Sure, you could update each package by hand by using npm.

But there's a simpler way to keep track of your packages and their versions.

We often refer to this as Managing Package Dependency.

With JavaScript projects,

we use a file in the root of the project called package.json.

This is what npm uses to manage all the dependencies for the project.

Let me show you how to create that file.

We're back in our password project, and I'm happy with bcrypt.

I want to make sure that my other colleagues and

I use the same version when we're working on the project.

Instead of manually creating the package.json file,

we can use npm's init command.

Hit Enter, and it says this.

This utility will walk you through creating a package.json file.

It covers the most common items and tries to guest sensible defaults.

See npm help json for definitive documentation on these fields and

exactly what they do.

Use npm install package name --save afterwards to

install a package and save it as a dependency to the package.json file.

Okay, let's remember that --save flag for later.

That'll come in useful when we're adding additional modules to the project.

Now the first question is the name of the project.

By default is suggested the folder we're currently in.

That's what in these brackets, the default value.

And if you don't put anything in, npm will use that.

Let's call this something more descriptive, like hash_generator.

Hit Enter and we'll do 0.0.1 as our version number.

The description,

A password hash generator.

And the entry point, app.js is fine, so I'm just going to hit Enter.

The test command whether we have any tests for our project.

If you're going to create a project professionally you should really have

tests.

Tests are a way to ensure your code works and can handle each case scenarios.

We don't have a git repository at the moment,

we'll have to manually add that to our package.json file later on.

Keywords are used to aid people to find your project when searching on npm.

But this is a private project, so we don't need it.

And for author you can put in your name there.

So I'm just gonna put Andrew Chalkley, and

now any appropriate open source license here.

I'm going to use MIT.

Including a license in your project helps other people understand how they can use

your code in their project.

MIT is a common license used for open source projects.

Some examples of projects that are under the MIT license are jQuery and

Ruby on Rails.

And if everything looks okay, press Enter.

Now this has created a package.json file.

Let's take a look inside.

It's included all of the information we inputted, and

it's looked in the node modules folder and has found that there's the bcrypt module.

And it's included that as a dependency for our project.

How about another dependency?

How do we add that to the package.json file?

Instead of adding it manually, let's let npm do that for us.

I want to add some color to my program.

I want the generated hash to show up in green in the console.

I know that there's an npm module called Colors,

that lets you add colors to your command line applications.

To install it, we type,

npm install colors --save.

Remember when we did the npm init command?

It said that we could use the save flag for it to get saved as the dependency and

update the package.json file.

Hit Enter and we see that colors is being added to our package.json file.

You may see warning messages like this when you install packages.

Warnings are not errors.

Errors are things that would prevent your code from working.

Because we didn't include a Git-repo or

a README file, it's bugging us to create one.

For now we can ignore it.

Let's include colors in our project.

Open up our app.js file.

We need to require the colors module.

Inside the console.log method, we can add the .green

property at the end of the hash stream to make the color of the output,

when we call the console.log method, green.

Let's run node app.js.

Awesome.

Our hash is green.

The package.json file makes it easy to install node modules used by our project,

even if you haven't already installed those modules.

This is useful when sharing your project.

For example, you don't want to put all

of the many modules used by your projects up on GitHub.

Because that wastes just space and updated versions of the module maybe available.

In other words, if we put this project on GitHub we should include the package.json

file but not the node_modules folder.

There's a file that you can create that will instruct Git

to ignore files and folders and that's a .gitignore file.

In there you would just add the path to the file or folder you want to ignore.

In this case it's node modules.

Since I can't edit it in workspaces, I can just rename this to .txt.

And type what I want in it.

And then rename it back

Imagine we've cloned the project from a GitHub Repo, and

we don't have the node_modules folder.

Let's delete the node_modules folder to replicate that scenario.

When we run our app now, it says it can't find the module colors.

That's because it's no longer in the project folder.

Let's install the packages.

You could do this by manually adding each module

using the npm install followed by the module name.

However, if you have a lot of modules in a project that would be a lot of work.

There's a much easier way, remember the first usage of the npm install

command was just npm install, where you don't specify a package.

Well, npm will look for the package.json file and

install all the dependencies it specifies.

Remember we had to include a build flag for our bcrypt module.

So in this case we just need to include

--python=python2 on any of the device that has Python 2 installed.

Or if your packages don't require it, you don't need to include a flag, or

you can just do npm install.

And let's see if our project now works.

Yes, it does.

And there's our generated password.

Finally, there's another type of dependency, a development or

dev dependency.

There dependencies aren't needed for the application to run, but

are used as you work on your project.

A good example of a development dependency is a test framework.

The reason why you'd want to list this module as a development dependency is to

reduce the amount of unneeded files in production.

For example, if you have a website,

you may have testing in your development environment.

But you don't need that test for a MAC once it's deployed.

When you deploy your code, you can just use npm install.

And it will install the dependencies it needs for your project to run.

A popular test framework in JavaScript is Mocha.

To add this as a DEV dependency,

we'll type npm install mocha --save-dev.

Take a look at the package.json file now, And

you'll see there's a devDependencies key, and there's mocha there now.

Sweet.

Without going in depth on what's involved with testing,

let's see how we can use mocha in our development environment.

Remember, mocha is now installed in this environment.

So we can now use it.

When we first created our package.json file we were asked about our tests.

We can now fill that in.

The mocha package installs a mocha command that can be utilized by npm.

We can replace this with just mocha.

We can get npm to run our mocha command by using npm test.

But before we do, mocha requires a test folder.

So let's create that.

Let's use the npm test command and hit Enter.

And it says no tests are passing.

Because we have no tests.

Once again, this course is about npm and not testing.

However, if you're interested you can check out the mocha website.

Let's delete the node modules folder again, And

play out the two scenarios of installing your dev environment or your production.

Let's try npm.install and see what it does by default.

Notice how mocha is in the node_modules folder.

That's because by default npm believes that an environment is a development

environment and not a production one which is sensible when you think about it.

There's probably more developers working on a project in development

than there are projects running in production in the wild.

Let's delete the node_modules folder again.

Now, how do we set the environment?

With command line applications you can include

environment variables before the command you're executing.

We can set NODE_ENV,

Which means the node environment, to =production, followed by npm install.

And this will only install the dependencies it needs to run,

not the dev dependencies.

Notice now mocha isn't installed, just bcrypt and colors.

There are more ways to set environment variables, but

this is one of the easiest to do to test it on your local machine.

In a company, there are system administrators who

deal with this end of things when deploying applications.

As a developer, it's just important to know that there are these variables set on

a machine which can influence how an application is run.

In this case, npm will install the required dependencies and

not dev dependencies.

There you have it.

You've installed packages both globally, for modules that you want to use anywhere

on your system, and locally, for modules that you want to use in a single project.

You've also used a package.json file to manage dependencies for

your application to run and to help in development.

Well done.