Introduction
This guide covers a range of style conventions for Angular application code. These recommendations are not required for Angular to work, but instead establish a set of coding practices that promote consistency across the Angular ecosystem. A consistent set of practices makes it easier to share code and move between projects.
This guide does not cover TypeScript or general coding practices unrelated to Angular. For TypeScript, check out Google's TypeScript style guide.
When in doubt, prefer consistency
Whenever you encounter a situation in which these rules contradict the style of a particular file, prioritize maintaining consistency within a file. Mixing different style conventions in a single file creates more confusion than diverging from the recommendations in this guide.
Naming
Separate words in file names with hyphens
Separate words within a file name with hyphens (-). For example, a component named UserProfile
has a file name user-profile.ts.
Use the same name for a file's tests with .spec at the end
For unit tests, end file names with .spec.ts. For example, the unit test file for
the UserProfile component has the file name user-profile.spec.ts.
Match file names to the TypeScript identifier within
File names should generally describe the contents of the code in the file. When the file contains a
TypeScript class, the file name should reflect that class name. For example, a file containing a
component named UserProfile has the name user-profile.ts.
If the file contains more than one primary namable identifier, choose a name that describes the
common theme to the code within. If the code in a file does not fit within a common theme or feature
area, consider breaking the code up into different files. Avoid overly generic file names
like helpers.ts, utils.ts, or common.ts.
Use the same file name for a component's TypeScript, template, and styles
Components typically consist of one TypeScript file, one template file, and one style file. These
files should share the same name with different file extensions. For example, a UserProfile
component can have the files user-profile.ts, user-profile.html, and user-profile.css.
If a component has more than one style file, append the name with additional words that describe the
styles specific to that file. For example, UserProfile might have style
files user-profile-settings.css and user-profile-subscription.css.
Project structure
All the application's code goes in a directory named src
All of your Angular UI code (TypeScript, HTML, and styles) should live inside a directory
named src. Code that's not related to UI, such as configuration files or scripts, should live
outside the src directory.
This keeps the root application directory consistent between different Angular projects and creates a clear separation between UI code and other code in your project.
Bootstrap your application in a file named main.ts directly inside src
The code to start up, or bootstrap, an Angular application should always live in a file
named main.ts. This represents the primary entry point to the application.
Group closely related files together in the same directory
Angular components consist of a TypeScript file and, optionally, a template and one or more style files. You should group these together in the same directory.
Unit tests should live in the same directory as the code-under-test. Avoid collecting unrelated
tests into a single tests directory.
Organize your project by feature areas
Organize your project into subdirectories based on the features of your application or common themes to the code in those directories. For example, the project structure for a movie theater site, MovieReel, might look like this:
src/├─ movie-reel/│ ├─ show-times/│ │ ├─ film-calendar/│ │ ├─ film-details/│ ├─ reserve-tickets/│ │ ├─ payment-info/│ │ ├─ purchase-confirmation/Avoid creating subdirectories based on the type of code that lives in those directories. For
example, avoid creating directories like components, directives, and services.
Avoid putting so many files into one directory that it becomes hard to read or navigate. As the number of files in a directory grows, consider splitting further into additional sub-directories.
One concept per file
Prefer focusing source files on a single concept. For Angular classes specifically, this usually means one component, directive, or service per file. However, it's okay if a file contains more than one component or directive if your classes are relatively small and they tie together as part of a single concept.
When in doubt, go with the approach that leads to smaller files.