Angular Meets Generative AI: Best Practices Made Easy

#angular #frontend #webdev #javascript

The use of generative AI to produce code is becoming increasingly popular in the developer world. From creating quick prototypes to scaffolding entire features, AI tools are no longer just assistants, they’re starting to become part of our workflow.

With Angular v20.2, a new CLI command allows you to generate a dedicated configuration file for AI models. This file defines project-specific guidelines, enabling generative AI to apply best practices, follow established coding patterns, and implement new functionality while remaining consistent with your codebase.

Let’s walk through how to generate this file and explore the set of rules it contains.

🤖 Generating the AI Configuration Files

Starting with Angular CLI v20.2, when creating a new project, the CLI prompts you to choose whether to include an AI configuration file:

ng new app

You’ll then be prompted to choose one or more AI tools to configure:

? Which AI tools do you want to configure with Angular best practices? 
  See: https://angular.dev/ai/develop-with-ai

❯ ◉ None  
  ◯ Claude                 [ https://docs.anthropic.com/en/docs/claude-code/memory ]  
  ◯ Cursor                 [ https://docs.cursor.com/en/context/rules ]  
  ◯ Gemini                 [ https://ai.google.dev/gemini-api/docs ]  
  ◯ GitHub Copilot         [ https://code.visualstudio.com/docs/copilot/copilot-customization#_custom-instructions ]  
  ◯ JetBrains AI Assistant [ https://www.jetbrains.com/help/junie/customize-guidelines.html ]  
  ◯ Windsurf               [ https://docs.windsurf.com/windsurf/cascade/memories#rules ]

The Angular CLI will generate a separate configuration file for each tool you select, placing it in its designated path:

Gemini → .gemini/GEMINI.md
Copilot → .github/copilot-instructions.md
Claude → .claude/CLAUDE.md
Cursor → .cursor/rules/cursor.mdc
JetBrains → .junie/guidelines.md
Windsurf → .windsurf/rules/guidelines.md

If you already know which AI tool you want to configure, you can skip the prompt and pass it directly as an option:

ng new app --ai-config=gemini
ng new app --ai-config=copilot
ng new app --ai-config=claude
ng new app --ai-config=cursor
ng new app --ai-config=jetbrains
ng new app --ai-config=windsurf

And if you skip this step, you can always add the configuration later in an existing project using one of the following commands:

# Start the prompt to choose which AI tool(s) to configure
ng generate ai-config

# Generate the AI configuration for a specific tool (Gemini in this example)
ng generate ai-config --tool=gemini

🔍 Let’s Analyze the Configuration File

The generated files have the same format for each selected AI tool.

Note: the Cursor file also includes some metadata, nothing to worry about

AI context for code generation

At the top of the file, a context is given to the AI:

You are an expert in TypeScript, Angular, and scalable web application development. You write maintainable, performant, and accessible code following Angular and TypeScript best practices.

This helps guide the AI to produce suggestions and scaffolding that align with the conventions and best practices for your Angular project.

Sections and rules

The rest of the file is then divided into several sections, each defining more context and rules for a specific area of development:

TypeScript Best Practices
Angular Best Practices
Components
State Management
Templates
Services

Here’s the full configuration file with all sections and rules:

## TypeScript Best Practices

- Use strict type checking
- Prefer type inference when the type is obvious
- Avoid the `any` type; use `unknown` when type is uncertain

## Angular Best Practices

- Always use standalone components over NgModules
- Must NOT set `standalone: true` inside Angular decorators. It's the default.
- Use signals for state management
- Implement lazy loading for feature routes
- Do NOT use the `@HostBinding` and `@HostListener` decorators. Put host bindings inside the `host` object of the `@Component` or `@Directive` decorator instead
- Use `NgOptimizedImage` for all static images.
  - `NgOptimizedImage` does not work for inline base64 images.

## Components

- Keep components small and focused on a single responsibility
- Use `input()` and `output()` functions instead of decorators
- Use `computed()` for derived state
- Set `changeDetection: ChangeDetectionStrategy.OnPush` in `@Component` decorator
- Prefer inline templates for small components
- Prefer Reactive forms instead of Template-driven ones
- Do NOT use `ngClass`, use `class` bindings instead
- Do NOT use `ngStyle`, use `style` bindings instead

## State Management

- Use signals for local component state
- Use `computed()` for derived state
- Keep state transformations pure and predictable
- Do NOT use `mutate` on signals, use `update` or `set` instead

## Templates

- Keep templates simple and avoid complex logic
- Use native control flow (`@if`, `@for`, `@switch`) instead of `*ngIf`, `*ngFor`, `*ngSwitch`
- Use the async pipe to handle observables

## Services

- Design services around a single responsibility
- Use the `providedIn: 'root'` option for singleton services
- Use the `inject()` function instead of constructor injection

As you can see, each section contains non-opinionated rules and focuses almost exclusively on using the new Angular APIs over the older ones.

For example, prefer the new Angular Control Flow directives (@if, @for, @switch) instead of *ngIf, *ngFor, and *ngSwitch. Similarly, use Signals and the input()/output() APIs over their older alternatives.

Add your own rules

If you’d like, you’re free to extend the configuration with your own rules, such as naming conventions, ordering preferences, or any other coding standards that better fit your team’s workflow.

You can either add new rules to the existing sections or create entirely new sections if needed.

For instance, a dedicated NgRx section could look like this:

## NgRx Best Practices

- Use feature-specific state slices rather than a single global state object.
- Always define action types using a `[Feature] Event` convention (e.g., `[Auth] Login Success`).
- Group effects logically per feature and keep side-effects outside of components.
- Avoid deeply nested state structures; normalize data when possible.

This file should be treated like code, but written in natural language. Structuring it thoughtfully and keeping it clean and organized is not trivial and should be done with care, just like any other code file.

📖 Useful Links for Further Reading

🎉 Thanks for Reading! Until Next Time! 🚀

If you found this useful, I’d love to hear your thoughts. Drop a comment, give a like, or follow me to stay in the loop. I’ll appreciate it! 👏

Share it with friends, colleagues, or anyone passionate about Angular.
Let’s connect on LinkedIn! 👋😁