The very first one is .browserslistrc file. What this does is it tells the application essentially which browsers it will support. This used to be a much bigger issue than it is now but years ago you'd have to create almost completely separate applications based on certain browsers, I'm looking at a few old versions of Internet Explorer.

That was not a fun way to live but that's changed quite a bit through the years and a number of the tools such as Babel help to kind of unify your entire project so that it can be used across any kind of modern browser. But that is what this browserslistrc file does is it says, we're not going to support anything less than or equal to IE8 essentially. But all the versions of Chrome, Firefox and Edge and those type of browsers will be supported but this file just lists that out.

Now moving on, the .gitignore file. What git does is it allows you to have versions for your application and as I'm going through the entire course, I will be saving each episode as its own version so that you can have access to the code at the exact point of in time where I have finished the video.

It's a really nice way of doing it for that reason, just for my own videoing reasons but as you're building out your application, I can tell you from experience that using a tool like git is a very helpful process and I've an entire course that walks through how to use it.

What the .gitignore file does is it tells the application and the git repository if you're using one, it tells it exactly what to not include. By default git is going to include pretty much all the files in your application. You have to explicitly tell it when you do not want it to include a file.

Let's walk through what a few of these mean because it helps to understand exactly the way the system is structured but also which files are important to keep and which ones can be seen as temporary.

The DS_Store one you don't even have to worry about that one, that's just going to be on your local system, you definitely don't need to check that into version control. Now, we've spoken about node_modules, this is just another reason on why your node modules should be seen as temporary in nature and should never be checked into version control and you should never change them.

If you're following best practices, you shouldn't even push up your node modules directory so that means that if you ever made a change to one of those files, anytime that someone else is pulling your application down, they're not going to get those changes because it's not even included in what you're saving.

You can think of git as being the master repository for your source code and for the application, node modules are simply temporary in nature, they can be deleted and reinstalled any time.

Your dist directory, as you may have noticed, you don't have a dist directory and that's because the dist directory is only used for production. Dist is short for distribution and so what we're doing here is if just in case if you're not aware, a vue file cannot be processed directly in the browser.

It first needs to be compiled down to pure JavaScript and then it can be utilized. Browsers can't process vue directly so we need an interpreter. What happens in production is all of our code gets compiled down and it get minified which means it gets made more efficient, it has all of the spaces taken out, and all the files are shrunk down and compressed so that the file will load as fast as possible when it's on a live server, that's your dist directory.

You don't ever want to check that directly into version control because that is also kind of like your node modules. That's going to change, every time that you push up a new change to the server, you're going to get rid of the dist directory automatically and it's going to generate a new one for you. You don't want to include that in source control.

The env which is short for your environment variables. What these represent is they represent your secret passwords that you might need. Imagine that you're building an application that connects to an API like the Google Maps API or the Yelp API. You need to pass in your own user name and password that they provide in order to get access to the data.

Well, you would not to push that up to a public repository because then someone else could take all of your code or all of your username, password and they could use the API just like they were you, that obviously wouldn't be a good idea.

I have told a story before, so I apologize if you're hearing it for a second time from a different course, but I once had developer that was working for me that accidentally published my private AWS key. My AWS has all of these private API keys and they published them. They did not put them and hide them the way that they should have and they got published on GitHub.

Within two hours, a hacker had already stolen them and had racked up over $16,000 in charges in just a couple hours by spinning up hundreds and hundreds of servers and so that is something you definitely do not want to do. We'll talk later how we can create and protect our environment variables and you want to make sure that when you save them on your system, you're not also publishing those onto GitHub or wherever you're pushing your code to.

Now you also don't want to publish your log files for a few reasons. One, log files can get very large and if you push those up to GitHub, then what would happen is you would end up growing your repository all for things that are not necessary.

But the other reason why you never want to publish log files is because your development log files might have some secure items. Your log files could also have some of your environment variables or some data that you're passing or trying to communicate with a server with and so you want to make sure that you do not ever publish your log file.

And then lastly, what this does is it, these editor directories and files, tools like vs code and some of these text editors, they have all kinds of their own setting files that you wouldn't want pushed up to some outside service and everyone have access to it mainly because it's just a waste of time.

It doesn't actually have anything to do with security usually, it has more to do with just not cluttering up an outside code repository. You can even see right here, this vs code directory is mapped directly to this vs code settings directory that we have right here, so that is all that that's doing.

Now moving down, a few of these files are very short so we'll go through them quickly. The babel.config, if you remember back to when we generated the application and it asked us if we wanted our configuration files separate or in the package json file and I said I wanted them separate, that is what is happening here. It took the configuration files and it placed them in their own isolated environment which is the way that I personally like to do it.

Here you can see that Babel is providing a set of presets that is specific to vue. We haven't talked a lot about what Babel is but we will as we go through the course. For right now, just know that what Babel does is it allows us to write in all kinds of different versions of JavaScript and then it converts that JavaScript that we wrote into something that the browser is able to understand.

So this was much more important years ago and it still is important for certain browsers and you want to make sure that the version of JavaScript that your system is outputting is something that pretty much every user who accesses your application, it's going to be something that they are able to utilize.

Right here, what we're doing is we're saying, we want the Babel config to use the vue app. We're not going to change this at all, this is just simply a preset that Babel gives us when we generate the application.

These next two files are absolutely critical and they also will help you understand not just vue but JavaScript applications in general. When we run any of our NPM commands, these two files, package.json and package-lock.json, are going to be invoked. Let's walk through what they are and I'm going to go in reverse order because the package-lock file is connected, it's tied directly into this package.json file.

Let's start with this one and you can see it starts off pretty small. As we build out the application, we are going to start adding to it but let's see what exactly is inside of it right now. We have things like the name, this is just pretty basic, it's just the name of the application, we have the version and then lists if it's private or not. Those things are all just pretty standard, you do not ever have to change those typically.

Now, moving down into the scripts object. As you can see, this is a just regular json file and what scripts does is it gives us the ability to run any kinds of scripts, either when we run them ourselves or also when we want a system to run it.

Great example, whenever we get ready to deploy our application to the web, we're going to add some custom scripts so that the server actually knows how to run and build our application. When we run NPM run serve, what we're doing is all we're doing is we're calling this exact command right here. This gives a really nice direct interface for communicating and running scripts with our application.

The way that the scripts work is if I open up the console here and we can see, let me clear it out. Whenever you run something like the one we've been running has been NPM run serve, what we're doing when you say NPM run, the very next thing that you're going to pass in is going to be the name of the script.

Right here we have serve, if we wanted to build this for production then we'd say, NPM run build and then it would run this entire process. So we'll be adding a few more scripts to this as we go through the course but for right now I just want you to know when we run NPM run and then serve, all we're doing is we're running this command right here which starts the server.

"serve": "vue-cli-service serve",

Now moving down, these next two sections are pretty closely related. We have our list of dependencies that we're starting the application with and then we have our dev dependencies. One of the very first questions that you probably have is, the difference between the two. I'll say that mainly the difference is your dependencies are code libraries that you are going to need whether you're on local hosts like we are right now or you're on production whereas your dev dependencies are what are needed in order for you to properly build out the application.

Typically when we're going to be adding dependencies for the most part, we're usually going to be placing them inside of the dependencies list but we're going to be adding them directly from the terminal and then it is going to update this file.

You can update this file if you want, it's perfectly fine to, but my process is usually to run commands at the terminal, we'll walk through how we can do that. That is how you can add the list of dependencies that create your node modules directory.

Now, that is your package.json library, it's perfectly fine to make changes to this file, update it and you will be doing that as you build out your app.

Now, this package-lock.json file, this is a very different kind of file and let's see if I can come all the way down to the bottom whereas we had a few dozen lines of code in the package.json file, we have 12,540 lines of code inside of the package-lock file.

What is the difference? Well, package-lock represents all of the dependencies in your application and that includes all of the nested dependencies. Let's take a look for example, if I were to find and I'll just search for it. The vue library right here, you can see we're pulling in vue version 2.5 and it has some metadata associated with it and then it has underneath it, all other kinds of these vue files.

We have vue-loader, we have hot-reload API, we have vue-router, style-loader, all of these kinds of files. What we're doing with package-lock is this is the exhaustive list of all of the dependencies. There's a direct mapping between the package-lock file and the node modules directory.

This is the way that NPM, when we run NPM install, what we're doing is we are taking, or what the system's doing is it's looking at this package-lock file. It's finding all these dependencies, it's finding the version, it's finding the URL to go get them from. Everything like that and then it's going and it's installing those directly in the application so that the code is accessible by the source directory and every spot that it is called. That is what the package-lock does.

Now, you do not usually want to ever change the package-lock file. It's pretty rare, usually the only time you'd ever need to do that is if you run into some weird dependency bug. It's not something that you should have to do very often at all.

Usually what you're going to be doing is you're going to be adding your dependencies, anything custom and new directly into your package.json file and then that will automatically update your package-lock file. That is kind of the common process there. That is a overview of how package.json and package-lock work.

Now we just have two more files then we're going to be done with this section. The first one is this postcss.config, what this does is it allows us to have a auto prefixer. We don't have to make any changes to this code. It is going to work perfectly and it's just another plugin and it's something that if you ever did have to do any kind of custom plugin work with CSS then you'd need to do it here. But we will not have to do that in this application and I've not even had to do that in any vue application I've ever built out including some pretty large ones.

Moving down to the very last file, we have a pretty basic one here, this is the README. This is the essentially it's the instructions and it's auto generated for the application. Say you were to push this up to GitHub, you need to provide a set of instructions to anyone else who's going to work on this. Let's take a quick look at GitHub, I'm going to go to my repository here or my set of repositories and let me go to a vue application. Here I have, let me see one that actually has a README.

If I come here you can see that this is the README, it's a pretty short one. It's for a private application but you can see it has some formatting here.

It has this title, it has this little quote and then it even has some just kind of paragraph tag text there. This is in a format called markdown and you know that it's markdown when you see .md as the extension and if you click edit here, and this is on GitHub you can even see this format that's here.

It has this little hash symbol which represents a heading, and then this > represents a block quote, and then everything else is just paragraph content. That is the same format that the README is right here, it lists all of the commands and I'm not going to make this a tutorial on the markdown language. If you want that, there's some great resources, you can just go to the markdown tutorial, and it has a step by step set of instructions for how you can write markdown.

For right here, just know that this was auto generated by vue.

When you see these back ticks, that represents code and so it'll get rendered out as code. You have a set of instructions such as running NPM install to install the dependencies, then from there you can do NPM run serve. We've already run these two commands and then you can see the other script that we went through, the NPM run build.

If you have tests, you can run tests and if you have a linter you can run it there. This is just a set of instructions so that when you push this up, some other developer is going to know exactly what commands to run in order to start working on the application.

Great job if you went through that, I know that was very exhaustive but this course is supposed to be exhaustive. It's supposed to be very comprehensive and so I didn't want to leave any piece of code unturned. Hopefully you now have a good high level understanding for what the basic structure is for a vue application. Now that you have that, we can go out and we can start building features and start building our app.