Generate Components in a Specific Folder with Angular CLI

By the end of this page, you will understand how Angular CLI generates components inside specific folders, how nested component paths work, and how to create child components cleanly within an Angular project structure.

Angular CLI can generate files not only by component name, but also by path. When you pass a nested path to ng generate component, the CLI creates the component inside that folder and updates your Angular module if needed.

This matters because Angular applications usually grow into many features and sub-features. If every component is created in one flat folder, the project quickly becomes hard to navigate. Organizing components into feature folders makes the codebase easier to maintain.

For example, instead of generating:

ng generate component plainsight

You can generate a child component inside that folder with a nested path such as:

ng generate component plainsight/child

This tells Angular CLI:

• create a folder named child inside plainsight
• generate the component files there
• declare the component in the appropriate module

In Angular projects, the generated structure often follows the path you provide. So the CLI is not limited to top-level components; it can generate nested components as part of a feature structure.

Think of Angular CLI like a file assistant that builds folders and files based on the address you give it.

• plainsight means: create one room called plainsight
• plainsight/child means: go into the plainsight room and create another room called child

The command is not just naming the component. It is also describing where it should live in your project.

So if you want a child component, you give the CLI a deeper path, just like saving a file into a subfolder on your computer.

The basic syntax is:

ng generate component path/to/component-name

You can also use the shorter alias:

ng g c path/to/component-name

Example 1: Generate a top-level component

ng g c plainsight

This usually creates:

plainsight/
  plainsight.component.ts
  plainsight.component.html
  plainsight.component.css
  plainsight.component.spec.ts

Example 2: Generate a child component inside plainsight

ng g c plainsight/child

This usually creates:

plainsight/
  child/
    child.component.ts
    child.component.html
    child.component.css
    child.component.spec.ts

Example 3: Generate a more descriptive nested component

ng g c plainsight/plainsight-detail

This creates a child component named PlainsightDetailComponent inside the plainsight folder.

What Angular CLI does for you

Consider this command:

ng g c plainsight/child

Here is what happens step by step:

1. Angular CLI reads plainsight/child as a path.
2. It looks for the plainsight folder inside your app structure.
3. Inside that folder, it creates a new folder named child if it does not already exist.
4. It generates files such as:

child.component.ts
child.component.html
child.component.css
child.component.spec.ts

1. It creates a component class similar to:

import { Component } from '@angular/core';

@Component({
  selector: 'app-child',
  templateUrl: './child.component.html',
  styleUrls: ['./child.component.css']
})
export class ChildComponent {}

1. It adds ChildComponent to the declarations array of the relevant Angular module.

Nested component generation is useful in many common Angular scenarios:

• Feature folders: Keep all components related to a feature together, such as users/user-list and users/user-detail
• Dashboard widgets: Generate dashboard/chart-card or dashboard/activity-feed
• Admin pages: Create admin/user-table or admin/role-editor
• E-commerce UI: Use folders like product/product-card and product/product-review
• Form sections: Organize large forms with components like checkout/address-form and checkout/payment-form

This kind of structure helps teams work faster because developers can quickly find related files.

In real Angular codebases, developers often organize components by feature, not by type.

For example:

app/
  plainsight/
    plainsight.component.ts
    child/
      child.component.ts
    settings/
      settings.component.ts

Common patterns include:

• Feature-based folders: everything for one feature lives together
• Container and presentational components: a parent component contains smaller child components
• Guarded generation: developers generate components directly into the intended folder to avoid later moving files by hand
• Consistent naming: names like user-list, user-card, and user-detail make the structure predictable
• Modular organization: components are often generated under a specific module such as admin/users/user-form

This reduces confusion, especially in larger projects with dozens or hundreds of components.

1. Generating the component in the wrong location

Broken approach:

ng g c child

If you run this from the project root without a path, Angular CLI may generate child as a top-level component instead of placing it inside plainsight.

Use:

ng g c plainsight/child

2. Confusing folder nesting with component hierarchy

Creating a component inside a folder does not automatically make it a child in Angular's rendering tree.

For example, this command:

ng g c plainsight/child

creates a nested folder structure, but the child component will only appear inside PlainsightComponent if you actually use its selector in the parent template.

3. Forgetting to include the child selector in the parent template

Generated child component:

selector: 'app-child'

Parent template must use it:

<app-child></app-child>

# Full command
ng generate component plainsight/child

# Short alias
ng g c plainsight/child

Key idea

• Pass a path to Angular CLI, not just a component name.
• The path determines the folder structure.

Examples

ng g c users/user-list
ng g c users/user-detail
ng g c dashboard/activity-feed

Important rules

• Use / to indicate nested folders
• Angular CLI usually creates missing folders automatically
• The CLI usually updates the Angular module for you
• Folder nesting does not automatically render one component inside another

To make it a visual child component

1. Generate it in the parent folder
2. Find its selector in the generated component
3. Add that selector to the parent component template

Common command pattern

ng g c feature-name/sub-component-name

Can Angular CLI generate a component inside an existing folder?

Yes. Pass the folder path as part of the component name, such as ng g c plainsight/child.

Does generating inside a folder automatically make it a child component?

No. It only places the files inside that folder. To render it as a child, you must use its selector in the parent template.

Can Angular CLI create the folder if it does not exist?

Yes, Angular CLI typically creates the folder structure for the path you provide.

What is the short version of ng generate component?

You can use ng g c.

Should I use slashes in the component path?

Yes. Use forward slashes like plainsight/child to indicate nested folders.

Will Angular CLI update the module automatically?

In typical Angular CLI setups, yes. It usually adds the generated component to the nearest module declarations.

Is folder structure the same as component parent-child relationship?

No. Folder structure is for file organization. Parent-child rendering happens in templates using selectors.

• Angular components — The main building block being generated by the CLI.
• Angular CLI — The tool used to scaffold components, modules, services, and more.
• Angular modules — Generated components are usually declared in a module.
• Component selector — Needed to place a generated child component inside a parent template.
• Project structure — Organizing files by feature makes Angular apps easier to maintain.
• Feature modules — Larger Angular apps often group related components into feature modules.
• Parent and child components — Important for understanding the difference between folder nesting and rendered hierarchy.