In this lecture, we're going to review the starter files generated by the angular CLI.
The CLI downloads dozens of files.
It can be overwhelming deciding where to start.
Therefore, I think a tour around the application will give us a good idea of where to start.
This review won't be super comprehensive.
It'll give you a general idea of what each file does.
Let's begin.
We're going to start with the root files.
The editor config file is a configuration file for editors.
That can be surprising.
Why would we need a file for configuring a text editor?
It's for teams.
If you're working on a team, chances are everyone will be using a different editor.
Their editors may be configured differently than yours.
This difference in configuration can lead to formatting issues during commitments.
Most editors can detect the editor config file if present.
The configuration options in this file will override the current settings of the editor, thus saving
us time from manually making the changes ourselves.
In addition, it's a great way to keep formatting consistent across multiple editors.
At the top of the file there's a link to the documentation for various configuration options.
If you're using Visual Studio code, the editor config plugin is not supported.
You need to install a separate extension.
Check out this link to download the extension for this course.
We're not going to be using this tool.
It's okay to ignore it.
The next file is called Git Ignore.
The git ignore file will tell git to ignore a list of files when performing commitments.
Angular has adjusted this file to include files and folders that don't need to be committed.
We won't be modifying this file.
The next file is called Angular.json.
This file.
Configures the workspace of our project.
We can change how Angular builds our project for production and development.
Unlike the other files, I want to dive into the options of this file.
I'm going to fold some of these options for readability.
The first option is called schema.
Angular is capable of generating files for our projects aside from the initial starter files.
It needs instructions for generating those files.
This option is a path to a file to provide instructions on the various files generated with Angular.
This file is also used for updating existing code whenever new changes are introduced.
The next option is called version.
This option will contain the version of the configuration we are currently using.
Version one of the configuration.
If the Angular team decides to change how the configuration file is formatted, this value would be
higher.
Afterward, we have the new project root option.
Believe it or not, we can manage multiple angular applications at once.
You may want to do this if you have a large app that needs to be broken down into several smaller apps.
For example, you may have an application for customers and another for administrators.
Code related to administrative actions shouldn't be loaded with customer actions.
Both apps may feed into the same API, therefore they share a relationship.
We can break this type of app into two apps.
The new project Root option will be the name of the directory for hosting additional apps.
For example, if we create a new project from within this angular project, it will be placed inside
the projects directory.
The next option is called Projects.
It'll contain a list of projects currently registered with Angular.
We've created one app so far, which is the basics app.
Inside this object, we'll have more configuration options for this specific project.
We won't go over every one of them.
It's not necessary.
The most crucial option is called architect.
I'm going to quickly minimize the children's properties.
The architect option contains a list of commands for building the project.
Building is the process of compiling our code.
For example, we need to build our TypeScript code into JavaScript code if we want to run our app in
the browser.
Angular needs to build our project differently based on what we plan on doing with the app.
If we want to develop the application, we will use the serve command.
If we want to ship our app to production, we would use the build command.
As you can probably tell, each of these objects correlate to a command in the CLI.
These commands will build the project differently.
If we want to configure the building process, we can do so through the respective option.
The build command will build the project for production.
The serve command will build the project for development.
The extract i18n command will extract translations from a project.
Lastly, the test command will build the project for testing.
We aren't going to be running through every command provided by Angular.
However, it's always good to know where you can modify the behavior of a command.
There isn't anything else worth mentioning, so let's move on to the next file in our project.
The next file is called Package.json.
You should already be familiar with this file.
It contains a list of dependencies for our project.
If we look inside the scripts object, we'll find some commands for starting and building the project.
As I've mentioned before.
The START command runs the NG serve command behind the scenes.
They both turn on the development server.
The next files are the TypeScript configuration files.
There are three configuration files there.
The TS config dot app.json tsconfig.json and TS config dot spec dot json files.
It feels redundant to have various configuration files for typescript.
However, they do serve a purpose.
The TS config dot app.json file runs when we're compiling our application, whereas the spec file runs
for tests.
Both files extend the tsconfig.json file.
If we look inside either file we'll find a property called extends.
The extends option allows us to import settings from another file.
As you can see, these files import the tsconfig.json file as a base.
If there are conflicting settings, the file importing the configuration file will have priority.
We aren't going to be modifying the TypeScript configuration for this project.
It's been optimized for Angular.
That wraps up the files in the root directory.
You may have noticed one thing about the files in this directory.
They're all configuration files.
Not a single file contains code for the actual application.
It's because the application code can be found inside the source directory.
The CLI will compile the code inside this directory.
We're going to start exploring the code in this directory in the next lecture.
I'll see you there.