Setting up Cursor IDE for Angular development

Cursor ships as a capable code editor from the moment you install it. It understands TypeScript, it has decent autocomplete, and its AI features work out of the box. But "works out of the box" and "works well for Angular" are two very different things.

Angular has strong opinions about file structure, dependency injection, component architecture, and reactive patterns. If Cursor does not know about those opinions, it will generate code that looks reasonable but breaks your conventions in subtle ways. A service that should be providedIn root gets provided in a component. A signal gets wrapped in an unnecessary Observable. A standalone component imports a module it does not need.

The good news is that Cursor was designed to be configured. A few deliberate setup steps turn it from a generic AI code editor into something that genuinely understands your Angular project. This guide walks through exactly how to do that.

Installing Cursor and the first launch

Cursor is a standalone editor built on top of VS Code. You download it from cursor.com and install it like any other desktop application. On macOS it drops into your Applications folder, on Windows it installs through a standard setup wizard, and on Linux you get an AppImage or deb package.

When you open Cursor for the first time, it will ask if you want to import your VS Code settings. Say yes. Your keybindings, theme, and font preferences carry over cleanly, and there is no reason to set them up again from scratch. Extensions also transfer, though you should audit the list before accepting everything blindly -- some VS Code extensions conflict with Cursor's built-in AI features.

Once the editor is open, create a new workspace by opening your Angular project folder. Cursor indexes the codebase on first open, which takes a few seconds for small projects and up to a minute for large monorepos. Let it finish. The index is what powers the AI's ability to understand your code in context.

The .cursor directory and where rules live

Cursor stores its project-level configuration in a directory called.cursor at the root of your workspace. If it does not exist yet, create it. Inside, the most important subdirectory is .cursor/rules/. This is where your cursor rules files go.

A cursor rules file is a plain Markdown file with the extension .mdc. The filename matters because Cursor uses it as an identifier. For an Angular project, you would typically create a file called angular.mdc inside .cursor/rules/.

The directory structure looks like this: your project root contains the .cursor/ folder, which contains rules/, which contains angular.mdc. You can add additional rule files for other concerns -- say, testing conventions or styling standards -- and Cursor will read all of them. Each file acts as a separate instruction set that feeds into the AI's context.

You should commit this directory to version control. The whole point of cursor rules is that every developer on the team gets the same AI behavior. If the rules live only on your machine, they are not doing their job.

How angular.mdc works

The angular.mdc file is where you describe your project's Angular conventions in plain language. Think of it as a style guide written for an AI rather than a human. You state things like "use standalone components, never NgModules" or "prefer signals over BehaviorSubject for component state" and Cursor incorporates those instructions into every AI interaction.

The file format is Markdown with a YAML frontmatter block at the top. The frontmatter typically includes a description field that tells Cursor when to apply the rules. For an Angular rule file, you might set the description to something like "Rules for Angular development in this project." The body of the file is freeform Markdown where you list your conventions.

There is no rigid schema. You write in natural language and the AI interprets it. That said, being specific helps. "Use signals" is vague. "Use Angular signals for all synchronous component state. Reserve RxJS observables for HTTP calls and complex async workflows" is actionable. The more precise your rules, the more consistent the generated code.

Cursor reads these rules every time you invoke an AI feature in a file that matches the rule's scope. If you are editing a TypeScript file in an Angular project with an angular.mdc in the rules directory, those rules are active.

Configuring extensions and editor settings

Since Cursor is built on VS Code, it supports the same extensions. For Angular development, a few are essential. The Angular Language Service extension provides template type checking, autocomplete in HTML templates, and go-to-definition for component selectors. Install it first. Without it, your templates are just strings as far as the editor is concerned.

ESLint integration matters too. If your project uses angular-eslint (and it should), install the ESLint extension so that linting feedback appears inline. This works alongside Cursor's AI -- when the AI generates code that violates a lint rule, you see the squiggly line immediately and can fix it before committing.

Prettier is worth adding for consistent formatting, especially if your cursor rules do not specify formatting preferences. Let Prettier handle semicolons, quotes, and indentation so your rules can focus on architecture and patterns.

On the settings side, a few tweaks improve the Angular experience. Enable editor.formatOnSave so generated code is always formatted. Set typescript.preferences.importModuleSpecifier to relative if your project uses relative imports, or non-relative if you use path aliases. This ensures that auto-imports from both the editor and the AI follow the same convention.

How rules interact with Cursor's AI features

Cursor has three primary AI interaction modes, and your rules affect all of them differently. Understanding how each one works helps you write better rules.

Tab completion is the most frequent interaction. As you type, Cursor predicts what comes next and offers multi-line suggestions. Your cursor rules influence these suggestions. If your rules say "always use inject() instead of constructor injection," Tab completions will favor the inject function when you start writing a service dependency. The effect is subtle but cumulative -- over a day of coding, it saves dozens of small corrections.

Cmd+K (or Ctrl+K on Windows and Linux) is the inline edit command. You select a block of code, hit the shortcut, and describe what you want to change in natural language. Cursor rewrites the selection based on your instruction and your rules. This is where rules shine. Without them, asking "refactor this to use signals" might produce code that mixes signal patterns with leftover RxJS. With rules that define your signal conventions explicitly, the output is clean and consistent.

Composer is the most powerful mode. It is a chat-style interface where you can ask Cursor to generate entire files, refactor across multiple files, or explain complex code. Composer has the largest context window of the three modes, which means it reads your cursor rules in full. This is where detailed rules about file structure, naming conventions, and architecture decisions pay off the most. When you ask Composer to "create a new feature module for user profiles," it will follow your rules about standalone components, signal-based state, and file organization.

Generating your first angular.mdc file

Writing a comprehensive rules file from scratch is tedious. You need to think about your Angular version, your state management approach, your component patterns, your testing strategy, your folder structure, and dozens of other decisions. That is why I built the Angular Cursor Rules Builder.

The builder walks you through each decision with sensible defaults. You pick your Angular version, choose between signals and RxJS, select standalone or module-based components, configure your styling approach, and set your testing preferences. At the end, it generates a ready-to-use angular.mdc file that you drop into your .cursor/rules/ directory.

It takes about two minutes, and it saves hours of inconsistent AI output. Once the file is in place, every Tab completion, every Cmd+K edit, and every Composer generation respects your project's conventions. That is the whole point -- not to fight the AI, but to teach it how your team works.

What to do after setup

Once Cursor is installed, your extensions are configured, and your angular.mdc is committed to the repo, you are ready to go. But the setup is not truly done -- it evolves. As your project grows, your rules should grow with it.

If you adopt a new library, add a rule about how to use it. If the AI keeps making the same mistake, add a rule that addresses it explicitly. If Angular ships a new major version and you upgrade, update your rules to reflect the new APIs. Think of your cursor rules file as a living document, not a one-time configuration.

The teams I have seen get the most value from Cursor are the ones that treat their rules file with the same care as their ESLint config or their tsconfig. It is not glamorous work, but it compounds. Every rule you add prevents the same mistake from happening again, across every developer on the team, in every AI interaction they have.

That is what makes this setup worth the fifteen minutes it takes. Not the initial convenience, but the long-term consistency it creates.