In this video which is the last one for this section we're going to make our lives a little bit easier
by setting up a second script and package Jason inside of there.
Right now we have a single script these start script we've created this start script because of that
is what Heroku is looking for when it starts up our application and we learned we could always run that
locally using NPM runs start.
Should we want to in this video we're going to create a second script a development script which is
going to run that node man command.
So currently when we want to start up our server using Node man we have to type out the command from
the terminal every single time that is node man followed by the path to the file source forward slash
app dot J.
S followed by our list of extensions.
J.S. comma HB S..
We have to type that out every single time we want to start up the application.
It would be much nicer to break that out into a package.
Jason script which we can use and reuse the first step to get this done is to simply define that new
script.
So just after start or before the order does not matter we're gonna set up a second property on these
scripts object.
We can pick a name for the script.
I'm gonna call this Dev which is short for development and we can also pick the actual command to run
here.
We're gonna type out exactly what we just typed out in the terminal.
That is node man.
Source forward slash app dot J.
S with our list of extensions J.S. and h b s.
So with this script in place it's gonna be a lot easier for folks to start up the dev server.
It's gonna be easier for us to rerun the command something we've had to type out so far and as we collaborate
with others they'll be able to use the dev script as well to start up that local development server
easily otherwise they'd have to figure out exactly what's needed and then have to go through that whole
problem of figuring out they need to add the HP s extension as well if there's a command we're using
often in a project it's best to create a script that runs it.
So it's reusable and accessible to everyone even if it's just you.
It's nice to be able to reuse that script without typing things out again from the terminal we can now
go ahead and run that Dev script and see what happens down below.
I'll use control C to shut down the old process where we manually type things out and they'll start
up that Dev script NPM run Dev.
When I started up what's going to happen it's going to print the exact same thing it was just printing
before here.
Node man is starting and it is starting watching for the extensions that we listed out up above and
we can see that by refreshing local host three thousand.
Right here we are still getting the application.
Now if I was to go into one of the j s files like forecast J S and I was to save the file even if I
don't make any changes.
We can see that down below the server did indeed Restart which is fantastic.
Now that we have this in place it's time to talk about the one catch to this solution.
The only reason the devs script works is because we have node man installed as a global module when
we have global modules installed.
It's difficult for other people to know they need to install them.
The problem with global modules is that they're not local dependencies.
So if we're using them in a specific project it's best to try to install everything locally.
So imagine if I gave this project to someone else.
Let's say I push this up to a public get Hub Repository.
Someone decides they want to add a new feature.
I say Yeah go for it and I will integrate that into my project.
So they download the code and they don't get node modules because that's ignored with get ignore.
And that's fine.
They'll be able to run npm install it will dig through the Jason files and it'll get all the modules
installed node modules will get generated for them on their machine and will have express.
It'll have HB Yes and it'll have request.
The problem is that when they go to use that Dev script it's gonna fail because well our project technically
depends on Node Mohn.
It does not have it as a dependency and that is a problem.
Now it might not take too much effort for someone to realize they have to install a node mod but it
would be nice if our app just worked right out of the box.
It's also trickier when different versions expect to be used in different ways.
This might not work with the version they have installed.
And if we don't tell them what version we have installed they really are helpless to solve the issue.
They're running against.
So the solution is to uninstall node Mohn globally and to install it as a local dependency so down below
from the terminal we can use control C to shut down the node demand process and we're gonna go ahead
and run NPM uninstall to uninstall something we're on installing a global module.
So we use that G flag and the name is node my now when we run this it's going to remove node mod which
means we can no longer run it from the terminal and our script is no longer going to work.
Both of them are expecting that command to be available.
We can address this now by installing it as a local dependency something that's actually listed in package
dot Jason right here npm install we are going to install no demand at the version we had before.
One point to point zero and from here we're going to provide a new flag.
Something we haven't used before that is hyphen hyphen save hyphen.
Def when we install something and we use save Dev it lists it as a dev dependency in our project.
So here under package dot Jason we have dependencies.
We have expressed HB s and request and we have Dev dependencies and for this we just have no demand
Dev dependencies our dependencies you only need on your local machine.
Well you're developing these dependencies aren't installed in your production environment which means
that node mine is not installed on Heroku and that's OK Heroku never uses the dev script Heroku just
uses that start script by adding node man as a dev dependency.
We're saving time preventing Heroku from having to install things it's not going to use.
You could easily install this as a regular dependency and the application would still work like it's
working now.
The only difference by breaking it out into a dev dependency is that it's not installed on the production
environment which once again just saves us a little bit of time.
Now the module is installed locally which means that we actually don't have access to it as a straight
up command from the terminal.
So if we were to cycle through our previous commands and get to that node mod command we've run maybe
30 times in the class and actually execute it.
It's going to fail.
It's looking for node man and Node man is not globally installed.
Now our script is still going to work.
Scripts they can use commands from a locally installed modules.
So here it is perfectly valid to use node man because node man is installed as a dependency.
It's OK to use it even though it would fail if we just straight up ran this command from the terminal.
So this is the difference between globally installed and locally installed modules.
Once again the main problem with those globally installed modules is that other people aren't going
to know what modules and what module versions you're using.
By bringing things in as local dependencies anyone can run npm install.
They can have everything installed then they can start working on the project now from the terminal
just to make sure things are working for the final time.
We're going to run NPM run Dev when we do this.
Things are going to work as expected it's able to start up node man.
And if I refresh local host three thousand we can see that our server is indeed up and running.
So that's where we're going to stop before this video.
And that's where we're gonna stop.
For this section in this section you learned about get for version control.
You learned about github for managing your software development projects and you learned how to use
Heroku to deploy your applications to production.
That's where we're going to stop for the section and it's also where we're going to stop for the weather
application in the next section we'll move on to our next application and we're going to kick things
off by talking about how we can connect to real databases from node j.
S I'm very excited to get to that.
So let's go ahead and jump right in to the next one.