Hopefully you're starting to get an idea for what React runs on top of, and after we have that we'll be able to start writing React code, and more importantly, we'll understand how it is functioning because we'll understand the foundation of what it's running on.

So let's move down, we went through our env files. The next one is the license, we don't really have to spend much on that. Whenever you're working with open source projects its common to use a license if you're working on an application that is just built for a company or for yourself, then you do not need to include that. But that's just something because this project, when I built it, it was an open source project and it still is, so it uses the MIT license.

Now, the next two files I'm gonna swap the order. So I'm actually gonna go into the package.json file first, and then we'll look at the package-lock.json file because they're very similar, but it's easier to understand the package-lock file after you've gone through the package.json file.

So starting off at the very top, we have the name, and in this guide we are gonna start switching a few things up. So by default, when I built the template I had it so that it would create a name, but we're going to change that up with the name of our project.

So swap out the values for name here, and we wanna call it whatever the name of the application is, I'm gonna say, jordan-hudgens-react-portfolio, and you can call it whatever your application is named.

Now we have a version here, I'm gonna keep that at version 1.0.0, and then we have a description. We can get rid of this description code here, and we can call it anything we want. So this will be Personal portfolio app built in React.

Now, one key thing to understand here, this is using the json file type. In order to write proper json, there are a few basic rules to follow. There aren't a ton, but the ones that are there are very strict, so make sure that you are writing your json properly.

I'm gonna give myself a few lines up here. I'll get rid of this here in a second, but just so you know the basic syntax. Json stands for JavaScript Object Notation, so this looks a lot like a JavaScript object, and it has key value pairs. You can also have nesting, kinda like how we have our scripts right here.

So it starts with a regular object just like this, and then you set up a key. This could be anything, so "anything" here would be the name of the key. Then use a colon, and then whatever the value is. So then you could say "something else for the value", just like that, and if you wanna add more key value pairs, then you give a comma and then you can just keep going down.

Now, a couple rules that I wanna show you. One is you have to make sure that your keys and your values all have double quotes. Now, in most programming languages, the difference between single or double quotes does not matter that much, in json it does, though. So make sure you're using that.

Then also make sure that if you come to the end of your list of items, just like we have right here, then make sure that you do not have a trailing comma or else you will get an error. So that is pretty much it on the basics of json, so I'm going to come here and delete it because we wanna get back to having a properly formed package json file.

I did wanna give you those rules, because you might start typing and get errors that would break your whole application just off something like, only having single quotes or something like that. So we have our name, our version, and our description.

Now let's look at the scripts. Now, this is pretty cool, this is something that we have available via Node. So what you can do is set up some automated processes. Here, these are ones that I added to the template so that you didn't have to, but they post-install things.

So you can run a command, and this is what I do is I have the cp command, which is a special command that copies, it's short for copy. That's how we got the example js file copied into an env.js file, and that ran right after the install process occurred, so that file was actually created dynamically.

Whenever we run, npm run start, this is actually the command that we are giving. So as you can see, it says, "npm run start" that starts the web server, we have the server set up called Webpack dev server, and then it has a few options.

So we pass in the configuration options of config, webpack/dev, which is in that webpack file that we walked through, then we set up watch. That is how whenever we make a change to one of our application files it auto-refreshes, that is an option for the webpack dev server. So if you wanted to, you could actually create your own custom commands which is pretty neat.

So if I come down to the end to "prod", and don't worry we'll still go through the rest of these, but just so you can see how this works. If I come here and we can just create anything we want, I could create a command that says, "Hey," and then I'm gonna have it echo which is the terminal command for if you want the terminal to simply repeat something back.

The only times you usually do that is if you're building out a library and you wanna ask questions or something like that, just so you can see the way it works. If I type "echo" and then, "Hey there," you can see it returns, "Hey there,".

So I could do something like that here, where I'll say, "Hey," and then, "echo," so I'm typing out the full command just like I would here in the terminal and that's one of the most important things I want you to understand. All of these scripts are scripts that are the same exact scripts that you would type into the terminal. That's what we have the ability to do.

So I'm gonna say, "echo," and then in single quotes here I'm gonna say, 'echo Hi there' and hit save.

Now what I can do is I can say, npm run hey and remember, that is the name of the command that we just gave. If I hit return, you can see that it actually prints out, "Hi there," it shows the command that ran, and then it prints that out.

So that is pretty neat. That gives us the ability to have a lot of control for building automation into our program. So there's not a big need for doing that for this application we're gonna be building, but as you go into more advanced applications there may be processes that you wanna run and you can do them directly in that file.

One of the most common ones that I use and that I see others using is a way of fixing style issues. So say that you are not sure if you used the right indentation or you wanna make sure that you're following certain style rules, you can actually run a command that'll go through all your files and it'll fix any style issues.

Building out those kinds of custom commands are very popular, so it's a common use case. I'm gonna get rid of this line here and let's now look at these other commands. We talked about start, now what build does if I were to type npm run build, this would take our application and it'd build it for production. So what that means is we have our local version of our application and it has certain rules that it follows.

But in production, you want it to follow different rules. So you want to have your production application work as fast as humanly possibly, which means you're gonna implement caching, you're going to have a different set of bug fixes. You're gonna have all kinds of different things that you wanna happen when your application is being used by users compared to if you're just using it on your local machine.

So what build does is it runs a full set of processes. You can see right here, it calls this cross-env which is just saying, "I want you to set the environment to production, then I'm gonna call webpack, and then I'm going to find all of our production configuration items, and then I'm going to build a production level type of application."

So it takes all of the code that you write and then it puts it together and wraps it up in a way the server will actually be able to use it.

Now, this is gonna be something we don't do until a little bit later on in the course. But the deployment process we're gonna use in order to get this application live on the web, it's actually gonna run this command for us. So it needs to be there, but we're not ever gonna have to run this locally on our own machine.

That actually is a perfect lead-in to the next command. Heroku-postbuild, what this does is Heroku is gonna be the app engine that we're going to be using for deploying to the web. So if you were in the browser, if you're interested in what Heroku is, if you went to Heroku.com, mine is gonna go and it's actually gonna show me my own, all of my applications.

But if you personally go to Heroku.com, if you don't have an account, it's gonna show you all of these different ways that you can deploy your applications from your local machine onto the web. They can run React applications, they can run Python, Rails, anything like that.

So that's what we're gonna be using later on in the course. So this is a command that Heroku needs to run so that it knows to go run this npm run build. So it's going to set it for production so that it can work on a live internet kind of environment.

Then we have a few other ones like precommit so you're not gonna have to worry about that, it's just testing it out to make sure that we don't have any crazy bad styles or anything like that. Then we have production, which if you ever want to run the system in production like the way it's gonna be when it's live on a website, then it's going to set the environment to production, then it's gonna run Node, and then it's gonna call the server js file which is one we're gonna look at in a little bit.

So those are all of the scripts. As you can see, they really have to do a lot with showing and allowing you to create some dynamic behavior and interact with the server, and also set it up so that it can work in a production environment. So hit save just so we have all of the things, like the name and the description updated and we'll keep moving down the line.

The repository, this is something we're gonna get into in a couple guides. We are going to use Git and GitHub to store our code base so that we can share it with others and so we can have it connected to Heroku when we wanna deploy. We're going to eventually replace this link, 'cause this is pointing to our js builder template file, and we're gonna replace it with our own unique URL that's gonna have our own spot where we're storing all of the code.

The key words, these are things you don't really have to worry about at all. These are more for just giving an idea for others of what this application is made up of. So es6, es7, those are just versions of JavaScript and Webpack and those kinds of things. I could get rid of all of this right here and it would still work.

I'm gonna keep it there, 'cause it's good for search engine optimization and if you ever wanna search through your own list of projects it's nice to have those keywords there.

Author, let's swap this out with whatever your name is. For license I'm just keeping it MIT and I would recommend you probably do that for this project as well. The bugs list, this is one that you can just get rid of right now or you can keep, we'll most likely replace this link later on with a very similar link on GitHub.

So in an open source project the reason why you'd have a list of bugs here, it's because they're, for open source projects you wanna give other people the ability to report any issues that they may run into when they're using your application. So you could go and point them to a spot where they could go and list those issues out.

Home page, you don't have to worry about this. This is simply something that if you wanna point people to your own personal home page or anything like that then you can. Then next we have our dependencies, which we've already talked about. So this is directly related to when we discussed our node modules.

As you can see, we have our regular dependencies and then our dev dependencies. I believe we brushed up on this a little bit, but we'll just review it. The difference between the two, 'cause this can be a little confusing if you've never seen it before.

Your dependencies are what your application needs to run in any environment. Your dev dependencies are the libraries and code you need for your system to work locally. So as you can see, the majority of our dependencies are located in our regular dependency list.

The only reason why it can be good to separate these out is because if you list all of your dependencies inside of the main list, that means that you're gonna have some code on your production server that is not needed. So it's a best practice to only include the items that the server is going to need, as we go through the course we'll talk about what each one of those are.

So this video took a little while, so let's take a break and in the next one we're gonna walk through the package-lock file.