DEV Community: Antonio Cardenas

Las skills y las herramientas MCP no son lo mismo — y confundirlos tiene un costo real. Aprende la diferencia, los problemas reales y cómo combinarlos para un flujo de trabajo agéntico que sí funcione.

Todo el mundo habla de MCP. Todo el mundo habla de skills.

La mayoría los usa como sinónimos — y ese es exactamente el problema.

No son lo mismo. No resuelven el mismo problema. Y si usas el incorrecto, lo vas a sentir: alucinaciones, contexto desbordado, agentes que pierden el hilo y flujos de trabajo que se rompen bajo presión.

Vamos a resolverlo.

El modelo mental

Piénsalo como una cocina.

Las herramientas MCP son tus electrodomésticos e ingredientes — el horno, el refrigerador, los vegetales frescos. Capacidad pura. Sin ellos, no se cocina nada.

Los skills son tus recetas — las instrucciones paso a paso que le dicen a un chef exactamente cómo convertir esos ingredientes en algo bueno. Sin ellas, tienes poder, pero sin dirección.

Un agente con solo herramientas MCP puede hacer cosas, pero no necesariamente sabe cómo hacerlas bien. Un agente con solo skills tiene excelentes instrucciones, pero no puede actuar sobre ellas.

Necesitas los dos.

¿Qué es una herramienta MCP?

El Model Context Protocol es un estándar abierto — ahora bajo la Agentic AI Foundation de la Linux Foundation — que le da a los agentes de IA una forma estandarizada de conectarse a sistemas externos: bases de datos, APIs, sistemas de archivos, GitHub, Slack, tu Angular CLI.

Cuando conectas un servidor MCP a tu cliente —ya sea Claude Code, la CLI de Gemini o un agente personalizado—, este accede a un conjunto de herramientas deterministas y tipadas. Cada herramienta tiene un esquema claro de entrada y salida. Cuando el agente la llama, se ejecuta — sin interpretación, sin riesgo de alucinación a nivel de ejecución. Es una llamada de API estructurada, no una sugerencia.

{
  "mcpServers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

MCP es como el agente alcanza fuera de sí mismo. Es el sistema nervioso.

Usa MCP cuando el agente necesite:

Leer o escribir en un sistema real (base de datos, sistema de archivos, API)
Ejecutar acciones con entradas y salidas claras y auditables.
Conectarse a herramientas que no controlas
Integrar múltiples servicios a través de una interfaz consistente.

¿Qué es un skill?

Un skill es una carpeta que contiene un archivo Markdown (con frontmatter YAML) más scripts y recursos opcionales. No es ejecutable por sí solo — es un playbook.

Cuando la solicitud de un usuario coincide con los criterios de relevancia de un skill, el agente carga esas instrucciones dinámicamente y las sigue. Es como darle al agente memoria procedural de nivel experto, bajo demanda.

---
name: angular-component-review
description: Revisar componentes Angular para cumplimiento de Signals y arquitectura standalone
---

# Revisión de Componente Angular

Al revisar un componente Angular:
1. Verificar que todo el estado use `signal()` o `computed()` — nunca mutación directa
2. Confirmar que el componente es `standalone: true`
3. Asegurar que no queden dependencias de `NgModule`
4. Validar que se use `@if` / `@for` en lugar de `*ngIf` / `*ngFor`

El agente lo carga solo cuando es relevante. Cuando no lo es — no te cuesta nada.

Usa un skill cuando el agente lo necesite:

Seguir un proceso o checklist consistente.
Aplicar experiencia específica del dominio (tus estándares de código, criterios de revisión).
Codificar conocimiento que no cambia frecuentemente.
Reutilizar el mismo flujo de trabajo en distintas conversaciones.

Los desventajas reales

Aquí es donde la mayoría de las guías se detienen. No deberían.

MCP: El Impuesto de Tokens

Cada herramienta MCP que conectas inyecta su esquema completo en la ventana de contexto antes de que el agente procese un solo mensaje. Cada herramienta cuesta 550–1,400 tokens. Conecta GitHub, Slack y Sentry y estás mirando 55,000 tokens quemados de entrada — más de un cuarto del límite de 200k de Claude antes de hacer cualquier trabajo real.

Un equipo reportó conectar tres servidores MCP y consumir 143,000 de 200,000 tokens solo en definiciones de herramientas. Al agente le quedaban 57,000 tokens para la conversación real.

Y si usas Gemini con su ventana de contexto de 1M+ tokens, podrías pensar que puedes ignorar esto. No lo hagas. Incluso si te sobra espacio, inyectar 55,000 tokens de esquema JSON crudo en cada iteración de la conversación aumenta la latencia, incrementa los costos de la API y diluye el enfoque del modelo.

La buena noticia: clientes modernos como Claude Code y la CLI de Gemini han adoptado el progressive discovery para MCP — cargando solo nombres y descripciones de herramientas al inicio (~20–50 tokens cada una), y obteniendo los esquemas completos solo cuando el agente realmente necesita una herramienta. El overhead de tokens cayó ~85%. Pero esto solo funciona si tu configuración MCP está preparada para usarlo — y la mayoría todavía no lo está.

Skills: El Problema de la Desactualización

Los skills son archivos Markdown. No se actualizan solos. Si tus patrones de Angular evolucionan — digamos que migraste de setInput() a la nueva API declarativa en Angular 20 — tu Skill sigue enseñando la forma antigua hasta que alguien lo actualice manualmente.

Cuantos más skills creas, mayor es la carga de mantenimiento. Y si un skill está sutilmente equivocado, el agente lo seguirá con confianza — sin error, solo output silenciosamente incorrecto.

Ambos: El problema de selección

Dale a un agente demasiadas herramientas o demasiados skills y empieza a tomar las decisiones equivocadas — llama a la herramienta incorrecta, activa el playbook equivocado, o los combina de formas que producen instrucciones contradictorias. Los expertos recomiendan no superar 10–15 herramientas MCP activas al mismo tiempo.

Cómo combinarlos

El patrón más poderoso es usarlos como capas:

Capa 1 — MCP provee acceso.
Conecta solo lo que el agente genuinamente necesita para la tarea actual. Angular CLI, una base de datos, un sistema de archivos. Mantenlo simple.

Capa 2 — Skills proveen experiencia.
Crea un Skill que le diga al agente cómo usar esas herramientas en tu contexto específico. No solo "ejecuta el Angular CLI" — sino "al migrar un componente, ejecuta ng generate con estos flags, luego valida contra estos patrones."

Capa 3 — Skills pueden orquestar MCP.
Un skill puede definir un flujo de trabajo multipaso que llame a múltiples herramientas MCP en secuencia. Ejemplo: un skill de "Deploy & Notify" que usa el MCP de GitHub para hacer push, un MCP de CI/CD para lanzar el build, y un MCP de Slack para notificar al equipo — todo bajo un playbook coherente.

---
name: angular-migration-workflow
description: Flujo completo para migrar un componente Angular a patrones v21
---

# Flujo de Migración

1. Usa el MCP del Angular CLI para verificar la versión actual del componente
2. Ejecuta `ng update` para el paquete afectado
3. Aplica el schematic de migración zoneless
4. Revisa el output contra el Skill de angular-component-review
5. Ejecuta los tests y reporta resultados

Guía de Decisión Práctica

Situación	Usar
Necesito consultar una base de datos real	MCP
Necesito seguir un checklist de code review	Skill
Necesito hacer push a GitHub	MCP
Necesito aplicar el formato de commits de mi equipo	Skill
Necesito leer una API en vivo	MCP
Necesito enseñarle al agente mis reglas de arquitectura Angular	Skill
Necesito acceso Y proceso consistente	Ambos

Mejorando el Flujo de Trabajo

Algunos patrones que realmente funcionan en producción:

1. Un servidor MCP por dominio. No cargues todo al mismo tiempo. Crea configuraciones separadas para "desarrollo Angular", "despliegue" y "comunicación" — y activa solo la que necesitas para cada sesión.

2. Versiona tus Skills como código. Ponlos en tu repositorio. Revísalos cuando actualices tu stack. Un Skill para patrones de Angular 19 te va a perjudicar activamente en Angular 21.

3. Usa Skills para escribir guardrails de MCP. En lugar de confiar en que el agente sepa cuándo llamar a una acción MCP destructiva, escribe un Skill que diga explícitamente: "Antes de ejecutar cualquier ng update, siempre crea un branch de git primero."

4. Mide tu presupuesto de contexto. Antes de que el agente haga cualquier trabajo real, conoce cuántos tokens consume tu configuración MCP. Si superas el 30% de tu ventana de contexto solo en definiciones de herramientas, tienes un problema de configuración.

5. Deja que el agente mantenga los Skills simples. Para áreas de cambio rápido — como mantener actualizadas las convenciones de versión de Angular de tu equipo — deja que el agente actualice el archivo Skill cuando se lo indiques. Es más rápido que hacerlo manualmente y mantiene el Skill honesto.

La conclusión

MCP les da a los agentes la capacidad de actuar. Los skills les enseñan cómo actuar bien.

El debate de "MCP vs Skills" es falso. La pregunta real es: ¿necesitas acceso, experiencia, o ambos?

En la mayoría de los flujos de trabajo reales con Angular, necesitas los dos. Un agente que puede ejecutar tu CLI, pero no conoce tu arquitectura, es solo una forma más rápida de cometer los mismos errores. Un agente que conoce tus patrones, pero no puede tocar tu proyecto real, es solo un buscador caro.

Usados juntos, con límites claros y configuración lean, son la base del desarrollo agéntico que realmente funciona.

Anteriormente escribí sobre Angular 21, MCP y el fin de las migraciones manuales — un buen punto de partida si eres nuevo en la configuración del servidor MCP para Angular.

MCP Skills vs MCP Tools: The Right Way to Configure Your Server

Antonio Cardenas — Sun, 22 Mar 2026 08:40:00 +0000

Skills and MCP tools are not the same thing — and confusing them costs you. Learn the real difference, the real downsides, and how to combine both for a better agentic workflow.

MCP Skills vs MCP Tools: What's the Difference and How to Combine Them

Everyone is talking about MCP. Everyone is talking about skills.

Most people are using them interchangeably — and that's exactly the problem.

They are not the same thing. They don't solve the same problem. And if you reach for the wrong one, you will feel it: hallucinations, context blowups, agents that drift off-task, and workflows that fall apart under pressure.

Let's fix that.

The Core Mental Model

Think of it like a kitchen.

MCP tools are your appliances and ingredients — the oven, the fridge, the fresh vegetables. Raw capability. Without them, nothing gets cooked.

Skills are your recipes — the step-by-step instructions that tell a skilled chef exactly how to turn those ingredients into something good. Without them, you have power with no direction.

An agent with only MCP tools can do things but doesn't necessarily know how to do them well. An agent with only skills has great instructions but no way to act on them.

You need both.

What Is an MCP Tool?

The Model Context Protocol is an open standard — now under the Linux Foundation's Agentic AI Foundation — that gives AI agents a standardized way to connect to external systems: databases, APIs, file systems, GitHub, Slack, your Angular CLI.

When you connect an MCP server to your client—whether that's Claude Code, the Gemini CLI, or a custom agent—it gets access to a set of typed, deterministic tools. Each tool has a clear input/output schema. When the agent calls it, it executes — no interpretation, no hallucination risk at the execution level. It's a structured API call, not a suggestion.

{
  "mcpServers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

MCP is how the agent reaches outside itself. It's the nervous system.

Use MCP when you need the agent to:

Read or write to a real system (database, filesystem, API)
Execute actions with clear, auditable inputs and outputs
Connect to tools you don't own or control
Integrate multiple services through a consistent interface

What Is a Skill?

A Skill is a folder containing a Markdown file (with YAML frontmatter) plus optional scripts and resources. It's not executable by itself — it's a playbook.

When a user's request matches a Skill's relevance criteria, the agent loads those instructions dynamically and follows them. Think of it as giving the agent expert-level procedural memory on demand.

---
name: angular-component-review
description: Review Angular components for Signal compliance and standalone architecture
---

# Angular Component Review

When reviewing an Angular component:
1. Check that all state uses `signal()` or `computed()` — never direct property mutation
2. Verify the component is `standalone: true`
3. Confirm no `NgModule` dependencies remain
4. Validate that `@if` / `@for` is used instead of `*ngIf` / `*ngFor`

The agent loads this only when it's relevant. When it's not — it costs you nothing.

Use a skill when you need the agent to:

Follow a consistent process or checklist
Apply domain-specific expertise (your coding standards, review criteria)
Encode knowledge that doesn't change often
Reuse the same workflow across different conversations

The Real Downsides

This is where most guides stop. They shouldn't.

MCP: The Token Tax

Every MCP tool you connect injects its full schema into the context window before the agent processes a single message. Each tool costs 550–1,400 tokens. Connect GitHub, Slack, and Sentry, and you're looking at 55,000 tokens burned upfront — over a quarter of Claude's 200k limit before any real work begins. And if you are using Gemini with its 1M+ token window, you might think you can just ignore this. Don't. Even if you have the space to spare, dumping 55,000 tokens of raw JSON schema into every single turn of a conversation drives up your latency, increases API costs, and dilutes the model's focus.

One team reported connecting three MCP servers and consuming 143,000 of 200,000 tokens on tool definitions alone. The agent had 57,000 tokens left for the actual conversation.

The good news: modern clients like Claude Code and the Gemini CLI have adopted progressive discovery for MCP—loading only tool names and descriptions upfront (~20–50 tokens each) and fetching full schemas only when the agent actually needs a tool. Token overhead declined by ~85%. But this feature only works if your MCP setup is configured to use it, and most setups still aren't.

Skills: The Staleness Problem

Skills are Markdown files. They don't update themselves. If your Angular patterns evolve — say you migrate from setInput() to the new declarative API in Angular 20 — your Skill still teaches the old way until someone updates it manually.

The more skills you create, the more maintenance burden you carry. And if a skill is subtly wrong, the agent will follow it confidently — no error, just quietly incorrect output.

Both: The Selection Problem

Give an agent too many tools or too many skills, and it starts making the wrong choices — calling the wrong tool, triggering the wrong playbook, or combining them in ways that produce contradictory instructions. Experts recommend staying under 10–15 active MCP tools at any time.

How to Combine Them

The most powerful pattern is using them as layers:

Layer 1 — MCP provides access.
Connect only what the agent genuinely needs for the current task. Angular CLI, a database, and a file system. Keep it lean.

Layer 2 — Skills provide expertise.
Create a skill that tells the agent how to use those tools in your specific context. Not just "run the Angular CLI" — but "when migrating a component, run ng generate with these flags, then validate against these patterns."

Layer 3 — Skills can orchestrate MCP.
A Skill can define a multi-step workflow that calls multiple MCP tools in sequence. Example: a "Deploy & Notify" Skill that uses GitHub MCP to push, a CI/CD MCP to trigger a build, and a Slack MCP to notify the team — all under one coherent playbook.

---
name: angular-migration-workflow
description: Full workflow for migrating an Angular component to v21 patterns
---

# Migration Workflow

1. Use the Angular CLI MCP to check the current component version
2. Run `ng update` for the affected package
3. Apply the zoneless migration schematic
4. Review the output against the angular-component-review Skill
5. Run tests and report results

The Practical Decision Guide

Situation	Use
Need to query a real database	MCP
Need to follow a code review checklist	Skill
Need to push to GitHub	MCP
Need to apply your team's commit message format	Skill
Need to read a live API	MCP
Need to teach the agent your Angular architecture rules	Skill
Need both access and consistent process	Both

Improving Your Workflow

A few patterns that actually work in production:

1. One MCP server per domain. Don't load everything at once. Create separate configs for "Angular development," "deployment," and "communication" — and activate only the one you need for a given session.

2. Version your Skills like code. Put them in your repository. Review them when you update your stack. A Skill for Angular 19 patterns will actively hurt you on Angular 21.

3. Use Skills to write MCP guardrails. Instead of relying on the agent to figure out when to call a destructive MCP action, write a Skill that explicitly says: "Before running any ng update, always create a git branch first."

4. Measure your context budget. Before your agent does any real work, know how many tokens your MCP setup consumes. If you're over 30% of your context window is on tool definitions, you have a configuration problem.

5. Let the agent maintain simple Skills. For fast-moving areas — like keeping track of your team's current Angular version conventions — let the agent update the Skill file itself when you tell it to. It's faster than doing it manually and keeps the Skill honest.

The Bottom Line

MCP gives agents the ability to act. Skills teach them how to act well.

The debate of "MCP vs Skills" is a false one. The real question is: do you need access, expertise, or both?

In most real Angular workflows, you need both. An agent that can run your CLI but doesn't know your architecture is just a faster way to make the same mistakes. An agent that knows your patterns but can't touch your actual project is just an expensive search engine.

Used together, with clear boundaries and lean configuration, they're the foundation of agentic development that actually works.

Previously I wrote about Angular 21 MCP and the end of manual migrations — a good starting point if you're new to the MCP server setup for Angular.

Angular 20 to 21 Upgrade: The Practical Survival Guide

Antonio Cardenas — Sat, 13 Dec 2025 07:48:14 +0000

A clear and concise guide to upgrading from Angular 20 to 21. that Covers the essentials like the Karma full removal, the new default Zoneless mode, automatic HttpClient, and how to fix your breaking builds.

If you thought Angular 20 was a big shift, welcome to Angular 21.

While version 20 was about stabilizing Signals, version 21 is about removing most of the old patterns. The "Angular Way" has fundamentally changed: zone.js is optional, Karma is dead, and RxJS is slowly retreating to the edges.

This isn't just an update; it's a new ecosystem. Here is what is going to break and how to fix it.

🚨 The "Stop Everything" Breaking Changes

Before you run ng update, be aware that your build will likely fail if you rely on these legacy patterns.

1. The Karma Extinction Event (Vitest is Default)

The most immediate shock for many teams will be ng test. Angular 21 has officially swapped Karma for Vitest as the default test runner.

What breaks: If you have a custom karma.conf.js or rely on specific Karma plugins/reporters, your test suite is now legacy code.

The Fix:

New Projects: You get Vitest out of the box. It's faster, cleaner, and uses Vite.
Existing Projects: You aren't forced to switch immediately, but the writing is on the wall. The CLI will nag you.
Migration: Run the schematic ng generate @angular/core:karma-to-vitest to attempt an auto-migration. It's remarkably good at converting standard configs, but custom Webpack hacks in your test setup will need manual rewriting for Vite.

2. HttpClient is "Just There"

Remember adding provideHttpClient() to your app.config.ts or importing HttpClientModule?

The Change: HttpClient is now injected by default in the root injector.

What breaks:

If you have tests that mock HttpClient by expecting it not to be there, they might fail.
If you rely on HttpClientModule for complex interceptor ordering in a mixed NgModule/Standalone app, you might see subtle behavior changes.

The Fix: Remove explicit provideHttpClient() calls unless you are passing configuration options (like withInterceptors or withFetch). It cleans up your config, but check your interceptor execution order.

3. zone.js is Gone (For New Apps)

New apps generated with ng new will exclude zone.js by default.

What breaks: Nothing for existing apps (yet). Your polyfils.ts will keep importing Zone.

The Warning: If you copy-paste code from a new v21 tutorial into your existing v20 app, it might assume Zoneless behavior (using ChangeDetectorRef less often, relying on Signals). If you mix the two paradigms without understanding them, you'll get "changed after checked" errors or views that don't update.

✨ The New Toys: Features You'll Actually Use

Once you fix the build, v21 offers some incredible DX improvements.

1. Signal Forms (Experimental but Stable)

This is the feature we've been waiting for. No more valueChanges.pipe(...)spaghetti.

import { form, field } from '@angular/forms/signals';

// Define a reactive form model
const loginForm = form({
  email: field('', [Validators.required, Validators.email]),
  password: field('', [Validators.required])
});

// Access values directly as signals!
console.log(loginForm.value().email);

Why use it: It's type-safe by default and doesn't require RxJS mastery.

Status: Experimental. Use it for new features, but maybe don't rewrite your checkout flow just yet.

2. Angular Aria (Developer Preview)

A new library of headless primitives for accessibility.

Instead of fighting with aria-expanded and role="button", you use directives that handle the a11y logic while you handle the CSS.

<!-- Handles keyboard nav, focus, and ARIA roles automatically -->
<div ariaMenu>
  <button ariaMenuItem>Option 1</button>
  <button ariaMenuItem>Option 2</button>
</div>

3. Regex in Templates

Small but mighty. You can finally use regex literals in templates, perfect for @iflogic without creating a helper function.

@if (email() | match: /@company\.com$/) {
  <span class="badge">Employee</span>
}

🛠️ The Upgrade Checklist

Ready to jump? Follow this order to minimize pain.

Backup: Commit everything. Seriously.

Update the Global CLI:
Updating Angular generally involves two parts: the global CLI and the local project dependencies. Ensure your global CLI is up to date first (you might need sudo or Administrator privileges).

# Optional: Uninstall the old global version first to avoid conflicts
npm uninstall -g @angular/cli

# Verify the npm cache
npm cache verify

# Install the latest global CLI version
npm install -g @angular/cli@latest

Update Local Project:
Now update your local project dependencies:
```
ng update @angular/cli@21 @angular/core@21
```
Run the Diagnostics:
Angular 21 includes smarter diagnostics. Pay attention to warnings about ngClass (soft deprecated in favor of [class.my-class]) and standalone migration opportunities.
Check Your Tests:
Run ng test. If it explodes, decide:
- Path A: Keep Karma (add @angular/build:karma manually if removed).
- Path B: Migrate to Vitest (Recommended).
Optional: Go Zoneless:
If you're feeling brave, run the experimental migration:
```
ng generate @angular/core:zoneless-migration
```

This is "Agentic" territory. See our MCP Guide for how to let AI handle this complex refactor.

Summary

Angular 21 is the "clean slate" release. It sheds the weight of the last decade (Zone, Karma, Modules) to compete with modern frameworks like Svelte and Solid.

The upgrade might be bumpy due to the testing changes, but the destination—a faster, simpler, signal-driven framework—is absolutely worth it.

Angular 21 & MCP: The End of "Manual" Migrations?

Antonio Cardenas — Sat, 13 Dec 2025 07:48:04 +0000

Angular 21 introduces the Model Context Protocol (MCP) server.

Learn how to connect your AI editor directly to the Angular CLI to automate upgrades, refactoring, and architectural shifts like Zoneless.

We used to treat AI like a smart stranger. We would copy-paste error messages or file contents into ChatGPT, hoping it understood our project's architecture. It was helpful, but it was blind.

With Angular 21, that stranger has moved into your house.

The release of the Angular CLI MCP Server (ng mcp) marks a fundamental shift in how we maintain applications. It isn't just a new command; it's a protocol that allows AI agents (like Cursor, Windsurf, or VS Code Copilot) to "interview" your project, understand your specific constraints, and run migrations that actually compile.

Here is why the "manual migration" era might be ending and how to survive the new Agentic Workflow.

What is MCP? (The "USB Port" for AI)

The Model Context Protocol (MCP) is an open standard that lets AI models connect to local tools and data.

Think of it this way:

Before MCP: You paste angular.json into the chat so the AI knows your file structure.

After MCP: The AI simply asks the Angular CLI, "Hey, list all the projects in this workspace," and the CLI responds with the exact structure, build targets, and library dependencies.

In Angular 21, the CLI is an MCP server. It exposes "tools" that your AI editor can call directly.

Setting It Up: 5 Minutes to "Agentic" Angular

The setup is surprisingly trivial because the Angular team baked it directly into the CLI.

1. Initialize the Server

In your Angular 21 workspace terminal:

ng mcp

This command doesn't start a daemon; it generates the configuration snippets you need for your specific IDE.

2. Connect Your Editor (e.g., Cursor)

If you are using Cursor (which you probably should be if you're interested in MCP), create or edit .cursor/mcp.json or if you are using Antigravity (which you probably should be if you're interested in MCP), create or edit .gemini/antigravity/mcp.json in your project root:

{
  "mcpServers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

To double-check the CURSOR configuration, in cursor click in the three dots in the top right corner and select "Agent Settings."

then click in "Tools & MCP." if everything is configured correctly, you should see angular as installed MCP server listed with the name of the tool as "ai_tutor."

To double-check the Antigravity configuration, in Antigravity click on the three dots in the top right corner and select "MCP Servers."

then you will see 'angular-cli' listed, and you can manage the tools, having the ability to enable or disable them.

[!NOTE]
The -y flag is crucial to prevent the "Press y to install" prompt from hanging the background process.

Available Tools

The Angular CLI MCP server provides several tools to assist you in your development workflow. By default, the following tools are enabled:

Tool Name	Read-Only	Local-Only
`ai_tutor`	✅	❌
`find_examples`	✅	❌
`get_best_practices`	✅	❌
`list_projects`	✅	✅
`angular.json`	✅	✅
`onpush_zoneless_migration`	✅	✅
`search_documentation`	✅	❌

Experimental Tools

Some tools are provided in experimental/preview status. You can enable them explicitly:

Tool Name	Read-Only	Local-Only
`modernize`	✅	❌

[!NOTE]
The -y flag is crucial to prevent the "Press y to install" prompt from hanging the background process.

The "Killer App": Context-Aware Migrations

Why go through this trouble? Because Context-Aware Migrations blow standard schematics out of the water.

Traditional ng update scripts are rigid. They follow a strict "If A, then B" logic. If your architecture is weird (and let's be honest, every enterprise architecture is weird), the script breaks or produces code you have to rewrite.

The MCP Server exposes tools that change this dynamic:

Tool 1: `get_best_practices`

The AI can fetch the current Angular team recommendations. It won't hallucinate that you should use SharedModule in 2025 because it "read it on a blog from 2021." It asks the CLI for the ground truth.

Tool 2: `onpush_zoneless_migration`

This is the big one for v21. Instead of blindly changing ChangeDetectionStrategy.Default to OnPush, the AI uses this tool to analyze your dependency graph.

The Workflow:

You: "Hey, I want to migrate user-profile.ts to Zoneless. Check if it's safe."

AI (Internal Thought): I need to check the component style. I'll call list_projects to find the root, then read the file.

AI (Internal Thought): I see an Observable subscription in ngOnInit. I'll check get_best_practices for handling async in Zoneless.

AI (Action): "I detected an unmanaged subscription. In Zoneless, this won't trigger a render. I recommend converting this user$ observable to a Signal using toSignal() before we switch the strategy."

It doesn't just apply a fix; it negotiates the refactor with you based on the framework's internal logic.

Tool 3: `search_documentation`

The AI doesn't need to guess API signatures. It queries the local offline documentation index provided by the MCP server.

Real-World Scenario: The "Legacy" Cleanup

Let's say you have an Angular 17-style component using HttpClientModule (deprecated approach) and RxJS for simple state.

Prompt to Cursor (with MCP active):

"Refactor dashboard.component.ts to align with Angular 21 best practices. Use the get_best_practices tool to verify your plan first."

What happens:

The AI calls get_best_practices and learns that standalone: true, inject(), and Signals are the standard.
It calls modernize (an experimental tool in v21) to run the standard schematics.
It manually cleans up the leftovers—converting constructor(private http: HttpClient) to private http = inject(HttpClient).
It converts your BehaviorSubject state to signal.

The result is code that looks like it was written in v21, not just patched to run in v21.

The Future: Continuous Maintenance

This release signals a change in how Google views the CLI. It's no longer just a build tool; it's an interface for agents.

In the near future, we likely won't "stop development" to upgrade. We will have a background agent running via MCP that opens PRs:

"I noticed you used a ControlValueAccessor here. I've created a PR to refactor this to the new Signal Forms input API."

"Angular v22 just dropped. I've updated your angular.json and verified your tests via vitest."

Summary: Don't Upgrade Alone

If you are moving to Angular 21, do not just run ng update and fight the compile errors manually.

Install the MCP server.
Let the AI map your project.
Ask it to plan the migration for you.

The code is still your responsibility, but the grunt work? That belongs to the machine now.

Actualizando a Angular 21 usando ng mcp

Antonio Cardenas — Sat, 13 Dec 2025 07:47:54 +0000

Angular 21 introduce el servidor Model Context Protocol (MCP). Aprende cómo conectar tu editor de IA directamente al CLI de Angular para automatizar actualizaciones, refactorizaciones y cambios arquitectónicos como Zoneless.

Solíamos tratar a la IA como a un extraño inteligente. Copiábamos y pegábamos mensajes de error o contenidos de archivos en ChatGPT, esperando que entendiera la arquitectura de nuestro proyecto. Era útil, pero estaba ciega.

Con Angular 21, ese extraño se ha mudado a tu casa.

El lanzamiento del servidor MCP del CLI de Angular (ng mcp) marca un cambio fundamental en la forma en que mantenemos las aplicaciones.

No es solo un nuevo comando; es un protocolo que permite a los agentes de IA (como Cursor, Windsurf o VS Code Copilot) "entrevistar" a tu proyecto, entender tus restricciones específicas y ejecutar migraciones que realmente compilen.

He aquí por qué la era de la "migración manual" podría estar terminando, y cómo sobrevivir al nuevo flujo de trabajo agéntico.

¿Qué es MCP? (El "puerto USB" para la IA)

El Model Context Protocol (MCP) es un estándar abierto que permite a los modelos de IA conectarse a herramientas y datos locales.

Piénsalo de esta manera:

Antes de MCP: Pegabas angular.json en el chat para que la IA conociera tu estructura de archivos.

Después de MCP: La IA simplemente pregunta al CLI de Angular: "Oye, lista todos los proyectos en este espacio de trabajo", y el CLI responde con la estructura exacta, los objetivos de compilación y las dependencias de bibliotecas.

En Angular 21, el CLI es un servidor MCP. Expone "herramientas" que tu editor de IA puede llamar directamente.

Configuración: 5 minutos para un Angular "agéntico"

La configuración es sorprendentemente trivial porque el equipo de Angular la integró directamente en el CLI.

1. Inicializar el servidor.

En tu terminal del espacio de trabajo de Angular 21:

ng mcp

Este comando no inicia un demonio; genera los fragmentos de configuración que necesitas para tu IDE específico.

2. Conectar tu editor (por ejemplo, Cursor).

Si estás usando Cursor (que probablemente deberías estar usando si te interesa MCP), crea o edita .cursor/mcp.json o, si usas Antigravity, crea o edita .gemini/antigravity/mcp.json en la raíz de tu proyecto:

{
  "mcpServers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

Para verificar la configuración de CURSOR, haz clic en los tres puntos en la esquina superior derecha y selecciona "Agent Settings".

Luego haz clic en "Tools & MCP". Si todo está configurado correctamente, deberías ver angular listado como servidor MCP instalado con el nombre de la herramienta como "ai_tutor".

Para verificar la configuración de Antigravity, haz clic en los tres puntos en la esquina superior derecha y selecciona "MCP Servers".

Luego verás listado 'angular-cli' y podrás gestionar las herramientas, teniendo la capacidad de habilitarlas o deshabilitarlas.

[NOTE]
La flag -y es crucial para evitar que el mensaje "Press y to install" bloquee el proceso en segundo plano.

Herramientas disponibles

El servidor MCP del CLI de Angular proporciona varias herramientas para ayudarte en tu flujo de trabajo de desarrollo. Por defecto, las siguientes herramientas están habilitadas:

Herramienta	Solo lectura	Solo local
`ai_tutor`	✅	❌
`find_examples`	✅	❌
`get_best_practices`	✅	❌
`list_projects`	✅	✅
`angular.json`	✅	✅
`onpush_zoneless_migration`	✅	✅
`search_documentation`	✅	❌

Herramientas experimentales

Algunas herramientas se proporcionan en estado experimental / vista previa. Puedes habilitarlas explícitamente:

Herramienta	Solo lectura	Solo local
`modernize`	✅	❌

La "killer app": Migraciones conscientes del contexto

¿Por qué pasar por este problema? Porque las migraciones conscientes del contexto superan con creces a los esquemáticos estándar.

Los scripts tradicionales de ng update son rígidos. Siguen una lógica estricta de "Si A, entonces B". Si tu arquitectura es rara (y seamos honestos, cada arquitectura empresarial es rara), el script se rompe o produce código que tienes que reescribir.

El servidor MCP expone herramientas que cambian esta dinámica:

Herramienta 1: `get_best_practices`

La IA puede obtener las recomendaciones actuales del equipo de Angular. No alucinará que deberías usar SharedModule en 2025 porque "lo leyó en un blog de 2021". Pregunta al CLI por la verdad fundamental.

Herramienta 2: `onpush_zoneless_migration`

Esta es la grande para la v21. En lugar de cambiar ciegamente ChangeDetectionStrategy.Default a OnPush, la IA utiliza esta herramienta para analizar tu gráfico de dependencias.

El flujo de trabajo:

Tú: "Oye, quiero migrar user-profile.ts a Zoneless. Comprueba si es seguro."

IA (Pensamiento Interno): Necesito comprobar el estilo del componente. Llamaré a list_projects para encontrar la raíz, luego leeré el archivo.

IA (Pensamiento Interno): Veo una suscripción a Observable en ngOnInit. Comprobaré get_best_practices para manejar asincronía en Zoneless.

IA (Acción): "Detecté una suscripción no gestionada. En Zoneless, esto no activará un renderizado. Recomiendo convertir este observable user$ a una Signal usando toSignal() antes de cambiar la estrategia."

No solo aplica una solución; negocia la refactorización contigo basándose en la lógica interna del marco.

Herramienta 3: `search_documentation`

La IA no necesita adivinar las firmas de la API. Consulta el índice de documentación local fuera de línea proporcionado por el servidor MCP.

Escenario del mundo real: La limpieza "Legacy"

Digamos que tienes un componente al estilo Angular 17 usando HttpClientModule (enfoque obsoleto) y RxJS para estado simple.

Prompt a Cursor (con MCP activo):

"Refactoriza dashboard.component.ts para alinearlo con las mejores prácticas de Angular 21. Usa la herramienta get_best_practices para verificar tu plan primero."

Qué sucede:

La IA llama a get_best_practices y aprende que standalone: true, inject() y Signals son el estándar.
Llama a modernize (una herramienta experimental en v21) para ejecutar los esquemáticos estándar.
Limpia manualmente los restos: convirtiendo constructor(private http: HttpClient) a private http = inject(HttpClient).
Convierte tu estado BehaviorSubject a signal.

El resultado es código que parece escrito en v21, no solo parcheado para ejecutarse en v21.

El futuro: Mantenimiento continuo

Este lanzamiento señala un cambio en cómo Google ve el CLI. Ya no es solo una herramienta de construcción; es una interfaz para agentes.

En el futuro cercano, probablemente no "pararemos el desarrollo" para actualizar. Tendremos un agente en segundo plano ejecutándose vía MCP que abre PRs:

"Noté que usaste un ControlValueAccessor aquí. He creado un PR para refactorizar esto a la nueva API de entrada de Signal Forms."

"Angular v22 acaba de salir. He actualizado tu angular.json y verificado tus pruebas vía vitest."

Resumen: No actualices solo.

Si te estás moviendo a Angular 21, no ejecutes simplemente ng update y pelees con los errores de compilación manualmente.

Instala el servidor MCP.
Deja que la IA mapee tu proyecto.
Pídele que planifique la migración por ti.

El código sigue siendo tu responsabilidad, ¿pero el trabajo pesado? Eso pertenece a la máquina ahora.

Migrando Angular 20 a 21: Guía.

Antonio Cardenas — Sat, 13 Dec 2025 07:47:46 +0000

Una guía sin rodeos para actualizar de Angular 20 a 21. Cubre la eliminación de Karma, el nuevo modo Zoneless por defecto, HttpClient automático y cómo arreglar tus compilaciones rotas.

Si pensabas que Angular 20 fue un gran cambio, bienvenido a Angular 21.

Mientras la versión 20 trataba de estabilizar Signals, la versión 21 trata de mejorar la experiencia del desarrollador. Angular ha cambiado fundamentalmente: zone.js es opcional, Karma está muerto y RxJS parece ser reemplazado lentamente.

Esto no es solo una actualización; se siente como todo un ecosistema nuevo. Aquí está lo que se va a romper y cómo arreglarlo.

Lo crítico que detienen todo

Antes de ejecutar ng update, ten en cuenta que tu compilación probablemente fallará si dependes de estos patrones heredados.

1. El Evento de Extinción de Karma (Vitest es el predeterminado)

El choque más inmediato para muchos equipos será ng test. Angular 21 ha cambiado oficialmente Karma por Vitest como el ejecutor de pruebas predeterminado.

Qué se rompe: Si tienes un karma.conf.js personalizado o dependes de complementos/reportadores específicos de Karma, tu suite de pruebas es ahora código heredado.

La solución:

Nuevos proyectos: Obtienes Vitest desde el principio. Es más rápido, más limpio y usa Vite.
Proyectos existentes: No estás obligado a cambiar inmediatamente, pero el final está cerca. El CLI te insistirá.
Migración: Ejecuta el s ng generate @angular/core:karma-to-vitest para intentar una auto-migración. Es notablemente bueno convirtiendo configuraciones estándar, pero los trucos personalizados de Webpack en tu configuración de pruebas necesitarán reescritura manual para Vite.

2. HttpClient está "simplemente ahí".

¿Recuerdas añadir provideHttpClient() a tu app.config.ts o importar HttpClientModule?

El cambio: HttpClient ahora se inyecta por defecto en el inyector raíz.

Qué se rompe:

Si tienes pruebas que simulan HttpClient esperando que no esté allí, podrían fallar.
Si dependes de HttpClientModule para un orden complejo de interceptores en una aplicación mixta NgModule/Standalone, podrías ver cambios sutiles de comportamiento.

La solución: Elimina las llamadas explícitas a provideHttpClient() a menos que estés pasando opciones de configuración (como withInterceptors o withFetch). Limpia tu configuración, pero comprueba el orden de ejecución de tus interceptores.

3. zone.js se ha ido (para nuevas apps).

Las nuevas aplicaciones generadas con ng new excluirán zone.js por defecto.

Qué se rompe: Nada para las aplicaciones existentes (todavía). Tu polyfils.ts seguirá importando Zone.

La advertencia: Si copias y pegas código de un tutorial nuevo de v21 en tu aplicación v20 existente, podría asumir un comportamiento Zoneless (usando menos ChangeDetectorRef, confiando en Signals). Si mezclas los dos paradigmas sin entenderlos, obtendrás errores "changed after checked" o vistas que no se actualizan.

✨ Las nuevas características

Una vez que arregles la compilación, la v21 ofrece algunas mejoras increíbles en la experiencia de desarrollo (DX).

1. Signal Forms (Experimental pero estable)

Esta es la característica que hemos estado esperando. No más espagueti de valueChanges.pipe(...).

import { form, field } from '@angular/forms/signals';

// Definir un modelo de formulario reactivo
const loginForm = form({
  email: field('', [Validators.required, Validators.email]),
  password: field('', [Validators.required])
});

// ¡Accede a los valores directamente como signals!
console.log(loginForm.value().email);

Por qué usarlo: Es seguro en cuanto a tipos por defecto y no requiere maestría en RxJS.

Estado: Experimental. Úsalo para nuevas características, pero tal vez no reescribas tu flujo de pago todavía.

2. Angular Aria (Developer Preview)

Una nueva biblioteca de primitivas "headless" para accesibilidad.

En lugar de pelear con aria-expanded y role="button", usas directivas que manejan la lógica de accesibilidad mientras tú manejas el CSS.

<!-- Maneja navegación por teclado, foco y roles ARIA automáticamente -->
<div ariaMenu>
  <button ariaMenuItem>Opción 1</button>
  <button ariaMenuItem>Opción 2</button>
</div>

3. Regex en plantillas

Pequeño pero poderoso. Finalmente, puedes usar literales de expresiones regulares en plantillas, perfecto para la lógica @if sin crear una función auxiliar.

@if (email() | match: /@company\.com$/) {
  <span class="badge">Empleado</span>
}

🛠️ La lista de verificación de actualización

¿Listo para saltar? Sigue este orden para minimizar el dolor.

Copia de seguridad: Haz commit de todo. En serio.

Actualizar el CLI Global:
Actualizar Angular generalmente implica dos partes: el CLI global y las dependencias locales del proyecto. Asegúrate de que tu CLI global esté actualizado primero (podrías necesitar sudo o privilegios de administrador).

# Opcional: Desinstalar la versión global antigua primero para evitar conflictos
npm uninstall -g @angular/cli

# Verificar la caché de npm
npm cache verify

# Instalar la última versión global del CLI
npm install -g @angular/cli@latest

Actualizar proyecto local:
Ahora actualiza las dependencias locales de tu proyecto:
```
ng update @angular/cli@21 @angular/core@21
```
Ejecutar los diagnósticos:
Angular 21 incluye diagnósticos más inteligentes. Presta atención a las advertencias sobre ngClass (obsoleto a favor de [class.my-class]) y oportunidades de migración standalone.
Comprobar tus pruebas:
Ejecuta ng test. Si explota, decide:
- Ruta A: Mantener Karma (añadir @angular/build:karma manualmente si se eliminó).
- Ruta B: Migrar a Vitest (recomendado).
Opcional: Ir zoneless:
Si te sientes valiente, ejecuta la migración experimental:
```
ng generate @angular/core:zoneless-migration
```

Nota
Esto es territorio "Agéntico". Mira nuestra Guía MCP para saber cómo dejar que la IA maneje esta refactorización compleja.

Resumen

Angular 21 es el lanzamiento de "borrón y cuenta nueva". Se deshace del peso de la última década (Zone, Karma, Modules) para competir con marcos modernos como Svelte y Solid.

La actualización puede ser irregular debido a los cambios en las pruebas, pero el destino —un marco más rápido, más simple e impulsado por signals— vale absolutamente la pena.

El cambio declarativo de Angular

Antonio Cardenas — Sun, 19 Oct 2025 09:02:30 +0000

Cómo la Nueva Estructura de Carpetas lo Cambia Todo

Si no has actualizado a la versión 20, la primera y segunda parte de esta guía te pueden ayudar a comprender qué cambia y actualizar.

Parte 1: La actualización en sí misma 🛠️

Primero, resolvamos lo básico. Antes de ejecutar cualquier comando, asegúrate de que tu entorno esté listo.

Prerrequisitos

Node.js: v20.11.1 o posterior.
TypeScript: v5.8 o posterior.
**Copia de seguridad del proyecto: Asegúrate de confirmar todos tus cambios actuales en Git. En serio.

El Comando de Actualización

Una vez que hayas confirmado tu versión de Node.js, ejecuta el comando que se ajuste a tu proyecto.

Para un proyecto estándar de Angular:

ng update @angular/cli @angular/core

Si utilizas Angular Material:

ng update @angular/cli @angular/core @angular/material

El proceso de actualización se ejecutará, pero es probable que te encuentres con tu primer obstáculo de inmediato.

*Parte 2: Lo que se rompe inmediatamente *

A diferencia de las actualizaciones anteriores, Angular 20 introduce un cambio significativo que detendrá tu compilación.

1. La Historia Completa Detrás de la Eliminación de Karma

Lo primero que notarás es que ng test fallará. Esto no es solo un error; es un cambio fundamental en las herramientas de compilación de Angular. Con Angular 20, el paquete de compilación predeterminado cambia de @angular-devkit/build-angular al nuevo @angular/build. Este nuevo paquete no incluye Karma. El ecosistema web ha avanzado hacia ejecutores de pruebas más rápidos y modernos como Vitest y Jest, y Karma se había convertido en un cuello de botella.

La solución temporal:

Para que tus pruebas se ejecuten sin migrar todo hoy, debes reinstalar manualmente la antigua herramienta de compilación. Esto obliga a la CLI a usar el antiguo compilador que aún es compatible con Karma.

npm install @angular-devkit/build-angular --save-dev

Este es un puente de compatibilidad. El mensaje del equipo de Angular es claro: comienza a planificar tu migración a Jest o Vitest pronto.

2. browserslist y soporte de navegadores

Aquí hay un detalle menor que podría sorprenderte. Angular 20 oficialmente ya no es compatible con Opera. Si tienes "Opera" listado en tu archivo .browserslistrc, tu compilación puede fallar o arrojar advertencias. Quítalo para resolver el problema.

*Parte 3: La Nueva Arquitectura *

Más allá de los cambios importantes, Angular 20 impulsa una arquitectura más moderna, explícita y escalable.

1. Componentes standalone por defecto.

Los nuevos proyectos generados con ng new ahora son standalone (independientes) por defecto. Esto marca un cambio arquitectónico fundamental que se aleja de los NgModules. Al listar las dependencias directamente en el array imports de un componente, cada componente se vuelve autocontenido.

¿Qué implica este cambio?:

Arquitectura más clara y definida: Sabes exactamente lo que necesita cada componente.
Mejora el *tree-shaking*: Conduce a paquetes más pequeños y optimizados.

Para migrar tus proyectos existentes, puedes ejecutar el schematic de migración standalone:

ng generate @angular/core:standalone

2. Una estructura de carpetas que cuenta una historia

Una buena estructura de carpetas no solo contiene archivos, sino que te dice lo que hace la aplicación. Vale la pena hacer énfasis en la guía de estilo oficial de Angular, ya que sus recomendaciones se basan en años de experiencia comunitaria. Esta filosofía, detallada en su página de referencia de estructura de archivos, a menudo se resume con el acrónimo LIFT (por sus siglas en inglés: Localizar, Identificar, Plano, Tratar de ser DRY):

Locate (Localiza) tu código fácilmente.
Identify (Identifica) lo que hace un archivo de un vistazo.
Flat Flat (Plano): Mantén estructura plana tanto como puedas.
Try to be DRY: Don't Repeat Yourself (Trata de no repetirte).

La conclusión principal es organizar por característica, no por tipo. En lugar de una carpeta components y una carpeta services, crea carpetas para características como user-profile o product-list.

Usemos un ejemplo práctico para una aplicación de comercio electrónico:

src/app/
├── core/
│   ├── auth/          # Lógica de autenticación usada en todas partes
│   │   ├── auth-store.ts
│   │   └── auth-interceptor.ts
│   └── layout/        # El shell de la aplicación: barra de navegación, pie de página
│       ├── navbar.ts
│       └── footer.ts
│
├── features/
│   ├── products/      # Todo para navegar por los productos
│   │   ├── product-list.ts
│   │   ├── product-details.ts
│   │   └── product-search.ts
│   │
│   └── cart/          # La característica del carrito de compras
│       ├── cart-store.ts
│       ├── cart-view.ts
│       └── add-to-cart.ts
│
└── shared/            # Componentes "tontos" reutilizables y utilidades
    └── ui/
        ├── button.ts
        ├── spinner.ts
        └── price.pipe.ts

¿Por qué funciona esto?

core (Proporcionar una vez): Servicios y componentes que la aplicación necesita para ejecutarse, cargados solo una vez (AuthStore, Navbar).
Features (Lo que hace tu aplicación): El corazón de tu aplicación. Cada carpeta es una característica autocontenida.
shared (Bloques de construcción reutilizables): Componentes "tontos", pipes y directivas que no saben nada sobre las características en las que se utilizan (Button, Spinner). Son importados por los módulos de características.

3. La Nueva Convención de Nombres

Angular 20 introduce una nueva convención oficial de nombres que elimina los sufijos tradicionales como .component.ts o .service.ts.

Nomenclatura Antigua	Nueva Nomenclatura	Intención
user-profile.component.ts	user-profile.ts	Componente de Interfaz de Usuario
auth.service.ts	auth-store.ts	Gestión de estado
highlight.directive.ts	highlight.ts	Directiva
user-api.service.ts	user-api.ts	Cliente HTTP

El objetivo es centrarse en la intención del archivo en lugar de su tipo técnico. Una clase que maneja el estado es un "store" (almacén), y una que realiza peticiones HTTP es una "api". Esto hace que el propósito de tu código sea mucho más claro, especialmente en una estructura de carpetas basada en características.

*Parte 4: Las nuevas herramientas y sintaxis *

Finalmente, veamos las nuevas herramientas que mejorarán tu desarrollo diario.

1. El flujo de control es más que syntactic sugar (azúcar sintáctico).

El nuevo bloque @for reemplaza a *ngFor y es una mejora importante.

Sintaxis antigua:

<div *ngFor="let item of items; trackBy: trackItemById">
  {{ item.name }}
</div>

Nueva sintaxis:

@for (item of items; track item.id) {
  <div>{{ item.name }}</div>
} @empty {
  <div>No hay elementos para mostrar.</div>
}

Mejoras clave:

track es obligatorio, lo que impone una mejor práctica de rendimiento que a menudo se olvidaba.
El bloque @empty incorporado limpia las plantillas al eliminar la necesidad de un *ngIf separado.

Puedes usar la CLI para refactorizar automáticamente tus plantillas:

ng generate @angular/core:control-flow

2. Zoneless: Escapando de la "magia de la detección de cambios".

Aunque todavía es experimental, el camino hacia un Angular sin zonas (zoneless) se está volviendo más claro. En un mundo sin zonas, la interfaz de usuario solo se actualiza cuando se lo indicas explícitamente.

Los signals (señales) son la herramienta principal para esto.

mySignal.set(newValue);

Esta línea le indica directamente a Angular que actualice solo las partes específicas del DOM que dependen de esa señal. Es un enfoque quirúrgico, predecible y de alto rendimiento que elimina la sobrecarga y la imprevisibilidad de Zone.js.

Conclusión

Angular 20 es una versión significativa. La actualización requiere intervención manual para las pruebas, pero impulsa el framework hacia un futuro más moderno, explícito y de alto rendimiento. Al adoptar componentes standalone, una arquitectura basada en características y el nuevo flujo de control, no solo estás actualizando, sino que estás preparando tu aplicación para la próxima era del desarrollo web.

Angular's Declarative Shift

Antonio Cardenas — Sun, 19 Oct 2025 08:00:09 +0000

How the New Folder Structure Changes Everything

If you haven't updated to version 20, the first and second parts of this guide can help you understand what's changing and how to update.

Part 1: The Upgrade Itself 🛠️

First, let's get the basics out of the way. Before running any commands, make sure your environment is ready.

Prerequisites

Node.js: v20.11.1 or later.
TypeScript: v5.8 or later.
Project Backup: Make sure you commit all your current changes in Git. Seriously.

The Update Command

Once you've confirmed your Node.js version, run the command that fits your project.

For a standard Angular project:

ng update @angular/cli @angular/core

If you use Angular Material:

ng update @angular/cli @angular/core @angular/material

The update process will run, but you're likely to hit your first roadblock immediately.

Part 2: What Breaks Immediately 🛑

Unlike previous updates, Angular 20 introduces a significant breaking change that will stop your build.

1 The Full Story Behind Karma’s Removal

The first thing you'll notice is that ng test will fail. This isn't just a bug; it's a fundamental change in Angular’s build tools.

With Angular 20, the default build package changes from @angular-devkit/build-angular to the new @angular/build. This new package does not include Karma. The web ecosystem has moved on to faster, more modern test runners like Vitest and Jest, and Karma had become a bottleneck.

The Temporary Fix:

To get your tests running without migrating everything today, you need to manually reinstall the old build tool. This forces the CLI to use the old compiler that still supports Karma.

npm install @angular-devkit/build-angular --save-dev

This is a compatibility bridge. The message from the Angular team is clear: start planning your migration to Jest or Vitest soon.

2. browserslist and Browser Support

Here's a smaller detail that might catch you by surprise. Angular 20 officially no longer supports Opera. If you have "Opera" listed in your .browserslistrc file, your build may fail or throw warnings. Remove it to resolve the issue.

Part 3: The New Architecture 🏛️

Beyond the breaking changes, Angular 20 pushes forward a more modern, explicit, and scalable architecture.

1. Standalone is the Default

New projects generated with ng new are now standalone by default. This marks a fundamental architectural shift away from NgModules. By listing dependencies directly in a component's imports array, each component becomes self-contained.

This change:

Clarifies your architecture: You know exactly what each component needs.
Improves tree-shaking: Leads to smaller, more optimized bundles.

To migrate your existing projects, you can run the standalone migration schematic:

ng generate @angular/core:standalone

2. A Folder Structure That Tells a Story

A good folder structure doesn't just hold files—it tells you what the application does. It's worth mentioning the official Angular style guide, as its recommendations are built on years of community experience. This philosophy, detailed on their file structure reference page, is often summarized by the acronym LIFT:

Locate your code easily.
Identify what a file does at a glance.
Flat structure for as long as you can.
Try to be DRY (Don't Repeat Yourself).

The main takeaway is to organize by feature, not by type. Instead of a components folder and a services folder, you create folders for features like user-profile or product-list.

Let's use a practical example for an e-commerce app:

src/app/
├── core/
│   ├── auth/          # Authentication logic used everywhere
│   │   ├── auth-store.ts
│   │   └── auth-interceptor.ts
│   └── layout/        # The app's shell: navbar, footer
│       ├── navbar.ts
│       └── footer.ts
│  
├── features/
│   ├── products/      # Everything for browsing products
│   │   ├── product-list.ts
│   │   ├── product-details.ts
│   │   └── product-search.ts
│   │  
│   └── cart/          # The shopping cart feature
│       ├── cart-store.ts
│       ├── cart-view.ts
│       └── add-to-cart.ts
│  
└── shared/            # Reusable "dumb" components & utilities
    └── ui/
        ├── button.ts
        ├── spinner.ts
        └── price.pipe.ts

Why This Works:

core 🏛️ (Provide once): Services and components the app needs to run, loaded only once (AuthStore, Navbar).
features ✨ (What your app does): The heart of your application. Each folder is a self-contained feature.
shared ♻️ (Reusable building blocks): "Dumb" components, pipes, and directives that don't know anything about the features they're used in (Button, Spinner). They are imported by feature modules.

3. The New Naming Convention

Angular 20 introduces a new official naming convention that drops traditional suffixes like .component.ts or .service.ts.

Old Naming	New Naming	Intent
user-profile.component.ts	user-profile.ts	UI Component
auth.service.ts	auth-store.ts	State Management
highlight.directive.ts	highlight.ts	Directive
user-api.service.ts	user-api.ts	HTTP Client

The goal is to focus on the file's intent rather than its technical type. A class that handles state is a "store," and one that makes HTTP requests is an "api." This makes your codebase's purpose much clearer, especially in a feature-based folder structure.

Part 4: The New Tools & Syntax 🚀

Finally, let's look at the new tools that will make your day-to-day development better.

1. Control Flow is More Than Syntactic Sugar

The new @for block replaces *ngFor and is a major improvement.

Old Syntax:

<div *ngFor="let item of items; trackBy: trackItemById">
  {{ item.name }}
</div>

New Syntax:

@for (item of items; track item.id) {
  <div>{{ item.name }}</div>
} @empty {
  <div>No items to display.</div>
}

Key improvements:

track is mandatory, enforcing a performance best practice that was often forgotten.
The built-in @empty block cleans up templates by removing the need for a separate *ngIf.

You can use the CLI to automatically refactor your templates:

ng generate @angular/core:control-flow

2. Zoneless: Escaping the "Magic" of Change Detection

While still experimental, the path to a zoneless Angular is becoming clearer. In a zoneless world, the UI only updates when you explicitly tell it to.

Signals are the primary tool for this.

mySignal.set(newValue);

This line directly tells Angular to update only the specific parts of the DOM that depend on that signal. It’s a surgical, predictable, and high-performance approach that eliminates the overhead and unpredictability of Zone.js.

Conclusion

Angular 20 is a significant release. The upgrade requires manual intervention for testing, but it pushes the framework toward a more modern, explicit, and performant future. By embracing standalone components, a feature-based architecture, and the new control flow, you're not just updating—you're preparing your application for the next era of web development.

Happy coding!

Angular 20: De la programación imperativa a la creación declarativa de componentes dinámicos

Antonio Cardenas — Thu, 09 Oct 2025 15:20:49 +0000

Angular 20 llega con nuevas y geniales características y mejoras. Una de las adiciones más significativas es la simplificación de la creación de componentes dinámicos, que la hace mucho más limpia, consistente y predecible. Esta mejora alinea la sintaxis para componentes dinámicos con la forma en que funcionan los "enlaces" (bindings) en las plantillas de componentes.

Anteriormente, la creación de componentes dinámicos se sentía como el complejo proceso de ensamblar una PC personalizada a partir de piezas dispares y manuales: funcional, sí, pero requería que el desarrollador lidiara manualmente con cada cable, cada conexión y cada compatibilidad. Ahora, Angular 20 te da un panel de control unificado.

El laberinto de la construcción manual (Pre-Angular 20)

Antes de Angular 20, trabajar con componentes creados dinámicamente era engorroso. El "enlace de datos bidireccional" (two-way data binding) era muy incómodo, y no existía un estilo unificado para trabajar con "entradas" (inputs) y "salidas" (outputs).

Para configurar un componente dinámico, era como si tuviéramos que conectar cada componente (input) y cable de salida (output) de forma individual y a mano. Para un hipotético NotificationComponent, los pasos manuales e imperativos eran:

Conexión manual de componentes: Se tenía que usar setInput() para conectar cada componente (propiedad) por separado.
Preparación manual de los datos: Si los datos venían de una "señal" (signal), debían ser desenvueltos (acceder a su valor) para obtener el valor real y no la función.
Gestión de las conexiones de salida: Se requería suscribirse manualmente a las salidas (outputs), guardando cada suscripción. Era crucial recordar desconectar estos cables (unsubscribe) para prevenir fugas de memoria.
Sincronización manual de datos: Para que el componente dinámico reaccionara a los cambios en una signal del padre, era necesario un "efecto" (effect) para rastrear el cambio y luego volver a conectar manualmente el cable (setInput) con el nuevo valor.

El código era como un diagrama de cableado muy imperativo y no reactivo:

// Enfoque anterior (Imperativo)

// Paso 1: Conexión básica de la placa madre
const componentRef = this.container().createComponent(NotificationComponent);

// Paso 2: Conexión manual de los componentes y datos
componentRef.setInput('message', 'Alerta de estado');
componentRef.setInput('priority', this.prioritySignal()); // ¡Desenvolver el valor de la signal!

// Paso 3 & 4: Conexión manual de los cables de salida y de sincronización
this.subscriptions.push(
  componentRef.instance.dismissed.subscribe(() => {
    componentRef.destroy(); // Lógica de destrucción manual (desconectar del todo)
  })
);

// Paso 5: Reactividad manual usando efecto
this.subscriptions.push(
  effect(() => {
    // Necesario para que el componente se actualice reactivamente
    componentRef.setInput('priority', this.prioritySignal());
  })
);
// ... Se necesita más código para la sincronización bidireccional y la limpieza de cables.

La forma de acceder a la salida (output) requería acceder directamente a la propiedad de la clase, lo que no respetaba el "alias" de la salida y era diferente de cómo funciona en las plantillas.

El panel de control unificado (Angular 20)

A partir de Angular 20, la configuración de componentes dinámicos se gestiona a través de la nueva propiedad bindings. Este nuevo enfoque es declarativo y reactivo, y su corazón es la "referencia del contenedor de vista" (ViewContainerRef), que actúa como el "socket" principal donde se insertará el nuevo componente.

El poder de `ViewContainerRef`

Una "referencia del contenedor de vista" (ViewContainerRef) es el "socket" en el chasis de tu PC donde se puede instalar una tarjeta de video o de sonido. Permite crear, eliminar o incluso mover "tarjetas" (views) dentro de ese contenedor. Para acceder a él, se puede inyectar con inject() o, para una ubicación específica, usar una referencia de plantilla.

Para controlar la ubicación exacta de tu componente dinámico, puedes añadir un <ng-container> en tu plantilla para definir un lugar de inserción:

<button (click)="createDynamic()">Create Dynamic Component</button>
<ng-container #container></ng-container>

Luego, en el código TypeScript, se accede a esa ubicación específica usando viewChild:

container = viewChild.required("container", { read: ViewContainerRef });

Ahora, la creación del componente dinámico con createComponent se realiza directamente en ese contenedor, asegurando que se renderice en el lugar deseado.

Configuración con `bindings`

La propiedad bindings permite definir "enlaces de entrada" (input), "enlaces de salida" (output) y "enlaces bidireccionales" (two-way bindings) en un estilo unificado. Esto elimina la necesidad de setInput() manuales y de suscripciones.

Aquí está el código completo para un ejemplo práctico, como un DialogComponent, que ahora se conecta con un solo "conector modular":

// Enfoque Angular 20 (Declarativo)

import { Component, inputBinding, outputBinding, viewChild, ViewContainerRef } from '@angular/core';
import { DialogComponent } from './dialog/dialog.component';

@Component({
  selector: 'app-root',
  template: `
    <button (click)="createDynamic()">Create Dynamic Component</button>
    <ng-container #container></ng-container>
  `
})
export class AppComponent {

  container = viewChild.required("container", { read: ViewContainerRef });

  createDynamic() {
    this.container().createComponent(
      DialogComponent,
      {
        bindings: [
          // Conexión del cable de entrada 'isOpen'
          inputBinding("isOpen", () => true),

          // Conexión del cable de entrada 'title'
          inputBinding("title", () => "Hello"),

          // Conexión del cable de salida 'onClose' para que se autodesconecte
          outputBinding("onClose", () => this.container().clear())
        ]
      }
    );
  }
}

La nueva API gestiona automáticamente la limpieza de suscripciones cuando el componente es destruido, eliminando las pesadillas de gestión de memoria y los cables sueltos.

Las tres funciones de enlace en detalle

La API de "enlaces" (bindings) se compone de tres funciones esenciales que deben importarse desde @angular/core.

1. `inputBinding()`

Esta función se utiliza para conectar las "entradas" (inputs) del componente:

Argumento	Propósito	Detalles
Primer Argumento	El nombre de la entrada.	Es el nombre del conector en la tarjeta.
Segundo Argumento	El valor.	Es el valor que se transmite. Puede ser un valor estático (un cable con un valor fijo) o una `signal` (un cable inteligente que transmite actualizaciones).

Cuando se proporciona un signal directamente, inputBinding accede automáticamente al valor de la signal y rastrea reactivamente los cambios, actualizando la entrada del componente sin necesidad de un effect manual.

Ejemplos de inputBinding:

// Entrada estática: el valor no cambia después de la creación
inputBinding('message', () => 'Datos cargados'),

// Entrada dinámica: automáticamente reactiva a los cambios en la signal
inputBinding('priority', this.prioritySignal),

// Entrada calculada: utiliza una función computada (también reactiva)
inputBinding('statusText', () => `Usuario: ${this.currentUser()} - Estado: ${this.systemStatus()}`),

2. `outputBinding()`

Esta función maneja los "eventos de salida" (outputs) emitidos por el componente dinámico.

Argumento	Propósito	Detalles
Primer Argumento	El nombre de la salida.	Es el nombre del cable de salida que emite un evento.
Segundo Argumento	Una función de "devolución de llamada" (`callback`).	Es la lógica que se ejecuta cuando el cable emite un evento.

Se puede especificar el tipo de valor emitido usando un "tipo genérico" (generic type) para mejorar la seguridad de tipos en TypeScript:

// Salida básica: Maneja el evento de cierre
outputBinding('dismissed', () => {
  console.log('Notificación cerrada!');
}),

// Salida con datos y tipado (UserEvent es un tipo genérico)
outputBinding<UserEvent>('userAction', (eventData) => {
  this.handleAction(eventData);
}),

3. `twoWayBinding()`

Esta es la solución simplificada para el "enlace de datos bidireccional" (two-way data binding), reemplazando el cableado manual complejo.

Simplemente se define el nombre de la "entrada modelo" (input model) y se proporciona la signal del componente padre que se desea mantener sincronizada.

// Sincroniza la propiedad 'isUrgent' del componente con 'this.urgentModeSignal' del padre
twoWayBinding('isUrgent', this.urgentModeSignal),

Angular maneja automáticamente la convención de sufijo Change (por ejemplo, isUrgent se empareja con la salida isUrgentChange).

Directivas aplicadas en tiempo de ejecución

Angular 20 también permite añadir componentes o características adicionales (directives) al componente creado dinámicamente. Esto se logra mediante la propiedad directives en la configuración de createComponent.

Para directivas sencillas, se proporciona el nombre del constructor de la directiva. Para directivas más complejas que requieren configuración, se proporciona un objeto que incluye la clave type (el constructor de la directiva) y la propiedad bindings para configurar sus propias entradas.

Ejemplo de directivas de runtime:

Configuraremos un NotificationComponent con una directiva simple (FocusHighlightDirective) y una directiva compleja de la librería Material (SnackbarDirective) para mostrar mensajes de estado al pasar el ratón:

const componentRef = this.container().createComponent(NotificationComponent, {
  bindings: [
    inputBinding('message', () => 'Mueva el ratón para ver más detalles')
  ],
  directives: [
    // Directiva simple sin configuración
    FocusHighlightDirective,

    // Directiva compleja con configuración de entradas
    {
      type: SnackbarDirective, // La clase de la directiva
      bindings: [
        // Configura las entradas de la directiva
        inputBinding('snackbarMessage', () => 'Información extra al hacer hover'),
        inputBinding('snackbarPosition', () => 'right')
      ]
    }
  ]
});

Esta capacidad permite un diseño más modular y una configuración dinámica de la experiencia del usuario.

En resumen, el nuevo enfoque de Angular 20 hace que la creación de componentes dinámicos sea más consistente, limpia y legible, ya que la sintaxis de "enlace" (binding) ahora es idéntica a la de las plantillas de Angular, además de ofrecer reactividad incorporada y gestión simplificada de la memoria. Ahora, en lugar de ensamblar una PC a mano, utilizas un "panel de control" unificado para la configuración y conexión de tus componentes.

Bonus :

stackblitz

Github Repo

DEV Community: Antonio Cardenas

[Boost]

What's New in Taiga UI v5: A Modern Angular UI Kit

[Boost]

Sincronizando mi AGENTS.md

[Boost]

MCP Skills vs MCP Tools: La forma correcta de configurar MCP Server

MCP Skills vs MCP Tools: La forma correcta de configurar MCP Server

El modelo mental

¿Qué es una herramienta MCP?

¿Qué es un skill?

Los desventajas reales

MCP: El Impuesto de Tokens

Skills: El Problema de la Desactualización

Ambos: El problema de selección

Cómo combinarlos

Guía de Decisión Práctica

Mejorando el Flujo de Trabajo

La conclusión

MCP Skills vs MCP Tools: The Right Way to Configure Your Server

MCP Skills vs MCP Tools: What's the Difference and How to Combine Them

The Core Mental Model

What Is an MCP Tool?

What Is a Skill?

The Real Downsides

MCP: The Token Tax

Skills: The Staleness Problem

Both: The Selection Problem

How to Combine Them

The Practical Decision Guide

Improving Your Workflow

The Bottom Line

Angular 20 to 21 Upgrade: The Practical Survival Guide

🚨 The "Stop Everything" Breaking Changes

1. The Karma Extinction Event (Vitest is Default)

2. HttpClient is "Just There"

3. zone.js is Gone (For New Apps)

✨ The New Toys: Features You'll Actually Use

1. Signal Forms (Experimental but Stable)

2. Angular Aria (Developer Preview)

3. Regex in Templates

🛠️ The Upgrade Checklist

Summary

Angular 21 & MCP: The End of "Manual" Migrations?

Angular 21 introduces the Model Context Protocol (MCP) server.

What is MCP? (The "USB Port" for AI)

Setting It Up: 5 Minutes to "Agentic" Angular

1. Initialize the Server

2. Connect Your Editor (e.g., Cursor)

Available Tools

Experimental Tools

The "Killer App": Context-Aware Migrations

Tool 1: get_best_practices

Tool 2: onpush_zoneless_migration

Tool 3: search_documentation

Real-World Scenario: The "Legacy" Cleanup

The Future: Continuous Maintenance

Summary: Don't Upgrade Alone

Actualizando a Angular 21 usando ng mcp

¿Qué es MCP? (El "puerto USB" para la IA)

Configuración: 5 minutos para un Angular "agéntico"

1. Inicializar el servidor.

2. Conectar tu editor (por ejemplo, Cursor).

Herramientas disponibles

Herramientas experimentales

La "killer app": Migraciones conscientes del contexto

Herramienta 1: get_best_practices

Herramienta 2: onpush_zoneless_migration

Herramienta 3: search_documentation

Escenario del mundo real: La limpieza "Legacy"

El futuro: Mantenimiento continuo

Resumen: No actualices solo.

Migrando Angular 20 a 21: Guía.

Lo crítico que detienen todo

1. El Evento de Extinción de Karma (Vitest es el predeterminado)

2. HttpClient está "simplemente ahí".

3. zone.js se ha ido (para nuevas apps).

✨ Las nuevas características

1. Signal Forms (Experimental pero estable)

2. Angular Aria (Developer Preview)

Tool 1: `get_best_practices`

Tool 2: `onpush_zoneless_migration`

Tool 3: `search_documentation`

Herramienta 1: `get_best_practices`

Herramienta 2: `onpush_zoneless_migration`

Herramienta 3: `search_documentation`

El poder de `ViewContainerRef`

Configuración con `bindings`

1. `inputBinding()`

2. `outputBinding()`

3. `twoWayBinding()`