DEV Community: Brandon Roberts

AnalogJS 2.7: Server Functions, Streaming SSR, Agent-Ready Projects, and more!

Brandon Roberts — Wed, 12 Aug 2026 14:20:24 +0000

We are excited to announce the release of Analog 2.7! This release introduces Server Functions, typed and validated server operations you call like regular functions, along with experimental progressive Streaming SSR, agent-ready project scaffolding with a conformant Agent Plugin, and new strictness options for testing. Let's dive in.

Server Functions 🚀

The headline feature of Analog 2.7 is Server Functions: typed, validated operations that run on the server and are called from anywhere in your app (a component, an effect, a route resolver) with full type inference on both ends. They are defined in a .server.ts file, so their code and dependencies never reach the browser bundle.

Where load fetches data for one page and action handles one form post, a server function is an arbitrary operation you can call by name.

Defining a Server Function

Server functions are defined with serverFn from @analogjs/router/server in any .server.ts file under src:

// src/app/server-fns/products.server.ts
import { serverFn } from '@analogjs/router/server';
import { inject } from '@angular/core';
import * as v from 'valibot';

import { CatalogService } from './catalog.service';

// A handler alone is an input-less read, served over GET.
export const getProducts = serverFn(async () => {
  return inject(CatalogService).list();
});

// A validation schema in front of the handler declares validated input, served over POST.
export const getProduct = serverFn(
  v.object({ id: v.string() }),
  async (input) => {
    return inject(CatalogService).find(input.id);
  },
);

The input schema is any Standard Schema validator: valibot, zod, and arktype all conform. It runs on the server before the handler, and invalid input is rejected without the handler ever running.

Notice the inject() call at the top of the handler. Server function handlers run inside the same request injector Analog builds for server-side rendering, bootstrapped from your app.config.server.ts, so providedIn: 'root' services just work, and request tokens like REQUEST, RESPONSE, and BASE_URL are available with no extra registration.

Calling a Server Function

Import the same exported function in a component and read it with injectServerFn, which returns an Angular resource:

// src/app/pages/products.page.ts
import { Component, input } from '@angular/core';
import { injectServerFn } from '@analogjs/router';

import { getProduct } from '../server-fns/products.server';

@Component({
  template: `
    @if (product.value(); as p) {
      <h2>{{ p.name }}</h2>
    } @else if (product.error()) {
      <p>Could not load this product.</p>
    } @else {
      <p>Loading…</p>
    }
  `,
})
export default class ProductCard {
  id = input.required<string>();

  protected product = injectServerFn(getProduct, () => ({ id: this.id() }));
}

The args factory is reactive: the resource refetches whenever a signal it reads changes. For writes, injectServerFnMutation returns a callable you can await:

import { injectServerFnMutation } from '@analogjs/router';

export default class Checkout {
  private placeOrder = injectServerFnMutation(placeOrderFn);

  async submit(sku: string, qty: number) {
    const { orderId } = await this.placeOrder({ sku, qty });
  }
}

Both helpers dispatch through HttpClient, so your existing HttpInterceptorFns apply and HttpTestingController works in tests. During server-side rendering, calls skip HTTP entirely and run in-process, and a read resolved on the server is transferred to the client so the browser doesn't refetch on hydration.

Interceptors

Server-side interceptors are functional, provided through DI, and apply to every server function, the same model as HttpInterceptorFn. Use them for authentication, tenancy, and logging:

// src/app/server-fns/auth.interceptor.ts
import type { ServerFnInterceptorFn } from '@analogjs/router/server';
import { fail } from '@analogjs/router/server/actions';
import { inject } from '@angular/core';

export const authInterceptor: ServerFnInterceptorFn = (ctx, next) => {
  const session = inject(SessionService);

  if (!session.user()) {
    return fail(401, { message: 'unauthenticated' });
  }

  return next(ctx.with({ user: session.user() }));
};

// src/app/app.config.server.ts
import { mergeApplicationConfig } from '@angular/core';
import { provideServerRendering } from '@angular/platform-server';
import {
  provideServerFns,
  withServerFnInterceptors,
} from '@analogjs/router/server';

import { appConfig } from './app.config';
import { authInterceptor } from './server-fns/auth.interceptor';

export const config = mergeApplicationConfig(appConfig, {
  providers: [
    provideServerRendering(),
    provideServerFns(withServerFnInterceptors([authInterceptor])),
  ],
});

Security by default

Server functions are HTTP endpoints, and Analog treats them that way. Route ids are derived at build time from the file and export name and served from an opaque /_analog/fn/<hash> route, so the endpoint surface can't be enumerated by guessing export names. Calls are same-origin by default, and cross-origin browser calls are rejected with a 403 before the function is even looked up. If you genuinely need cross-origin access, opt in explicitly with withAllowedOrigins([...]).

Server functions require Angular v19 or higher, as the client half is built on resource(). Check out the Server Functions docs for the full guide, including error handling with fail and redirect.

Streaming SSR (experimental) 🌊

Analog 2.7 introduces experimental support for progressive streaming server-side rendering, flushing the response to the browser as the app renders instead of buffering the whole document until it is complete.

The document head is sent immediately, each @defer (hydrate …) block is sent the moment it resolves on the server, and the authoritative document arrives last, so a slow block never holds back the rest of the page.

Enable the experimental.streaming option in your Vite config:

// vite.config.ts
import analog from '@analogjs/platform';
import { defineConfig } from 'vite';

export default defineConfig({
  plugins: [analog({ experimental: { streaming: true } })],
});

Then use renderStream instead of render in main.server.ts:

// src/main.server.ts
import { renderStream } from '@analogjs/router/server';
import { config } from './app/app.config.server';
import { AppComponent } from './app/app.component';

export default renderStream(AppComponent, config);

Streaming builds on incremental hydration, so enable it in your client providers with provideClientHydration(withIncrementalHydration()). Content that should stream progressively goes in a @defer block with a hydrate trigger:

<h1>Dashboard</h1>

@defer (hydrate on immediate) {
  <app-activity-feed />
} @placeholder {
  <p>Loading activity…</p>
}

@defer (hydrate on viewport) {
  <app-recommendations />
} @placeholder {
  <p>Loading recommendations…</p>
}

A few details worth calling out:

A title or meta set during render is applied to the streamed document once the render completes, before hydration runs.
Search engine crawlers are served a buffered render with a fully resolved head instead of the streamed shell.
Individual routes can fall back to buffered rendering with a streaming: false route rule, the same way ssr: false disables SSR.

Streaming SSR is opt-in, requires Angular v21 or later, and the default buffered SSR path is unchanged. See the Streaming SSR docs for details.

Agent-Ready Projects 🤖

AI coding agents are part of many workflows now, and agents write better Analog code when they're given current framework conventions instead of guessing from training data. Analog 2.7 wires that context in from the start.

New projects scaffolded with create-analog and the Nx preset now include an AGENTS.md and a CLAUDE.md at the workspace root. Rather than freezing guidance into each scaffold, these are thin references pointing to a canonical AGENTS.md that ships inside @analogjs/platform, covering file-based routing, server/API routes, data fetching, and content loading. That way the guidance your agent reads always matches the version of Analog you have installed.

The @analogjs/platform package also now ships an Agent Plugins v1.0.0 conformant plugin: a plugin.json manifest and an Analog skill that expose the same guidance in a structured, machine-discoverable form for agent tooling that supports the spec.

Check out the AI integrations guide for how to point your tools at it.

Stricter Template Checking in Tests ✅

setupTestBed from @analogjs/vitest-angular picks up two new options that forward to TestBed.initTestEnvironment:

setupTestBed({
  errorOnUnknownElements: true,
  errorOnUnknownProperties: true,
});

By default, unknown elements and property bindings in templates only log warnings during tests. Opting in turns those NG8001/NG8002 diagnostics into thrown errors, so a typo'd selector fails the test instead of scrolling past in the console. Both options default to false, so existing test suites are unaffected.

Upgrading

To upgrade to Analog 2.7, run:

ng update @analogjs/platform@latest

If you're using Nx, run:

nx migrate @analogjs/platform@latest

For the full list of changes, see the changelog.

Partner with Analog 🤝

Continued development of Analog would not be possible without our partners and community. Thanks to our official deployment partner Zerops, code review partner CodeRabbit, and longtime supporters Snyder Technologies and Nx, and many other backers of the project.

Find out more information on our partnership opportunities or reach out directly to partnerships[at]analogjs.org.

Join the Community 🥇

Visit and Star the GitHub Repo
Join the Discord
Follow us on Twitter

If you enjoyed this post, click the ❤️ so other people will see it. Follow AnalogJS and Brandon Roberts on Bluesky, and subscribe to my YouTube Channel for more content!

Choosing Angular in the Age of Agents

Brandon Roberts — Thu, 30 Jul 2026 19:53:49 +0000

I see the some version of "Is Angular still worth picking?" every so often, and for years my answer came with a lot of qualifiers. It depends on your team. It depends on how long the app has to live. It depends on how much you like RxJS.

That question feels different now. A meaningful amount of code is being written by agents, and the things that make a framework pleasant to type by hand are not the same things that make it safe to generate. I've been thinking about which of Angular's tradeoffs got better in that world and which ones got worse. The short version is that Angular became the safest mainstream option for agentic engineering and vibe coding, and it got there by doing what it always did rather than by chasing the moment.

Where Angular Actually Sat

Let's be honest about the starting point, because the AI part of this only makes sense if we are.

Angular was not the framework people reached for on a weekend. React won mindshare years ago and never really gave it back. Stack Overflow's 2025 survey put React at 44.7% among professional developers, Angular at 18.2%, Vue at 17.6%. State of JS 2025 noted that for all the talk of churn, the usage rankings barely moved. Angular has not been the dominant choice for a long time, but it has stayed a substantial and durable one.

The reasons are not mysterious. The AngularJS to Angular 2 rewrite burned a lot of goodwill and it took a decade for people to stop bringing it up. NgModules meant that adding a component involved editing a second file for no benefit you could explain to a newcomer. RxJS was everywhere, including in places where a plain value would have done, and the learning curve was steep enough that "I have to learn Angular and also learn reactive programming" was a real barrier. Templates had their own dialect. The CLI generated a lot of files. Builds got slow as apps got big, which I measured on a large real app recently and found was mostly the type-checker's fault, not the bundler's.

Underneath all of that was a coherent bet: optimize for large teams and long timelines, even when that costs you the first-week experience. Angular chose the boring, consistent, verbose thing on purpose. If you were one person shipping a prototype, you paid the cost and got very little of the benefit, and you noticed.

The last few years cleaned up a lot of the surface complaints. Standalone components killed NgModules. Signals gave you reactivity without needing to know what a switchMap is. Built-in control flow replaced the structural directives. Zoneless went stable. angular.dev is genuinely good documentation. Angular v22 deprecated the Webpack builder in favor of the stable esbuild and Vite builder. The framework people complain about is often the one they last used in 2019.

But cleaning up the surface didn't change the underlying bet, and that bet is the part that got interesting.

The Thing Angular Was Always Good At

Angular's actual differentiator was never templates or DI syntax. It was how much of your application Angular tries to verify before it will build.

Strict template type-checking is the big one. Angular generates a type-check block for every template, so {{ user.nmae }} is a build error, a value bound to an input() of the wrong type is a build error, and a directive you forgot to import is a build error. Not a blank spot on the page in staging. A failed build.

This is not free. When I benchmarked a real Angular app with hundreds of components four different ways, the whole-program type-check on its own was about 15 seconds, roughly as long as an entire type-check-free build. That cost is the price of the guarantee, and for most of Angular's life it was a cost people resented without ever really crediting the thing they were buying.

Dependency injection does something similar for wiring. It's declared, typed, and resolvable statically, which means a missing provider is a known failure with a known message instead of an undefined value that surfaces three components deep. HttpClient is typed. The Router is typed. The CLI generates code that already fits the shape the compiler expects.

The production-ready Signal Forms API is the clearest recent expression of that philosophy. Validation is declared as data, in one place, against a typed model:

import { Component, signal } from '@angular/core';
import { form, FormField, required, email, minLength } from '@angular/forms/signals';

interface LoginData {
  email: string;
  password: string;
}

@Component({
  selector: 'app-login',
  imports: [FormField],
  template: `
    <input type="email" [formField]="loginForm.email" />
    <input type="password" [formField]="loginForm.password" />
  `,
})
export class LoginComponent {
  loginModel = signal<LoginData>({ email: '', password: '' });

  loginForm = form(this.loginModel, (schemaPath) => {
    required(schemaPath.email, { message: 'Email is required' });
    email(schemaPath.email, { message: 'Enter a valid email address' });
    required(schemaPath.password, { message: 'Password is required' });
    minLength(schemaPath.password, 8, { message: 'Minimum 8 characters' });
  });
}

schemaPath.email isn't a string key that gets looked up at runtime. Rename the field on LoginData and this stops compiling. There's also validateStandardSchema, which takes a Zod or Valibot schema directly, so if you already validate the same payload on the server you can share the schema instead of writing the rules twice.

That's the pattern across the whole framework: say what's true, let the compiler check it, fail at build time.

Why That Matters More With Agents

An agent writing code needs two things you don't think about when you're writing it yourself: a narrow space of correct answers, and a fast way to find out it was wrong.

Angular gives it both, and not by accident. A framework built so that a large team can safely change code it didn't write, and get told immediately when it gets that wrong, is already most of the way to a framework an agent can work in. The audience changed. The requirement didn't.

The narrow space comes from having a much smaller set of officially supported choices. One router. One DI system. One HTTP client. One project layout that ng generate produces. When a model writes an Angular component it isn't choosing between four routers and three data-fetching libraries that are all correct and all well represented in its training data. Ecosystem fragmentation is great for developers who have opinions and rough on a generator that has to guess which stack this particular repo committed to. Angular's rigidity used to be the complaint. With an agent driving, it's leverage.

The fast feedback comes from the type-checker. An agent that hallucinates an input name, binds the wrong type, or forgets to add a component to imports finds out from ng build, in a message that names the file and line. That's a loop it can close by itself. The failure mode I actually worry about with generated code is the plausible-looking thing that runs and is subtly wrong, and template type-checking eats a whole category of exactly that. That 15-second cost buys an automated reviewer that never gets tired.

Angular's decade of changing conventions creates the opposite problem: its training data contains several incompatible eras. Ask for a component and you'll still get NgModule declarations, constructor injection, *ngIf, and a manual subscribe in ngOnInit, all of which work and none of which is how you'd write it today. More than with other frameworks I use, I have to tell the model which era of Angular to target. That's a real tax, and it's the tax Angular is now paying down with tooling rather than hoping models catch up.

Vibe Coders Building Safely

Everything above assumes you're reading the code. Plenty of people aren't right now, at least not closely, and I don't think that's automatically a bad way to work. It does change what you should want from a framework.

If you aren't reading closely, the question stops being how nice the code is to write. It becomes what the framework refuses to let through. The bug you can't catch by skimming is the one that only shows up on a page you didn't click, and Angular turns a lot of those into a failed build instead. A failed build is hard to ignore.

So the advice is boring: run the build, and run it often. It's the cheapest review you have. Angular publishes a setup for AI editors that points your agent at the current docs and lets it read its own build errors, and it's worth the few minutes it takes.

Set that up, because the model's idea of Angular is a few years out of date. It will write things the old way, that code still works, and nothing warns you. You find out much later, when you add something modern and the two styles don't fit together. Tell it which version you're on, and ask for signals and standalone components by name.

A passing build means your code holds together, not that it does what you wanted. The compiler catches the typo, never the wrong feature. Building the right thing is still your job.

That's a trade I'd take. Every framework lets you vibe. Angular is the one checking your work while you do it.

What the Roadmap Says

The Angular roadmap is unusually direct about this. It lists three goals for the framework, and the first one is improving the AI experience for developers. Then developer experience, then performance.

Most of that already exists. The editor setup I mentioned above is built on an MCP server that ships in the CLI and a set of official agent skills, and there's an AI tutor and WebMCP to experiment with alongside them. The roadmap also commits to evaluating code generation quality and changing the framework itself where that improves it. "We'll change APIs so models generate better code" is a different posture than "we'll write better docs."

The performance work matters for the same loop. The team is prototyping compatibility with Microsoft's TypeScript port to Go, which the roadmap describes as a 5 to 10 times speedup for typical TypeScript compilation. Angular's compiler wraps the TypeScript program directly, so when the solution lands for template type-checking, the expensive guarantee gets a lot cheaper. Even a fraction of that number changes how often you're willing to run a full check.

So Should You Choose Angular?

If you're building something that has to survive team turnover, if you want validation rules in one typed place instead of scattered through components, if you'd rather a mistake in a template be a failed build than a support ticket, Angular's tradeoffs make more sense today than they did five years ago. You didn't have to change your mind about anything. The cost of ceremony went down when signals and standalone components landed, and the value of enforced correctness went up when a machine started writing the first draft.

If you're already fast in another ecosystem and you read everything you ship, none of this is an argument to switch. It never was.

"AI likes it" is a depressing pitch for a framework, and it isn't the pitch. Angular spent a decade making the compiler prove things about your code and took real criticism for what that cost. That was a deliberate bet on correctness over convenience, made by people who were solving for large teams and long-lived code, not for agents. It's the same bet either way. Angular was built for codebases where no one person could review every change, and agent-generated code is that same problem arriving faster.

So if you're going to let a machine write most of it, write it somewhere that argues back. That's the case for Angular right now. Not that it makes you faster, but that it makes being fast less dangerous.

If you enjoyed this post, click the ❤️ so other people will see it. Follow AnalogJS and Brandon Roberts on Bluesky!

Distributing AnalogJS CI with Nx Agents and One Prompt

Brandon Roberts — Wed, 01 Jul 2026 15:44:59 +0000

AnalogJS has been an Nx monorepo since its very first commit, back in July 2022 — so for nearly four years the build tool has known the full dependency graph between every package and app. CI, though, never used any of that. It was six GitHub Actions jobs running mostly in series, each one checking out the repo and re-installing the world before it could do any real work. The workflow had grown into that job-per-concern shape over those years, and once it worked, nobody had a reason to revisit it.

I'd been meaning to move it onto Nx Agents for a while. What finally made me do it was getting a little shamed by a post from Altan Stalker — a pointed argument that CI pipelines exactly like mine reinvent a build graph the tool already has. Mine did, so I tried something: hand the whole migration to my coding agent from a single prompt and see how far careful analysis — not clever YAML — would get.

The short version is that it got the whole way. The more interesting part was watching why it made the choices it did.

The starting point

The old ci.yml had a job per concern — prettier, lint, build, build-windows, unit, and e2e. Every Linux job opened with the same boilerplate:

- uses: actions/checkout@v3
- uses: actions/setup-node@v3
- run: corepack enable
- run: pnpm install --frozen-lockfile --prefer-offline

Then e2e was hand-gated behind build with needs: build. That needs: edge is the heart of what Altan calls out: CI was re-encoding a dependency graph the build tool already knows. And stage gating has a quieter cost — when build fails, e2e is skipped, so you don't even find out whether e2e would have passed until the next push. Six runners, duplicated setup, serial --parallel=1 steps, and dead time between the stages.

One prompt

The prompt I gave my coding agent was deliberately about behavior, not YAML: analyze the existing CI and produce a correct, conservative Nx Agents setup based on the pipeline's real commands, dependencies, secrets, and execution behavior. Then I let it do the analysis itself. A few things it did stood out, because they're the things I'd want a careful human to do:

It read the real pipeline, not an idealized one — ci.yml, the package.json scripts each job actually invoked, nx.json targetDefaults, .node-version, and the package-manager pin.
It generated the Nx task graph (nx run-many -t build test e2e lint --graph) and inspected the edges to prove that test and e2e already depend on build — for example, storybook-angular:test → vite-plugin-angular:build. That evidence is what justified deleting the needs: build gate: Nx schedules the ordering, so CI doesn't have to.
It refused to over-consolidate. Each target has a distinct project filter — lint excludes content,platform,router, build excludes astro-app, e2e is limited to two projects. A single run-many can't express those, so the commands stayed separate. Correctness over a tidier diff.
It translated constraints, not bottlenecks. The old --parallel=1 limits became per-agent task concurrency rather than global serialization, because the constrained resource — memory, browser ports — is local to a machine, and each agent is its own machine.

That last distinction is the one I most expected it to get wrong, and the one that matters most. An old single-runner --parallel=1 is easy to misread as "this must never run concurrently anywhere." Usually it just means "this machine only has so much RAM."

The result

CI is now a single coordinator job that starts a distributed run and hands the cacheable Nx work to agents:

- name: Start CI run
  run: >
    pnpm exec nx-cloud start-ci-run
    --distribute-on="3 analog-linux"
    --require-explicit-completion
    --stop-agents-after="e2e"

A new .nx/workflows/agents.yaml defines one analog-linux agent template — Node pinned from .node-version, corepack and pnpm, Playwright and Cypress browsers — so any agent can pick up a lint, build, test, or e2e task. The build-windows smoke build stays a native runner job; it needs a separate OS plane, and the agent left it alone.

The payoff is on the part I changed. On the first run — cold cache, agents starting from scratch — the Linux pipeline dropped from about 10 minutes to 7 and a half, just from letting the graph schedule across agents instead of chaining build → e2e in YAML. It should keep dropping as the Nx Cloud cache warms up.

That left one long pole: the Windows smoke build, still around 12 minutes. It was rebuilding all 20 projects, one at a time, just to verify a single app's output. So I scoped it to that app — nx build blog-app, the six tasks it actually needs — and moved the full Windows build to a nightly run. It dropped from ~12 minutes to under 4. Time to green went from ~12 minutes to about 7 and a half.

Conclusion

Let the build tool own the graph. Nx already knows test depends on build. Restating that in YAML just keeps the same fact in two places, and only one of them is checked.

The rest was separating meaning from shape. Old job boundaries and --parallel numbers tell you how the last setup happened to work, not what the next one has to keep. And the analysis — read the scripts, generate the task graph, decide what not to merge — turned out to be the part worth handing off. Point a tool at the real pipeline instead of a mental model of it, and it does that part well. That's the part to lean on.

If you enjoyed this post, click the ❤️ so other people will see it. Follow AnalogJS and Brandon Roberts on Bluesky, and subscribe to my YouTube Channel for more content!

Angular Compilation, Type-Checking, and Build Bottlenecks

Brandon Roberts — Fri, 26 Jun 2026 14:22:09 +0000

Angular application builds aren't inherently slow — for a small or medium app you rarely think about them. But the compiler does its heaviest work whole-program, so build time grows with the size of your codebase, and at scale it becomes a real bottleneck. To find out where that time actually goes, I built a large, real-world Angular app — hundreds of components — four different ways and measured each. More of it goes to type-checking than most people expect.

How Angular compilation works

When you build an Angular app ahead-of-time, the compiler (ngtsc) does two jobs at once:

Template compilation (AOT) — every component template is parsed and lowered to Ivy instructions (ɵɵelement, ɵɵproperty, ɵɵtemplate, …) emitted into the component's definition.
Type-checking — your TypeScript is type-checked, and so are your templates. Angular generates a "type-check block" for each template so that a typo like {{ user.nmae }}, or a value bound to an input() of the wrong type, is a compile error.

The second job is the expensive one, and it's expensive for a structural reason: it's whole-program. To type-check a template, the compiler needs the resolved types of every directive, component, and pipe that template uses — their inputs, outputs, and generic signatures.

A standalone component lists those dependencies in its imports, but the types themselves live in other files and in third-party libraries. So the compiler can't work one file at a time. It builds and holds the whole program in memory and reasons across it.

That whole-program requirement is what makes Angular builds hard to parallelize and hard to cache at file granularity. It's also what the fast per-file compilers deliberately give up.

Four pipelines, two architectures

I built the app four ways. They split cleanly into two camps: whole-program AOT (the classic Angular compiler, however it's bundled) and per-file transpile (emit Ivy a file at a time, skip type-checking). Understanding the architecture is the whole point — it's what predicts the numbers.

Webpack + `@ngtools/webpack` (whole-program AOT, legacy)

The app's own production build, and the classic Angular CLI architecture. @ngtools/webpack's AngularWebpackPlugin owns a single ngtsc program for the entire application — Angular's NgtscProgram wrapping one TypeScript Program.

The plugin intercepts every .ts file, but the unit of work is the program, not the file: ngtsc runs AOT template compilation and full type-checking (TypeScript plus generated template type-check blocks) across the whole graph. Webpack then bundles the emitted JS. One single-threaded compile pass over everything, then Webpack's module graph and Terser.

Webpack-based compilation is deprecated as of Angular v22 — the modern default is the esbuild/Vite application builder — so treat it as the legacy baseline. Worth noting, though: the new default builder swaps the bundler (esbuild/Vite for Webpack), not the compiler. It still drives the same whole-program ngtsc with the same type-checking, which is exactly why the next one matters.

Angular application builder (whole-program AOT, esbuild — the modern default)

This is what ng build runs today: the @angular/build:application builder. It uses esbuild for transpilation and bundling, with the Angular compiler plugin handling AOT and type-checking, plus a persistent on-disk cache. Crucially it's the same ngtsc — the same whole-program NgtscProgram, the same AOT codegen and strict template type-checking — as the Webpack path. Only the bundler changed (esbuild for Webpack), which is exactly the point: set against Webpack, it shows what the bundler swap bought; set against the per-file pipelines below, it shows what the whole-program type-check costs.

AnalogJS fastCompile (per-file transpile)

Introduced in AnalogJS 2.5, fastCompile is a per-file, transpile-only compiler written in TypeScript — no NgtscProgram, no type-checking. For each file it finds the @Component / @Directive / @Pipe / @Service / @NgModule decorators, builds the R3 metadata, and calls @angular/compiler's public R3 emit APIs (compileComponentFromMetadata, etc.) to produce the same Ivy definitions the AOT compiler would (ɵcmp, ɵfac, ɵprov, ɵmod, …).

It still needs cross-file information — which directive a selector maps to, what a library module exports — but that comes from a lightweight registry, built once by scanning the project and reading library .d.ts files, not from a type-checker. Every file compiles independently, so the work parallelizes and caches per file.

Oxc Angular Compiler (experimental, Rust — per-file transpile)

The same per-file idea, but written in Rust on the Oxc toolchain — its Rust TypeScript parser, AST, and arena allocator. The Oxc Angular Compiler parses each file natively, lowers templates to an Ivy/R3 instruction IR through a pipeline of phases (binding specialization, sanitizer resolution, constant pooling, …), and emits the Ivy definitions in native code, with no Node or TypeScript in the hot path.

It reaches the build through a napi binding and a thin Vite plugin. Like fastCompile it skips type-checking and resolves cross-file scope from a registry; the difference is doing the parse and codegen in Rust instead of TypeScript.

To set expectations: the Oxc Angular Compiler is a research project — a way to explore what native Angular compilation could look like, not a supported tool or a roadmap item. Separately, the Angular team is running its own investigation into how Oxc could fit into Angular's tooling. I'm including the compiler here because it's a useful data point for where the codegen ceiling might be, not as something to adopt today.

All four ran on the same machine, same app, as cold production builds, each producing a bundle that boots. ("Boots" is a deliberately low bar — more on that below.)

The numbers

One caveat before the chart, because it matters: the two per-file pipelines skip type-checking, so they aren't doing the same work as the AOT ones and the raw totals aren't apples-to-apples. The chart marks which pipelines type-check (orange) and which don't (green); treat that as part of the number — we'll reconcile it at the end.

The dashed bar is the reference point: type-checking the app on its own — ngc --noEmit with strictTemplates, no codegen, no bundling — takes about 15 seconds, as long as an entire per-file build.

These are cold, production builds, the kind CI runs. The application builder keeps a persistent cache, but it barely moved the full production number here — a clean rebuild came within a second of a cold one. Caching helps incremental dev rebuilds far more than a from-scratch production build, so read this as the CI story, not the ng serve story.

A few things stand out.

The bundler helped, but it's not where the headroom is. Webpack (~49s) → the esbuild application builder (~36s) is a real improvement, and it's the move Angular itself made by deprecating the Webpack builder in v22. The modern default is solid — it's just not the fastest option here. It's the same ngtsc underneath, and the per-file pipelines still come in 2.5–5× faster, so the remaining headroom isn't in the bundler; it's in the compiler.

Type-checking is a large, separable cost. ngc --noEmit puts a number on it: the whole-program type-check alone is ~15s — about as long as the entire fastCompile build (~14.5s), and roughly twice the Oxc Angular Compiler build (~7.7s). The per-file compilers do everything the AOT compilers do except that whole-program analysis, and that single omission is most of why they're fast. (They also lean on a faster bundler — Vite and rolldown rather than esbuild — so the totals mix two effects; ngc is what cleanly isolates the type-check.)

The expensive half was never the codegen. Turning templates into Ivy instructions is cheap and trivially parallel — that's exactly what the per-file compilers demonstrate. The costly part has always been proving the templates are correct. Of the modern builder's ~36s, roughly 15 is type-checking and the rest is codegen, bundling, and optimization — and the type-check is the biggest of those pieces, and the only one that produces no output, just a pass or a fail.

(This is a comparison of compile speed, not bundle size; the outputs are broadly comparable.)

What per-file compilers still need

Skipping type-checking is the easy part. The subtler problem is that a per-file compiler, by definition, can't see other files — yet to compile a template it still needs the selectors (and input/output names) of every directive and component that template uses, and those are declared elsewhere.

In a standalone app this is tractable. A component lists its dependencies in imports, so the compiler already knows which classes a template can match; it just has to resolve their metadata from the files — or library .d.ts — where they're defined. The per-file compilers do this with a lightweight registry, scanned once from the project and its type declarations, instead of a whole-program type-checker. Only the directives a template actually references get inlined into its definition, so the output matches what ngtsc would emit.

That's a much smaller problem than type-checking — selector resolution, not full type inference — and it doesn't require holding the whole program in memory. (Older NgModule-based code needs a little more bookkeeping, since a component's dependencies come from its declaring module rather than its own file, but the same registry resolves them.)

And the fairness note in the other direction: "it boots" is not "it's correct." Skipping type-checking means template mistakes the normal build would reject slip through to runtime — that's the explicit trade, and it's why you still run the type-check, just elsewhere. These compilers are also young: matching the full AOT compiler across every Angular feature — control flow, @defer, queries, animations, i18n, host bindings, content projection — is a long tail that both projects are still working through. The point here is the shape of the cost, not a suggestion to swap your production compiler today.

What the gap comes down to

Line the numbers up and the shape is clear. The type-check (ngc --noEmit, ~15s) is its own large, self-contained cost — as long as an entire fastCompile build, twice the Oxc one. The per-file compilers are fast precisely because they don't do it; the AOT builders take longer precisely because they do, as part of the build.

So the distance between ~7–14s and ~36s isn't really about codegen, or even the bundler — it's that one set of tools runs a whole-program type-check on every build and the other doesn't. That's the same analysis your editor runs as you type and your CI runs on every push; ngc --noEmit does it standalone in ~15s. Most of what we call an Angular build's "compile" time is the work of proving the templates are correct, not producing the code.

Conclusion

At scale, most of an Angular build's time is the type-check — not the codegen, and not the bundler. A faster bundler helps, but it can't touch that cost; the per-file compilers are fast because they skip the check entirely.

Turning templates into Ivy was never the expensive part. Proving they're correct is — about 15 seconds of it, on this app, separable from everything else the build does.

Looking ahead: a native type-checker

Of the two halves of the work, type-checking is the larger — ~15s against the ~8s a per-file compiler needs to emit code. So even setting the bundler aside, the type-check is where the real time is, and it's the part poised to get faster.

That part should get much faster, eventually. The TypeScript team is porting the compiler to Go — shipping as TypeScript 7 — targeting a roughly 10× speedup in type-checking and project load. Angular's compiler is built directly on the TypeScript compiler API: ngtsc wraps a ts.Program and generates its template type-check blocks into it. So in principle, as the native compiler's API lands, Angular's type-checking could ride on top of it.

I'd hedge that, though. Angular's template type-checking leans on a lot of TypeScript's compiler surface, some of it internal, and the Go port exposing what ngtsc needs is a real undertaking, not a flag flip. The 10× is also TypeScript's headline for tsc itself; Angular's template checking sits on top and may not see the same multiple. Even a fraction of it, though, would take that ~15s ngc --noEmit down meaningfully.

Codegen is already cheap — fastCompile and the Oxc experiment both show how low it goes. A native type-checker is what would make the other half cheap too. That's the part to watch.

If you enjoyed this post, click the ❤️ so other people will see it. Follow AnalogJS and Brandon Roberts on Bluesky, and subscribe to my YouTube Channel for more content!

Deploying Angular applications to Cloudflare with Void

Brandon Roberts — Wed, 20 May 2026 13:30:15 +0000

Angular is a web framework for building scalable applications, with a powerful CLI, signals-based reactivity, and a batteries-included approach to routing, forms, and testing.

Void is a Vite plugin and deployment platform built on Cloudflare. It deploys your app to Cloudflare's global edge network with a single command — no Cloudflare account required.

This guide shows how to create a new Angular application or add to an existing one and deploy it to Void as a single-page app.

Void is still in private beta currently, but will open up for public beta in the future. Visit https://void.cloud for more info on availability.

Creating a new Angular application

To create a new project, generate it with the Angular CLI:

npx @angular/cli new angular-void

The CLI asks a few setup questions. When prompted for Server-Side Rendering (SSR) and Static Site Generation (SSG/Prerendering), answer No — Void deploys the build as a static SPA, so a client-only app keeps the setup simple.

Once the project is generated, move into it:

cd angular-void

For an existing project, skip this step and go straight to installing Void.

Installing Void

Install the Void CLI as a dev dependency using your package manager of choice:

npm install -D void

Angular doesn't expose Vite directly — the Angular CLI owns its own build pipeline — so there's no vite.config.ts to add voidPlugin() to. Instead, you point Void at the Angular build through a small config file, and keep developing with the Angular CLI as usual:

npm start

Configuring the build for Void

Void deploys the output of your build command. Add a void.json at the project root telling Void this is a SPA, how to build it, and where the build output lands:

{
  "$schema": "./node_modules/void/schema.json",
  "output": "static",
  "inference": {
    "appType": "spa",
    "build": "npm run build",
    "outputDir": "dist/angular-void/browser"
  },
  "worker": {
    "compatibility_date": "2026-05-11"
  }
}

The $schema field gives you autocomplete and validation for void.json in your editor. The outputDir matches the Angular CLI's default output path — dist/<project-name>/browser. With appType set to spa, Void falls back all non-file paths to index.html, so the Angular router works out of the box.

If you created the project with SSR enabled, open angular.json and set the build target's outputMode to static, then remove the ssr entry and server option. Void serves the prerendered output as a static SPA:

"outputMode": "static"

Deploying

npx void auth login

Then deploy:

npx void deploy

Void runs your build command, uploads the static assets, and makes the site live:

┌  void deploy
│
◇  Building...
│  (ng build output)
│
◇  Checking assets...
◇  Uploading assets...
◇  Packaging...
◇  Deploying...
◇  Deployed!
│
│  ╭─────────────────────────────────────────╮
│  │  https://<project-name>.void.app        │
│  ╰─────────────────────────────────────────╯
│
└  Done!

On the first deploy, Void creates or links the project and saves the link to .void/project.json, so subsequent void deploy runs go straight to the same project. Run void project status to see recent deployments, and void project rollback to instantly switch traffic back to a previous one.

Shaping requests at the edge

Once the app is live, you can control how requests are served — without writing any worker code — by adding a routing block to void.json. These rules run on Cloudflare's edge before the response is served, so they add no latency.

Send old URLs to new ones with routing.redirects:

{
  "routing": {
    "redirects": {
      "/home": "/",
      "/blog/*": { "to": "/posts/:splat", "status": 301 }
    }
  }
}

Keys are source patterns where * matches any characters. A value is either a plain string (a 302 by default) or an object with an explicit status. :splat in the destination carries over whatever * matched.

Attach response headers — security policies, cache rules — by URL pattern with routing.headers:

{
  "routing": {
    "headers": {
      "/*": [
        "X-Frame-Options: DENY",
        "X-Content-Type-Options: nosniff",
        "Referrer-Policy: strict-origin-when-cross-origin"
      ]
    }
  }
}

Deploying from CI

To deploy on every push instead of from your machine, let Void scaffold a GitHub Actions workflow for you:

npx void init --github

This creates .github/workflows/deploy.yml with the right package manager commands to build and run void deploy on every push to main.

CI needs a deploy token instead of an interactive login. Run void auth token to copy one to your clipboard, then add it as a repository secret named VOID_TOKEN. Set VOID_PROJECT to your project slug so the CLI knows which project to target.

If you'd rather write the workflow by hand, a minimal version looks like this:

name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npx void deploy
        env:
          VOID_TOKEN: ${{ secrets.VOID_TOKEN }}
          VOID_PROJECT: angular-void

VOID_TOKEN skips the interactive login, and VOID_PROJECT tells the CLI which project to target.

Adding a custom domain

Point your own domain at the project with void domain add:

npx void domain add example.com

The CLI prints a CNAME target to add at your DNS provider. Check verification and SSL status anytime with void domain status example.com, or list every domain on the project with void domain list.

Conclusion

With void.json in place, deploying an Angular app to Cloudflare's global edge is a single void deploy away — no Cloudflare account and no Wrangler config required. Void runs the Angular CLI build untouched and serves the output as a SPA, while routing rules, custom domains, and a small CI workflow are there when you need them.

If you enjoyed this post, click the ❤️ so other people will see it. Follow Brandon Roberts on Bluesky, and subscribe to my YouTube Channel for more content!

Using Cypress Component Testing with Angular and Vite

Brandon Roberts — Thu, 14 May 2026 19:48:20 +0000

Cypress is an end-to-end and component testing framework that runs tests in a real browser. Cypress component testing supports both Webpack and Vite as its dev server bundler.

This guide configures an existing Cypress component testing setup in an Angular project to use Cypress's Vite bundler support instead of Webpack.

Installing the Vite plugin

First, install @analogjs/vite-plugin-angular as a dev dependency so Vite can compile Angular components:

npm install @analogjs/vite-plugin-angular --save-dev

Configuring Cypress

Next, Update cypress.config.ts at the project root to use the Vite bundler:

import { defineConfig } from 'cypress';
import angular from '@analogjs/vite-plugin-angular';

export default defineConfig({
  component: {
    devServer: {
      bundler: 'vite',
      // @ts-expect-error Cypress's public types do not yet pair `bundler: 'vite'`
      // with `framework: 'angular'`.
      framework: 'angular',
      viteConfig: {
        plugins: [angular({ tsconfig: 'tsconfig.cypress.json' })],
      },
    },
    specPattern: 'src/**/*.cy.ts',
    supportFile: 'cypress/support/component.ts',
    indexHtmlFile: 'cypress/support/component-index.html',
  },
});

Remove any existing Webpack-specific options from the component config.

Updating the support file

Next, update cypress/support/component.ts to import the matching mount adapter. For zoneless projects:

import '@angular/compiler';
import { mount } from 'cypress/angular-zoneless';

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
    }
  }
}

Cypress.Commands.add('mount', mount);

For zone-based projects:

import 'zone.js';
import 'zone.js/testing';
import '@angular/compiler';
import { mount } from 'cypress/angular';

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
    }
  }
}

Cypress.Commands.add('mount', mount);

For zoneless projects:

import '@angular/compiler';
import { mount } from 'cypress/angular';

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
    }
  }
}

Cypress.Commands.add('mount', mount);

Configuring TypeScript

Ensure tsconfig.cypress.json at the project root matches the following:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/cypress",
    "target": "es2022",
    "types": ["cypress", "node"],
    "noPropertyAccessFromIndexSignature": false
  },
  "include": ["src/**/*.ts", "cypress/**/*.ts"],
  "exclude": ["src/**/*.spec.ts", "src/test-setup.ts"]
}

Running tests

Your existing Cypress scripts work without changes:

npm run cypress:open
npm run cypress:run

The dev server now uses Vite, and your existing component specs run unchanged.

Conclusion

With Vite powering the dev server, your specs benefit from faster cold starts and HMR while keeping the Cypress features you rely on — real browser execution, time-travel debugging, automatic retries, cy.intercept network stubbing, and the interactive runner.

If you enjoyed this post, click the ❤️ so other people will see it. Follow AnalogJS and Brandon Roberts on Bluesky, and subscribe to my YouTube Channel for more content!

AnalogJS 2.5: Runtime i18n, Fast Compilation Mode, Hierarchical Content, and more!

Brandon Roberts — Tue, 28 Apr 2026 17:53:29 +0000

We are excited to announce the release of Analog 2.5! This release introduces first-class runtime i18n support, a new fast compilation mode, hierarchical content with recursive prerendering, and a new AI integrations guide. Let's dive in.

Runtime i18n 🌍

Analog 2.5 adds first-class runtime internationalization built on Angular's $localize. With a single build, your app can serve every supported locale, with the active locale detected on both the server and the client.

Setup

Install @angular/localize and import the polyfill in your application entry:

// src/main.ts
import '@angular/localize/init';

Configure the supported locales on the analog() plugin in vite.config.ts. This enables locale detection on SSR and exposes the values as build-time globals so the application config doesn't have to repeat them:

// vite.config.ts
import { defineConfig } from 'vite';
import analog from '@analogjs/platform';

export default defineConfig(() => ({
  plugins: [
    analog({
      i18n: {
        defaultLocale: 'en',
        locales: ['en', 'fr', 'de'],
      },
    }),
  ],
}));

Then provide the runtime translation loader via provideI18n():

// src/app/app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideFileRouter } from '@analogjs/router';
import { provideI18n } from '@analogjs/router/i18n';

export const appConfig: ApplicationConfig = {
  providers: [
    provideFileRouter(),
    provideI18n({
      loader: async (locale) => {
        const translations = await import(`../i18n/${locale}.json`);
        return translations.default;
      },
    }),
  ],
};

Mark templates with the standard Angular i18n attribute:

<h1 i18n="@@greeting">Hello</h1>

On SSR, the locale is detected from the URL path prefix (/fr/about) or the Accept-Language header. On the client, it's read from window.location.pathname. The loader function you provide is called once at startup with the active locale, and $localize handles the rest.

Message Extraction

The i18n plugin option also accepts an extract config that scans the compiled output for $localize tagged templates and writes a translation source file at the end of a production build:

analog({
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'fr', 'de'],
    extract: {
      format: 'json',
      outFile: 'src/i18n/messages.json',
    },
  },
})

format supports json, xliff, xliff2, and xmb.

Switching Locales

A small helper makes runtime locale switching a one-liner:

import { Component } from '@angular/core';
import { injectSwitchLocale } from '@analogjs/router/i18n';

@Component({ /* ... */ })
export class LanguagePickerComponent {
  switchLocale = injectSwitchLocale();
}

Calling switchLocale('fr') navigates to the equivalent /fr URL and re-evaluates templates with the new translations. Check out the i18n docs for the full guide.

Fast Compilation Mode ⚡️

Analog 2.5 introduces fastCompile, a new option on the analog() Vite plugin that enables a Vite-native Angular compilation pipeline combined with OXC for fast parsing. The most noticeable differences are with cold starts and HMR.

Enable it in your Vite config:

// vite.config.ts
import { defineConfig } from 'vite';
import analog from '@analogjs/platform';

export default defineConfig(() => ({
  plugins: [
    analog({
      fastCompile: true,
    }),
  ],
}));

A companion fastCompileMode option controls the compilation output:

'full' (default): Emits final Ivy definitions for application builds.
'partial': Emits partial declarations for library publishing.

analog({
  fastCompile: true,
  fastCompileMode: 'partial',
})

Fast compilation mode allows you to offload type checking as a separate process, keeping the development workflow streamlined, especially when building content-focused sites and applications, or running tests.

Hierarchical Content 📚

Support for hierarchical content and nested content directories has been improved for more complex documentation structure:

src/content/docs/
  getting-started/
    welcome.md
    first-upload.md
  assets/
    upload.md

Content resolvers in Analog previously only handled top level folders and slugs in the src/content directory, but is now more flexible to handle nested subdirectories with existing APIs.

Slash-containing slugs

A catch-all route now resolves nested files correctly:

// src/app/pages/docs/[...slug].page.ts
import { Component } from '@angular/core';
import { injectContent, MarkdownComponent } from '@analogjs/content';

@Component({
  standalone: true,
  imports: [MarkdownComponent],
  template: `
    @if (post(); as post) {
      <analog-markdown [content]="post.content" />
    }
  `,
})
export default class DocsPageComponent {
  post = injectContent({ subdirectory: 'docs' });
}

Recursive prerendering

A new recursive option was added, and each content file now exposes a relativePath so transforms can identify identically-named files across subdirectories:

// vite.config.ts
analog({
  prerender: {
    routes: async () => [
      {
        contentDir: 'src/content/docs',
        recursive: true,
        transform: (file) => {
          const segment = file.relativePath
            ? `${file.relativePath}/`
            : '';
          return `/docs/${segment}${file.name}`;
        },
      },
    ],
  },
})

For backward compatibility, recursive defaults to false.

AI Integrations Guide 🤖

Analog 2.5 ships with a new AI integrations guide that walks through wiring LLM providers into Analog's API routes — streaming responses, server-side keys, and the usual use cases. If you're adding AI features to an app, that guide is the starting point.

We are also looking into adding official skills for Analog features and conventions.

Upgrading

To upgrade to Analog 2.5, run:

ng update @analogjs/platform@latest

If you're using Nx, run:

nx migrate @analogjs/platform@latest

For the full list of changes, see the changelog.

Partner with Analog 🤝

Find out more information on our partnership opportunities or reach out directly to partnerships[at]analogjs.org.

Join the Community 🥇

Visit and Star the GitHub Repo
Join the Discord
Follow us on Twitter

If you enjoyed this post, click the ❤️ so other people will see it. Follow AnalogJS and Brandon Roberts on Bluesky, and subscribe to my YouTube Channel for more content!

AnalogJS 2.4: Vite 8, Vitest Snapshot Serializers, Astro v6 Support, and more!

Brandon Roberts — Mon, 30 Mar 2026 16:52:55 +0000

We are excited to announce the release of Analog 2.4! This release brings Vite 8 support, significant testing improvements for Vitest w/ Angular, and an updated Astro Angular integration. Let's dive in.

Vite 8 Support ⚡️

Analog 2.4 updates to the stable release of Vite 8.0.0. This is a major ecosystem alignment that brings several benefits:

Rolldown bundler: Vite 8 introduces Rolldown, a Rust-based bundler, as an alternative to esbuild for optimization. Analog's Angular Vite plugin now detects Rolldown availability and uses OXC-based compilation when available.
Vite Environment API: Analog leverages the new Environment API for managing client and server configurations, particularly in the Astro Angular integration.
Backward compatibility: Analog integrations continue to support Vite 5 through 8, so you can upgrade at your own pace.

Vitest DX Improvements 🧪

Reusable Snapshot Serializers

Writing snapshot tests for Angular components often produces noisy output filled with framework internals like _ngcontent-*, _nghost-*, ng-reflect-* attributes, and  comments. Analog 2.4 introduces three built-in snapshot serializers that clean this up.

createNoNgAttributesSnapshotSerializer strips Angular runtime noise from DOM snapshots. Here's what that looks like in practice:

<!-- Before -->
<div id="root0" ng-version="21.1.3" _nghost-a-c1="" class="card ng-star-inserted keep-me">
  <span class="card ng-star-inserted" _ngcontent-a-c1="" ng-reflect-foo="bar">Title</span>
</div>

<!-- After -->
<div class="card keep-me">
  <span class="card">Title</span>
</div>

createAngularFixtureSnapshotSerializer converts ComponentFixture objects into clean component markup, so instead of seeing raw testing internals you get:

<app-chip>
  <h1>
    Hello [Input Signal: Alice]
  </h1>
</app-chip>

createHtmlCommentSnapshotSerializer removes Angular-generated HTML comments like .

The easiest way to enable all serializers is via the automatic setup imports in your test setup file:

import '@angular/compiler';
import '@analogjs/vitest-angular/setup-snapshots';
import '@analogjs/vitest-angular/setup-serializers';
import { setupTestBed } from '@analogjs/vitest-angular/setup-testbed';

setupTestBed();

New Analog projects include this by default. You can also register serializers individually if you need more control:

import {
  createAngularFixtureSnapshotSerializer,
  createNoNgAttributesSnapshotSerializer,
  createHtmlCommentSnapshotSerializer,
} from '@analogjs/vitest-angular/snapshot-serializers';

expect.addSnapshotSerializer(createAngularFixtureSnapshotSerializer());
expect.addSnapshotSerializer(createNoNgAttributesSnapshotSerializer());
expect.addSnapshotSerializer(createHtmlCommentSnapshotSerializer());

Many thanks to Tim Deschryver for adding this feature!

`teardown.destroyAfterEach` Option

The new teardown option on setupTestBed gives you explicit control over Angular TestBed cleanup behavior:

import { setupTestBed } from '@analogjs/vitest-angular/setup-testbed';

setupTestBed({
  teardown: { destroyAfterEach: false },
});

This replaces the browserMode option, which is now deprecated and will be removed in v3.0.0.

Check out our Vitest Guide for more information on setting up Vitest in your Angular projects.

Many thanks to Younes Jaaidi for adding this feature!

Astro v6 Support & Strict Style Placement 🚀

Astro v6 Compatibility

Analog 2.4 adds full support for Astro v6 via the new Vite Environment API. Use the official Astro upgrade tool to update Astro and its integrations together:

npx @astrojs/upgrade

Then update @analogjs/astro-angular to the latest version:

npm install @analogjs/astro-angular@latest

`strictStylePlacement` Option

A new strictStylePlacement configuration option moves Angular component styles from the component body into the document <head>, producing valid HTML output:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import angular from '@analogjs/astro-angular';

export default defineConfig({
  integrations: [angular({ strictStylePlacement: true })],
});

When enabled, Angular component styles are relocated to <head> regardless of which island they originate from. Style ordering is preserved across multiple islands, and styles inside <template> elements (shadow DOM) are left in place. This lays the foundation for enabling client-side hydration of Angular components when used with Astro.

Note: Enabling this option disables Astro's streaming mode under SSR.

Many thanks to eblocha for the feature request and addition!

Upgrading

To upgrade to Analog 2.4, run:

ng update @analogjs/platform@latest

If you're using Nx, run:

nx migrate @analogjs/platform@latest

For the full list of changes, see the changelog.

Partner with Analog 🤝

Find out more information on our partnership opportunities or reach out directly to partnerships[at]analogjs.org.

Join the Community 🥇

Visit and Star the GitHub Repo
Join the Discord
Follow us on Twitter

If you enjoyed this post, click the ❤️ so other people will see it. Follow AnalogJS and Brandon Roberts on Bluesky, and subscribe to my YouTube Channel for more content!

Using a Headless CMS with Angular and Analog Content Loaders

Brandon Roberts — Mon, 23 Feb 2026 19:22:52 +0000

Analog provides a powerful content system out of the box. Drop some markdown files in the src/content folder, add some frontmatter, and you have a working blog. For many projects, this is all you need.

The @analogjs/content package also allows you to pull posts from a headless CMS like Contentful, Sanity, or some other external source. This post shows you how to provide your own content loaders and keep your component the same using the custom content resource APIs.

Understanding the Default Content System

Before diving into custom loaders, let's understand how the default system works. Analog provides Resources that fetch content files and content using Angular Resources underneath. When you call contentFilesResource(), Analog returns an Angular resource containing an array of ContentFile objects:

interface ContentFile<Attributes extends Record<string, any>> {
  filename: string;
  slug: string;
  content?: string | object;
  attributes: Attributes;
}

Each content file has a filename (the path to the file), a slug (derived from the filename or frontmatter), optional content (the rendered body), and attributes (parsed frontmatter). You typically define an interface for your attributes:

import { contentFilesResource } from '@analogjs/content/resources';

interface PostAttributes {
  title: string;
  description: string;
  published: boolean;
  publishedDate: string;
}

// In your component class
readonly posts = contentFilesResource<PostAttributes>();

// In your template, access the value using .value()
// @for (post of posts.value(); track post.slug) { ... }

The resource functions use Angular's resource() API under the hood, which means they return signals.

By default, loaders scan your src/content folder, parse the frontmatter, and make everything available through dependency injection.

The Content Loader Tokens

Analog exports two Injection tokens that control how content is loaded:

CONTENT_LIST_LOADER - Returns a function that provides an array of all content files. This powers contentFilesResource() and is used when you need to list or filter your content.

CONTENT_FILE_LOADER - Returns a function that provides a map of filenames to content loader functions. This powers contentFileResource() and is used when loading individual content files by slug.

You can provide your own implementations using the standard provide syntax to provide the data from your custom source.

Fetching Custom Content at Build Time

When building static sites with Analog, fetching content is done at build time. Customizing this behavior involves three pieces: a Vite plugin that fetches content and exposes it as a virtual module, custom content loaders that consume the pre-fetched data, and prerender configuration to generate routes for your external content.

Creating a Vite Plugin

Vite plugins can fetch external content during the build process and expose it through a virtual module.

For example, here's a plugin that fetches articles from dev.to:

// vite-plugins/devto-posts.ts
import { Plugin } from 'vite';

export interface DevToArticle {
  id: number;
  slug: string;
  title: string;
  description: string;
  published_at: string;
  body_markdown?: string;
  cover_image?: string;
}

export function devToPostsPlugin(username: string): Plugin {
  const virtualModuleId = 'virtual:devto-posts';
  const resolvedVirtualModuleId = '\0' + virtualModuleId;
  let cachedPosts: string | null = null;

  return {
    name: 'devto-posts',
    resolveId(id) {
      if (id === virtualModuleId) {
        return resolvedVirtualModuleId;
      }
    },
    async load(id) {
      if (id === resolvedVirtualModuleId) {
        if (!cachedPosts) {
          // Fetch article list
          const response = await fetch(
            `https://dev.to/api/articles?username=${username}&per_page=10`
          );
          const articles: DevToArticle[] = await response.json();

          // Fetch full content for each article
          const fullArticles = await Promise.all(
            articles.map(async (article) => {
              const full = await fetch(
                `https://dev.to/api/articles/${article.id}`
              ).then((r) => r.json());
              return full;
            })
          );

          cachedPosts = JSON.stringify(fullArticles);
        }
        return `export const devToPosts = ${cachedPosts};`;
      }
    },
  };
}

The plugin fetches articles once during the build, caches the result, and exposes them through a virtual module that can be imported anywhere in your application.

Adding Types for the Virtal Module

For type-safety, TypeScript needs a declaration file to understand the virtual module:

// src/app/data/devto-posts.d.ts
declare module 'virtual:devto-posts' {
  import { DevToArticle } from '../vite-plugins/devto-posts';
  export const devToPosts: DevToArticle[];
}

Custom Loaders with Build-Time Data

Now we create custom content loaders that use the pre-fetched data from the virtual module:

// src/app/providers/devto-content-loader.ts
import { Provider } from '@angular/core';
import {
  ContentFile,
  CONTENT_LIST_LOADER,
  CONTENT_FILE_LOADER,
  injectContentFiles,
  injectContentFilesMap,
} from '@analogjs/content';
import { devToPosts, DevToArticle } from 'virtual:devto-posts';

export interface PostAttributes {
  title: string;
  slug: string;
  description: string;
  published: boolean;
  publishedDate: string;
  isDevTo?: boolean;
  coverImage?: string;
}

/** Convert a dev.to article to the ContentFile format */
function toContentFile(article: DevToArticle): ContentFile<PostAttributes> {
  return {
    filename: article.slug,
    slug: article.slug,
    content: article.body_markdown,
    attributes: {
      title: article.title,
      slug: article.slug,
      description: article.description,
      published: true,
      publishedDate: article.published_at,
      isDevTo: true,
      coverImage: article.cover_image,
    },
  };
}

/** Custom list loader combining local markdown and dev.to posts */
export function withDevToContentListLoader(): Provider {
  return {
    provide: CONTENT_LIST_LOADER,
    useFactory() {
      return async () => {
        // Get local markdown files
        const localPosts = injectContentFiles<PostAttributes>();

        // Convert dev.to posts to ContentFile format
        const devToContentFiles = devToPosts.map(toContentFile);

        // Combine and sort by date
        return [...localPosts, ...devToContentFiles].sort(
          (a, b) =>
            new Date(b.attributes.publishedDate).getTime() -
            new Date(a.attributes.publishedDate).getTime()
        );
      };
    },
  };
}

/** Custom file loader including dev.to posts */
export function withDevToContentFileLoader(): Provider {
  return {
    provide: CONTENT_FILE_LOADER,
    useFactory() {
      return async () => {
        // Get local content files map
        const localFilesMap = injectContentFilesMap();

        // Add dev.to posts to the map
        const devToFilesMap: Record<string, () => Promise<any>> = {};
        for (const article of devToPosts) {
          devToFilesMap[article.slug] = async () => ({
            metadata: {
              title: article.title,
              slug: article.slug,
              description: article.description,
              published: true,
              publishedDate: article.published_at,
              isDevTo: true,
            },
            default: article.body_markdown,
          });
        }

        return { ...localFilesMap, ...devToFilesMap };
      };
    },
  };
}

/** Combined provider for both loaders */
export function withDevToContentLoader(): Provider[] {
  return [
    withDevToContentListLoader(), 
    withDevToContentFileLoader()
  ];
}

The loaders use injectContentFiles() and injectContentFilesMap() to get the default local content, then merge it with the build-time fetched dev.to posts.

Configuring Vite and Prerender Routes

// vite.config.ts
import { defineConfig } from 'vite';
import analog from '@analogjs/platform';
import { devToPostsPlugin } from './vite-plugins/devto-posts';

export default defineConfig({
  plugins: [
    devToPostsPlugin('your-devto-username'),
    analog({
      static: true,
      prerender: {
        routes: async () => {
          // Fetch slugs for prerendering
          const response = await fetch(
            'https://dev.to/api/articles?username=your-devto-username&per_page=10'
          );
          const articles = await response.json();
          const devToSlugs = articles.map((a: any) => a.slug);

          return [
            '/',
            '/blog',
            // Local content
            { contentDir: '/src/content', transform: (file) => `/blog/posts/${file.attributes.slug}` },
            // Dev.to posts
            ...devToSlugs.map((slug: string) => `/blog/posts/${slug}`),
          ];
        },
      },
    }),
  ],
});

Finally, provide the custom loaders in your app configuration:

// src/app/app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideFileRouter } from '@analogjs/router';
import { provideContent, withMarkdownRenderer } from '@analogjs/content';
import { withDevToContentLoader } from './providers/devto-content-loader';

export const appConfig: ApplicationConfig = {
  providers: [
    provideFileRouter(),
    provideContent(
      withMarkdownRenderer(),
      ...withDevToContentLoader()
    ),
  ],
};

Using the Content in Components

Your components use contentFilesResource() and contentFileResource() exactly as they would with local content:

// src/app/pages/blog.page.ts
import { Component } from '@angular/core';
import { RouterLink } from '@angular/router';
import { contentFilesResource } from '@analogjs/content/resources';
import { PostAttributes } from '../providers/devto-content-loader';

@Component({
  imports: [RouterLink],
  template: `
    <h1>Blog</h1>
    <ul>
      @for (post of posts.value(); track post.slug) {
        <li>
          <a [routerLink]="['/blog/posts', post.slug]">
            {{ post.attributes.title }}
          </a>
        </li>
      }
    </ul>
  `,
})
export default class BlogComponent {
  readonly posts = contentFilesResource<PostAttributes>();
}

For individual posts:

// src/app/pages/blog/posts/[slug].page.ts
import { Component } from '@angular/core';
import { MarkdownComponent } from '@analogjs/content';
import { contentFileResource } from '@analogjs/content/resources';
import { PostAttributes } from '../../../providers/devto-content-loader';

@Component({
  imports: [MarkdownComponent],
  template: `
    @if (post.value(); as post) {
      <article>
        <h1>{{ post.attributes.title }}</h1>

        <analog-markdown [content]="post.content"></analog-markdown>
      </article>
    }
  `,
})
export default class BlogPostComponent {
  readonly post = contentFileResource<PostAttributes>();
}

The components are completely agnostic to where the content comes from. Local markdown files and dev.to articles are presented through the same unified API.

Custom content file loaders give you the flexibility to fetch content from anywhere while maintaining a consistent API in your components. By combining Vite plugins for build-time fetching with custom loader tokens, you can integrate external content sources like dev.to, headless CMS platforms, or databases - all while your components continue using contentFilesResource() and contentFileResource() without any changes.

Check out the Analog documentation for more details on the content system.

If you enjoyed this post, click the ❤️ so other people will see it. Follow me on Bluesky, X, and subscribe to my YouTube Channel for more content!

Angular Skills: Agent Skills for AI-Assisted Development

Brandon Roberts — Mon, 26 Jan 2026 16:39:24 +0000

Coding agents are powerful tools for building applications, but they often suggest outdated Angular patterns—NgModules, @Input() decorators, *ngIf, and constructor injection. Angular has evolved significantly, and without up-to-date context, coding agents don't know about standalone components, signals, or the new control flow syntax.

This post introduces Angular Skills, a collection of skills that teach coding agents modern Angular v20+ patterns.

What Are Skills?

Skills are structured knowledge files that provide coding agents with domain-specific expertise. Agent Skills are a simple, open format for giving agents new capabilities and expertise, developed by Anthropic. They are meant to integrate directly into your AI-assisted development workflow.

Installing Angular Skills

Install all skills with a single command:

npx skills add analogjs/angular-skills

Or install individual skills:

npx skills add analogjs/angular-skills/skills/angular-signals
npx skills add analogjs/angular-skills/skills/angular-forms
npx skills add analogjs/angular-skills/skills/angular-http

Available Skills

angular-component

Modern standalone components with signal-based inputs, outputs, and queries. Covers OnPush change detection, host bindings, content projection, and lifecycle hooks.

angular-signals

Angular's reactive primitives: signal(), computed(), linkedSignal(), and effect(). Includes RxJS interop with toSignal() and toObservable().

angular-di

Dependency injection using the inject() function, injection tokens, provider configuration, and hierarchical DI patterns.

angular-forms

Signal Forms (experimental) with schema-based validation and field state management.

angular-http

Data fetching with httpResource() and resource() APIs for declarative, signal-based HTTP. Also covers HttpClient and functional interceptors.

angular-routing

Lazy loading, functional guards and resolvers, and signal-based route parameters with input.fromRoute().

angular-directives

Attribute directives, structural directives for portals and overlays, and host directive composition.

angular-ssr

Server-side rendering, incremental hydration, prerendering, and patterns for browser-only code.

angular-testing

Testing with TestBed, component harnesses, and signal testing utilities. Includes Vitest support for Angular v21+.

angular-tooling

Angular CLI commands, code generation with schematics, build configuration, and workspace setup.

What You Get

With these skills installed, coding agents will:

Use standalone components without adding standalone: true
Prefer signal inputs (input(), input.required()) over @Input() decorators
Use native control flow (@if, @for, @switch) instead of *ngIf, *ngFor
Apply OnPush change detection by default
Use inject() instead of constructor injection
Suggest httpResource() for data fetching
Write functional guards and interceptors
And more ...

Conclusion

Angular Skills provides coding agents with the context they need to generate modern Angular code. Install the skills and start building with AI that understands the framework.

Check out the repository:

https://github.com/analogjs/angular-skills

Give the GitHub repo a ⭐️! Contributions are welcome!

If you enjoyed this post, click the ❤️ so other people will see it. Follow me on Bluesky, X, and subscribe to my YouTube Channel for more content!

Interactive Angular Component Testing with Storybook and Vitest

Brandon Roberts — Wed, 14 Jan 2026 17:36:14 +0000

Storybook is a frontend workshop for building UI components and pages in isolation. Storybook with Vitest also enables interactive component testing.

This post guides you through setting up Storybook with Angular using Vite and the @storybook/addon-vitest package for interactive component testing.

Setting up Storybook

If you don't have Storybook setup already, run the following command to initialize Storybook for your project:

npx storybook@latest init --type angular

This installs the necessary Storybook dependencies and sets up a Storybook with example components including a Button component.

Follow the provided prompts, and commit your changes.

Setting up Storybook to use Vite with Analog

Install the AnalogJS Storybook Angular integration:

npm install @analogjs/storybook-angular @angular/animations zone.js --save-dev

Update the .storybook/main.ts file to use the @analogjs/storybook-angular package:

import { StorybookConfig } from '@analogjs/storybook-angular';

const config: StorybookConfig = {
  stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|mjs|ts|tsx)'],
  addons: [
    '@storybook/addon-essentials',
    '@storybook/addon-interactions',
  ],
  framework: {
    name: '@analogjs/storybook-angular',
    options: {},
  },
};

export default config;

Update the angular.json storybook targets to use the @analogjs/storybook-angular builders:

"storybook": {
  "builder": "@analogjs/storybook-angular:start-storybook",
  "options": {
    "configDir": ".storybook",
    "styles": ["src/styles.css"],
    "experimentalZoneless": true
  }
},
"build-storybook": {
  "builder": "@analogjs/storybook-angular:build-storybook",
  "options": {
    "configDir": ".storybook",
    "styles": ["src/styles.css"],
    "experimentalZoneless": true
  }
}

Run Storybook to verify everything works:

npm run storybook

Setting up Vitest for Interaction Testing

Install the Vitest addon and dependencies:

npm install @analogjs/vitest-angular @storybook/addon-vitest vitest @vitest/browser-playwright --save-dev

Add the addon to your .storybook/main.ts:

import { StorybookConfig } from '@analogjs/storybook-angular';

const config: StorybookConfig = {
  stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|mjs|ts|tsx)'],
  addons: [
    '@storybook/addon-essentials',
    '@storybook/addon-interactions',
    '@storybook/addon-vitest',
  ],
  framework: {
    name: '@analogjs/storybook-angular',
    options: {},
  },
};

export default config;

Create a .storybook/vitest.setup.ts file:

import '@angular/compiler';
import { setProjectAnnotations } from '@analogjs/storybook-angular/testing';
import { beforeAll } from 'vitest';
import * as projectAnnotations from './preview';

const project = setProjectAnnotations([projectAnnotations]);

beforeAll(project.beforeAll);

Update .storybook/tsconfig.json to include the setup file:

{
  "extends": "../tsconfig.app.json",
  "compilerOptions": {
    "types": ["node"],
    "allowSyntheticDefaultImports": true,
    "resolveJsonModule": true
  },
  "exclude": ["../src/test.ts", "../src/**/*.spec.ts"],
  "include": ["../src/**/*.stories.*", "./preview.ts", "./vitest.setup.ts"],
  "files": ["./typings.d.ts"]
}

Create a vitest.config.ts file in your project root:

/// <reference types="vitest/config" />
import { defineConfig } from 'vite';
import path from 'node:path';
import { fileURLToPath } from 'node:url';
import { storybookTest } from '@storybook/addon-vitest/vitest-plugin';
import { playwright } from '@vitest/browser-playwright';

const dirname =
  typeof __dirname !== 'undefined'
    ? __dirname
    : path.dirname(fileURLToPath(import.meta.url));

export default defineConfig({
  test: {
    projects: [
      {
        extends: true,
        plugins: [
          storybookTest({
            configDir: path.join(dirname, '.storybook'),
          }),
        ],
        test: {
          name: 'storybook',
          browser: {
            enabled: true,
            headless: true,
            provider: playwright(),
            instances: [{ browser: 'chromium' }],
          },
          setupFiles: ['.storybook/vitest.setup.ts'],
        },
      },
    ],
  },
});

Install Playwright browser binaries:

npx playwright install chromium

Add the test-storybook target to your angular.json:

"test-storybook": {
  "builder": "@analogjs/vitest-angular:test",
  "options": {
    "configFile": "vitest.config.ts"
  }
}

Add a test script to your package.json:

"scripts": {
  "test-storybook": "ng run your-app:test-storybook"
}

Writing Interaction Tests

The Button component from Storybook's initial setup is a great example for interaction testing. Here's how to add a play function to test user interactions:

import type { Meta, StoryObj } from '@storybook/angular';
import { fn, expect, userEvent, within } from '@storybook/test';
import { Button } from './button.component';

const meta: Meta<Button> = {
  title: 'Example/Button',
  component: Button,
  argTypes: {
    backgroundColor: { control: 'color' },
  },
  args: { onClick: fn() },
};

export default meta;
type Story = StoryObj<Button>;

export const Primary: Story = {
  args: {
    primary: true,
    label: 'Button',
  },
  play: async ({ canvasElement, args }) => {
    const canvas = within(canvasElement);
    const button = canvas.getByRole('button', { name: /Button/i });

    await userEvent.click(button);

    await expect(args.onClick).toHaveBeenCalled();
  },
};

export const Secondary: Story = {
  args: {
    label: 'Button',
  },
  play: async ({ canvasElement }) => {
    const canvas = within(canvasElement);
    const button = canvas.getByRole('button', { name: /Button/i });

    await expect(button).toBeInTheDocument();
    await expect(button).toHaveClass('storybook-button--secondary');
  },
};

The play function allows you to:

Query elements using within(canvasElement)
Simulate user interactions with userEvent
Make assertions with expect
And more ...

Running Tests

Run your interaction tests with:

npm run test-storybook

This runs all stories with play functions as tests in a real browser using Playwright, giving you confidence that your components work as expected.

You can also run tests directly in the Storybook UI. Start Storybook and use the "Run Tests" button in the sidebar, or navigate to a story to see interaction tests run automatically in the Interactions panel.

Conclusion

Using Storybook with Angular and Vite provides faster builds and a better developer experience. Adding Vitest for interaction testing lets you verify component behavior directly in your stories.

See the example repository with a full Storybook setup

https://github.com/brandonroberts/angular-vite-storybook

If you enjoyed this post, click the ❤️ so other people will see it. Follow AnalogJS and me on Twitter/X, and subscribe to my YouTube Channel for more content!

Building an Angular Compiler using AI with Google Gemini

Brandon Roberts — Wed, 31 Dec 2025 17:15:08 +0000

The Angular Compiler is the pipeline that translates Angular decorator and template syntax into metadata and Ivy runtime instructions. In an exploration using Gemini, I set out to build a "Lite" version of this without the @angular/compiler-cli package to learn more about the internals of the Angular Compiler, how Angular transforms components into the static ɵcmp and ɵfac properties, and how this could influence single-file compilation in the future with build tools such as Vite.

Parsing Decorator Metadata

Every Angular component begins with a @Component decorator. My compiler's first task is to statically analyze the metadata. This can be done using the TypeScript Compiler API to scan for classes, decorators, and other properties of the source file.

To research the complex R3ComponentMetadata structures, I leveraged Gemini as a specialized research agent. By feeding it snippets of the Angular source code, I was able to:

Map internal interfaces: Gemini identified the relationships between the Component decorator properties and the internal R3 metadata required by the compileComponentFromMetadata function.
Scan for modern APIs: I used Gemini to help write a static analyzer that identifies Signal-based APIs like input() and model() within class members, ensuring they are registered in the metadata even though they sit outside the decorator.

function extractMetadata(dec: ts.Decorator): any {
  const call = dec.expression as ts.CallExpression;
  const obj = call.arguments[0] as ts.ObjectLiteralExpression;
  const meta: any = { hostRaw: {}, inputs: {}, outputs: {}, standalone: true, imports: [], providers: null, viewProviders: null, animations: null, changeDetection: 1, encapsulation: 0, preserveWhitespaces: false, exportAs: null, styles: [], templateUrl: null, styleUrls: [] };
  if (!obj) return meta;
  obj.properties.forEach(p => {
    if (!ts.isPropertyAssignment(p)) return;
    const key = p.name.getText().replace(/['"`]/g, ''), valNode = p.initializer, valText = valNode.getText();
    switch (key) {
      case 'host': if (ts.isObjectLiteralExpression(valNode)) valNode.properties.forEach(hp => { if (ts.isPropertyAssignment(hp)) meta.hostRaw[hp.name.getText().replace(/['"`]/g, '')] = hp.initializer.getText().replace(/['"`]/g, ''); }); break;
      case 'changeDetection': meta.changeDetection = valText.includes('OnPush') ? 0 : 1; break;
      case 'encapsulation': meta.encapsulation = valText.includes('None') ? 2 : (valText.includes('ShadowDom') ? 3 : 0); break;
      case 'preserveWhitespaces': meta.preserveWhitespaces = valText === 'true'; break;
      case 'exportAs': meta.exportAs = [valText.replace(/['"`]/g, '')]; break;
      case 'templateUrl': meta.templateUrl = valText.replace(/['"`]/g, ''); break;
      case 'styleUrls': if (ts.isArrayLiteralExpression(valNode)) meta.styleUrls = valNode.elements.map(e => e.getText().replace(/['"`]/g, '')); break;
      case 'styles': if (ts.isArrayLiteralExpression(valNode)) meta.styles = valNode.elements.map(e => e.getText().replace(/['"`]/g, '')); break;
      case 'imports': case 'providers': case 'viewProviders': case 'animations': case 'rawImports': if (ts.isArrayLiteralExpression(valNode)) meta[key] = valNode.elements.map(e => new o.WrappedNodeExpr(e)); break;
      default: meta[key] = valText.replace(/['"`]/g, '');
    }
  });
  return meta;
}

This function collects all the necessary metadata from the Component decorator, and translates into TypeScript expressions that can be passed to the compileComponentFromMetadata function.

Parsing the Component Template

After metadata is gathered, the next step is processing the template string. Using the official @angular/compiler's parseTemplate function, raw HTML is converted into a Angular's Render3 AST.

Gemini assisted in deciphering the AST Node documentation, helping me understand how high-level syntax—like the new @if control flow—is converted into discrete internal nodes that the code generator can understand.

const parsedTemplate = parseTemplate(templateString, fileName, {
  preserveWhitespaces: false,
});

The parseTemplate function has many use cases; for example, it is used by Angular ESLint to analyze the AST and validate lint rules. It's also used in Angular migrations to detect legacy syntax that can be migrated to newer syntax.

// The result is a collection of nodes (Element, BoundText, etc.)
const templateNodes = parsedTemplate.nodes;

As the result can be fed directly into the component compiler function, not much extra transformation is needed here.

    const cmp = compileComponentFromMetadata({
      // other metadata
      template: {
        nodes: parsedTemplate.nodes,
        ngContentSelectors: parsedTemplate.ngContentSelectors,
        preserveWhitespaces: parsedTemplate.preserveWhitespaces
      }
    });

There's much more metadata that's needed to compile an Angular component, but these are the necessary parts for incorporating the template.

Translating the Output AST

The next phase is translating Angular's internal "Output AST" back into valid TypeScript code. This was achieved an Exhaustive Visitor Pattern, mapping Angular nodes to TypeScript Factory calls.

Initially, Gemini generated some utility functions to translate Angular's AST output to TypeScript code.

function translateOutputASTStatement(stmt: o.Statement, printer: ts.Printer, sf: ts.SourceFile): string | ts.Statement {
  let tsStmt: ts.Statement;

  if (stmt instanceof o.ReturnStatement) {
    tsStmt = ts.factory.createReturnStatement(translateOutputAST(stmt.value));
  } else if (stmt instanceof o.DeclareVarStmt) {
    tsStmt = ts.factory.createVariableStatement(
      undefined,
      ts.factory.createVariableDeclarationList(
        [ts.factory.createVariableDeclaration(stmt.name, undefined, undefined, stmt.value ? translateOutputAST(stmt.value) : undefined)],
        stmt.hasModifier(o.StmtModifier.Final) ? ts.NodeFlags.Const : ts.NodeFlags.Let
      )
    );
  } else if (stmt instanceof o.IfStmt) {
    tsStmt = ts.factory.createIfStatement(
      translateOutputAST(stmt.condition),
      ts.factory.createBlock(stmt.trueCase.map(s => translateOutputASTStatement(s, null as any, null as any) as ts.Statement), true),
      stmt.falseCase.length ? ts.factory.createBlock(stmt.falseCase.map(s => translateOutputASTStatement(s, null as any, null as any) as ts.Statement), true) : undefined
    );
  } else if (stmt instanceof o.ExpressionStatement) {
    tsStmt = ts.factory.createExpressionStatement(translateOutputAST(stmt.expr));
  } else {
    tsStmt = ts.factory.createEmptyStatement();
  }

  return printer ? printer.printNode(ts.EmitHint.Unspecified, tsStmt, sf) : tsStmt;
}

function translateOutputAST(expr: o.Expression): ts.Expression {
  // Literals
  if (expr instanceof o.LiteralExpr) {
    if (typeof expr.value === 'string') return ts.factory.createStringLiteral(expr.value);
    if (typeof expr.value === 'number') return ts.factory.createNumericLiteral(String(expr.value));
    if (typeof expr.value === 'boolean') return expr.value ? ts.factory.createTrue() : ts.factory.createFalse();
    return ts.factory.createNull();
  }

  // References & Core Bridge
  if (expr instanceof o.ExternalExpr) {
    return ts.factory.createPropertyAccessExpression(ts.factory.createIdentifier('i0'), ts.factory.createIdentifier(expr.value.name!));
  }
  if (expr instanceof o.ReadVarExpr) return ts.factory.createIdentifier(expr.name);
  if (expr instanceof o.ReadPropExpr) return ts.factory.createPropertyAccessExpression(translateOutputAST(expr.receiver), expr.name);
  if (expr instanceof o.ReadKeyExpr) return ts.factory.createElementAccessExpression(translateOutputAST(expr.receiver), translateOutputAST(expr.index));

  // Functions & Constructors
  if (expr instanceof o.FunctionExpr) {
    return ts.factory.createArrowFunction(
      undefined, undefined,
      expr.params.map(p => ts.factory.createParameterDeclaration(undefined, undefined, p.name, undefined, undefined, undefined)),
      undefined, ts.factory.createToken(ts.SyntaxKind.EqualsGreaterThanToken),
      ts.factory.createBlock(expr.statements.map(s => translateOutputASTStatement(s, null as any, null as any) as ts.Statement), true)
    );
  }
  if (expr instanceof o.InvokeFunctionExpr) return ts.factory.createCallExpression(translateOutputAST(expr.fn), undefined, expr.args.map(translateOutputAST));
  // if (expr instanceof ts.stat.InvokeMethodExpr) {
  //   return ts.factory.createCallExpression(
  //     ts.factory.createPropertyAccessExpression(translateOutputAST(expr.receiver), expr.name),
  //     undefined, expr.args.map(translateOutputAST)
  //   );
  // }
  if (expr instanceof o.InstantiateExpr) {
    return ts.factory.createNewExpression(translateOutputAST(expr.classExpr), undefined, expr.args.map(translateOutputAST));
  }

  // Operators & Logic
  if (expr instanceof o.BinaryOperatorExpr) {
    const opMap: Record<o.BinaryOperator, ts.BinaryOperator> = {
      [o.BinaryOperator.And]: ts.SyntaxKind.AmpersandAmpersandToken, [o.BinaryOperator.Or]: ts.SyntaxKind.BarBarToken,
      [o.BinaryOperator.Equals]: ts.SyntaxKind.EqualsEqualsToken, [o.BinaryOperator.Identical]: ts.SyntaxKind.EqualsEqualsEqualsToken,
      [o.BinaryOperator.NotEquals]: ts.SyntaxKind.ExclamationEqualsToken, [o.BinaryOperator.NotIdentical]: ts.SyntaxKind.ExclamationEqualsEqualsToken,
      [o.BinaryOperator.Minus]: ts.SyntaxKind.MinusToken, [o.BinaryOperator.Plus]: ts.SyntaxKind.PlusToken,
      [o.BinaryOperator.Divide]: ts.SyntaxKind.SlashToken, [o.BinaryOperator.Multiply]: ts.SyntaxKind.AsteriskToken,
      [o.BinaryOperator.Modulo]: ts.SyntaxKind.PercentToken, [o.BinaryOperator.Lower]: ts.SyntaxKind.LessThanToken,
      [o.BinaryOperator.LowerEquals]: ts.SyntaxKind.LessThanEqualsToken, [o.BinaryOperator.Bigger]: ts.SyntaxKind.GreaterThanToken,
      [o.BinaryOperator.BiggerEquals]: ts.SyntaxKind.GreaterThanEqualsToken, [o.BinaryOperator.BitwiseAnd]: ts.SyntaxKind.AmpersandToken
    };
    return ts.factory.createBinaryExpression(translateOutputAST(expr.lhs), opMap[expr.operator] ?? ts.SyntaxKind.PlusToken, translateOutputAST(expr.rhs));
  }
  if (expr instanceof o.NotExpr) return ts.factory.createPrefixUnaryExpression(ts.SyntaxKind.ExclamationToken, translateOutputAST(expr.condition));
  if (expr instanceof o.TypeofExpr) return ts.factory.createTypeOfExpression(translateOutputAST(expr.expr));
  if (expr instanceof o.ConditionalExpr) {
    return ts.factory.createConditionalExpression(translateOutputAST(expr.condition), ts.factory.createToken(ts.SyntaxKind.QuestionToken), translateOutputAST(expr.trueCase), ts.factory.createToken(ts.SyntaxKind.ColonToken), translateOutputAST(expr.falseCase!));
  }

  // Collections
  if (expr instanceof o.LiteralMapExpr) {
    return ts.factory.createObjectLiteralExpression(expr.entries.map(e => ts.factory.createPropertyAssignment(e.quoted ? ts.factory.createStringLiteral(e.key) : ts.factory.createIdentifier(e.key), translateOutputAST(e.value))), true);
  }
  if (expr instanceof o.LiteralArrayExpr) return ts.factory.createArrayLiteralExpression(expr.entries.map(translateOutputAST), true);

  // Wrappers
  if (expr instanceof o.WrappedNodeExpr) return expr.node as ts.Expression;

  return ts.factory.createNull();
}

This proved to be error-prone and lacked sufficient coverage of edge cases. Through some digging into Angular source code, prompting Gemini to implement the visitor pattern was much more comprehensive.

import * as o from '@angular/compiler';
import * as ts from 'typescript';

export class AstTranslator implements o.ExpressionVisitor, o.StatementVisitor {
    // --- Non-exported or Version-Specific Expression Methods ---

    visitWritePropExpr(ast: any, context: any) {
        return ts.factory.createBinaryExpression(
            ast.receiver.visitExpression(this, context),
            ts.SyntaxKind.EqualsToken,
            ast.value.visitExpression(this, context)
        );
    }

    visitInvokeMethodExpr(ast: any, context: any) {
        return ts.factory.createCallExpression(
            ts.factory.createPropertyAccessExpression(
                ast.receiver.visitExpression(this, context),
                ast.name
            ),
            undefined,
            ast.args.map((a: any) => a.visitExpression(this, context))
        );
    }

    visitWriteKeyExpr(ast: any, context: any) {
        return ts.factory.createBinaryExpression(
            ts.factory.createElementAccessExpression(
                ast.receiver.visitExpression(this, context),
                ast.index.visitExpression(this, context)
            ),
            ts.SyntaxKind.EqualsToken,
            ast.value.visitExpression(this, context)
        );
    }

    visitTaggedTemplateLiteralExpr(ast: any, context: any) {
        const elements = ast.template.elements;
        const expressions = ast.template.expressions;

        const head = ts.factory.createTemplateHead(elements[0].text, elements[0].text);
        const spans = expressions.map((expr: any, i: number) => {
            const element = elements[i + 1];
            const literal = i === expressions.length - 1
                ? ts.factory.createTemplateTail(element.text, element.text)
                : ts.factory.createTemplateMiddle(element.text, element.text);
            return ts.factory.createTemplateSpan(expr.visitExpression(this, context), literal);
        });

        return ts.factory.createTaggedTemplateExpression(
            ast.tag.visitExpression(this, context),
            undefined,
            ts.factory.createTemplateExpression(head, spans)
        );
    }

    // --- Standard Expression Visitor Methods ---

    // Support Defer dependency tracking variables
    visitReadVarExpr(ast: o.ReadVarExpr, context: any) {
        return ts.factory.createIdentifier(ast.name);
    }

    visitReadPropExpr(ast: o.ReadPropExpr, context: any) {
        return ts.factory.createPropertyAccessExpression(ast.receiver.visitExpression(this, context), ast.name);
    }

    visitReadKeyExpr(ast: o.ReadKeyExpr, context: any) {
        return ts.factory.createElementAccessExpression(ast.receiver.visitExpression(this, context), ast.index.visitExpression(this, context));
    }

    visitLiteralExpr(ast: o.LiteralExpr, context: any) {
        if (typeof ast.value === 'string') {
            return ts.factory.createStringLiteral(ast.value);
        }
        if (typeof ast.value === 'number') {
            if (ast.value < 0) {
                return ts.factory.createPrefixUnaryExpression(
                    ts.SyntaxKind.MinusToken,
                    ts.factory.createNumericLiteral(Math.abs(ast.value).toString())
                );
            }
            return ts.factory.createNumericLiteral(ast.value.toString());
        }
        if (typeof ast.value === 'boolean') return ast.value ? ts.factory.createTrue() : ts.factory.createFalse();
        return ts.factory.createNull();
    }

    visitLiteralArrayExpr(ast: o.LiteralArrayExpr, context: any) {
        return ts.factory.createArrayLiteralExpression(
            ast.entries.map(e => {
                // Safety check: sometimes the compiler emits null entries for empty slots
                if (!e) return ts.factory.createNull();
                return e.visitExpression(this, context);
            }),
            true
        );
    }

    visitLiteralMapExpr(ast: o.LiteralMapExpr, context: any) {
        return ts.factory.createObjectLiteralExpression(
            ast.entries.map(e => ts.factory.createPropertyAssignment(
                e.quoted ? ts.factory.createStringLiteral(e.key) : ts.factory.createIdentifier(e.key),
                // Fix: Added safety check for null entries in metadata maps
                e.value ? e.value.visitExpression(this, context) : ts.factory.createNull()
            )),
            true
        );
    }

    // Ensure visitInvokeFunctionExpr is fully mapping all arguments for v21
    visitInvokeFunctionExpr(ast: o.InvokeFunctionExpr, context: any) {
        return ts.factory.createCallExpression(
            ast.fn.visitExpression(this, context),
            undefined,
            ast.args.map(a => a.visitExpression(this, context))
        );
    }

    visitInstantiateExpr(ast: o.InstantiateExpr, context: any) {
        return ts.factory.createNewExpression(ast.classExpr.visitExpression(this, context), undefined, ast.args.map(a => a.visitExpression(this, context)));
    }

    visitTemplateLiteralExpr(ast: o.TemplateLiteralExpr, context: any) {
        const headText = ast.elements[0].text;
        const head = ts.factory.createTemplateHead(headText, headText);
        const spans = ast.expressions.map((expr, i) => {
            const isLast = i === ast.expressions.length - 1;
            const content = ast.elements[i + 1].text;
            const literal = isLast ? ts.factory.createTemplateTail(content, content) : ts.factory.createTemplateMiddle(content, content);
            return ts.factory.createTemplateSpan(expr.visitExpression(this, context), literal);
        });
        return ts.factory.createTemplateExpression(head, spans);
    }

    visitBinaryOperatorExpr(ast: o.BinaryOperatorExpr, context: any) {
        const opMap: Record<o.BinaryOperator, ts.BinaryOperator> = {
            [o.BinaryOperator.Equals]: ts.SyntaxKind.EqualsEqualsToken,
            [o.BinaryOperator.NotEquals]: ts.SyntaxKind.ExclamationEqualsToken,
            [o.BinaryOperator.Assign]: ts.SyntaxKind.EqualsToken,
            [o.BinaryOperator.Identical]: ts.SyntaxKind.EqualsEqualsEqualsToken,
            [o.BinaryOperator.NotIdentical]: ts.SyntaxKind.ExclamationEqualsEqualsToken,
            [o.BinaryOperator.Minus]: ts.SyntaxKind.MinusToken,
            [o.BinaryOperator.Plus]: ts.SyntaxKind.PlusToken,
            [o.BinaryOperator.Divide]: ts.SyntaxKind.SlashToken,
            [o.BinaryOperator.Multiply]: ts.SyntaxKind.AsteriskToken,
            [o.BinaryOperator.Modulo]: ts.SyntaxKind.PercentToken,
            [o.BinaryOperator.And]: ts.SyntaxKind.AmpersandAmpersandToken,
            [o.BinaryOperator.Or]: ts.SyntaxKind.BarBarToken,
            [o.BinaryOperator.BitwiseOr]: ts.SyntaxKind.BarToken,
            [o.BinaryOperator.BitwiseAnd]: ts.SyntaxKind.AmpersandToken,
            [o.BinaryOperator.Lower]: ts.SyntaxKind.LessThanToken,
            [o.BinaryOperator.LowerEquals]: ts.SyntaxKind.LessThanEqualsToken,
            [o.BinaryOperator.Bigger]: ts.SyntaxKind.GreaterThanToken,
            [o.BinaryOperator.BiggerEquals]: ts.SyntaxKind.GreaterThanEqualsToken,
            [o.BinaryOperator.NullishCoalesce]: ts.SyntaxKind.QuestionQuestionToken,
            [o.BinaryOperator.Exponentiation]: ts.SyntaxKind.AsteriskAsteriskToken,
            [o.BinaryOperator.In]: ts.SyntaxKind.InKeyword,
            [o.BinaryOperator.AdditionAssignment]: ts.SyntaxKind.PlusEqualsToken,
            [o.BinaryOperator.SubtractionAssignment]: ts.SyntaxKind.MinusEqualsToken,
            [o.BinaryOperator.MultiplicationAssignment]: ts.SyntaxKind.AsteriskEqualsToken,
            [o.BinaryOperator.DivisionAssignment]: ts.SyntaxKind.SlashEqualsToken,
            [o.BinaryOperator.RemainderAssignment]: ts.SyntaxKind.PercentEqualsToken,
            [o.BinaryOperator.ExponentiationAssignment]: ts.SyntaxKind.AsteriskAsteriskEqualsToken,
            [o.BinaryOperator.AndAssignment]: ts.SyntaxKind.AmpersandAmpersandEqualsToken,
            [o.BinaryOperator.OrAssignment]: ts.SyntaxKind.BarBarEqualsToken,
            [o.BinaryOperator.NullishCoalesceAssignment]: ts.SyntaxKind.QuestionQuestionEqualsToken,
        };
        return ts.factory.createBinaryExpression(ast.lhs.visitExpression(this, context), opMap[ast.operator] ?? ts.SyntaxKind.PlusToken, ast.rhs.visitExpression(this, context));
    }

    visitConditionalExpr(ast: o.ConditionalExpr, context: any) {
        return ts.factory.createConditionalExpression(ast.condition.visitExpression(this, context), ts.factory.createToken(ts.SyntaxKind.QuestionToken), ast.trueCase.visitExpression(this, context), ts.factory.createToken(ts.SyntaxKind.ColonToken), ast.falseCase!.visitExpression(this, context));
    }

    visitNotExpr(ast: o.NotExpr, context: any) {
        return ts.factory.createPrefixUnaryExpression(ts.SyntaxKind.ExclamationToken, ast.condition.visitExpression(this, context));
    }

    visitTypeofExpr(ast: o.TypeofExpr, context: any) {
        return ts.factory.createTypeOfExpression(ast.expr.visitExpression(this, context));
    }

    visitUnaryOperatorExpr(ast: o.UnaryOperatorExpr, context: any) {
        const ops = { [o.UnaryOperator.Minus]: ts.SyntaxKind.MinusToken, [o.UnaryOperator.Plus]: ts.SyntaxKind.PlusToken };
        return ts.factory.createPrefixUnaryExpression(ops[ast.operator] ?? ts.SyntaxKind.PlusToken, ast.expr.visitExpression(this, context));
    }

    visitFunctionExpr(ast: o.FunctionExpr, context: any) {
        return ts.factory.createArrowFunction(undefined, undefined, ast.params.map(p => ts.factory.createParameterDeclaration(undefined, undefined, p.name)), undefined, ts.factory.createToken(ts.SyntaxKind.EqualsGreaterThanToken), ts.factory.createBlock(ast.statements.map(s => s.visitStatement(this, context)), true));
    }

    visitArrowFunctionExpr(ast: o.ArrowFunctionExpr, context: any) {
        return ts.factory.createArrowFunction(undefined, undefined, ast.params.map(p => ts.factory.createParameterDeclaration(undefined, undefined, p.name)), undefined, ts.factory.createToken(ts.SyntaxKind.EqualsGreaterThanToken), ast.body.visitExpression(this, context));
    }

    visitDynamicImportExpr(ast: o.DynamicImportExpr, context: any) {
        return ts.factory.createCallExpression(ts.factory.createToken(ts.SyntaxKind.ImportKeyword) as any, undefined, [ast.url.visitExpression(this, context)]);
    }

    visitParenthesizedExpr(ast: o.ParenthesizedExpr, context: any) {
        return ts.factory.createParenthesizedExpression(ast.expr.visitExpression(this, context));
    }

    visitCommaExpr(ast: o.CommaExpr, context: any) {
        return ast.parts.map(p => p.visitExpression(this, context)).reduce((p, c) => ts.factory.createBinaryExpression(p, ts.SyntaxKind.CommaToken, c));
    }

    visitVoidExpr(ast: o.VoidExpr, context: any) {
        return ts.factory.createVoidExpression(ast.expr.visitExpression(this, context));
    }

    visitLocalizedString(ast: o.LocalizedString, context: any) {
        throw new Error('i18n is not supported');
    }

    visitRegularExpressionLiteral(ast: o.RegularExpressionLiteralExpr, context: any) {
        return ts.factory.createRegularExpressionLiteral(`/${ast.pattern}/${ast.flags}`);
    }

    visitTemplateLiteralElementExpr(ast: o.TemplateLiteralElementExpr, context: any) {
        return ts.factory.createStringLiteral(ast.text);
    }

    visitWrappedNodeExpr(ast: o.WrappedNodeExpr<any>, context: any) {
        // This is how Angular passes back original TS nodes (like Signal calls)
        // into the generated code.
        return ast.node as ts.Expression;
    }

    visitExternalExpr(ast: o.ExternalExpr, context: any) {
        return ts.factory.createPropertyAccessExpression(ts.factory.createIdentifier('i0'), ts.factory.createIdentifier(ast.value.name!));
    }

    // --- Statement Visitor Methods ---

    visitDeclareVarStmt(stmt: o.DeclareVarStmt, context: any) {
        return ts.factory.createVariableStatement(undefined, ts.factory.createVariableDeclarationList([ts.factory.createVariableDeclaration(stmt.name, undefined, undefined, stmt.value ? stmt.value.visitExpression(this, context) : undefined)], stmt.hasModifier(o.StmtModifier.Final) ? ts.NodeFlags.Const : ts.NodeFlags.Let));
    }

    visitDeclareFunctionStmt(stmt: o.DeclareFunctionStmt, context: any) {
        return ts.factory.createFunctionDeclaration(undefined, undefined, stmt.name, undefined, stmt.params.map(p => ts.factory.createParameterDeclaration(undefined, undefined, p.name)), undefined, ts.factory.createBlock(stmt.statements.map(s => s.visitStatement(this, context)), true));
    }

    visitExpressionStmt(stmt: o.ExpressionStatement, context: any) {
        return ts.factory.createExpressionStatement(stmt.expr.visitExpression(this, context));
    }

    visitReturnStmt(stmt: o.ReturnStatement, context: any) {
        return ts.factory.createReturnStatement(stmt.value.visitExpression(this, context));
    }

    visitIfStmt(stmt: o.IfStmt, context: any) {
        return ts.factory.createIfStatement(stmt.condition.visitExpression(this, context), ts.factory.createBlock(stmt.trueCase.map(s => s.visitStatement(this, context)), true), stmt.falseCase.length ? ts.factory.createBlock(stmt.falseCase.map(s => s.visitStatement(this, context)), true) : undefined);
    }
}

Example: From Source to Ivy Output

Here is a sample standalone component using Signals and its actual compiled Ivy output. Note how the @Component decorator is replaced by static properties that use imperative instructions like ɵɵelementStart and ɵɵtext.

Input Source

import { Component, computed, input, signal } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    Count: {{ count() }}

    <button (click)="increment()">Increment</button>
        <button (click)="decrement()">Decrement</button>

        @if(show()) {
            <div>Hello {{ name() }}</div>
        }
  `
})
export class Counter {
    name = input();
  count = signal(0);
    show = computed(() => this.count() > 5);

  increment() {
    this.count.update(cnt => ++cnt);
  }

  decrement() {
    this.count.update(cnt => --cnt);
  } 
}

Actual Ivy Output

import*as i0 from "/node_modules/.vite/deps/@angular_core.js?v=0f32e3a9";
import {computed, input, signal} from "/node_modules/.vite/deps/@angular_core.js?v=0f32e3a9";
export class Counter {
    constructor() {
        this.name = input();
        this.count = signal(0);
        this.show = computed( () => this.count() > 5);
    }
    increment() {
        this.count.update( (cnt) => ++cnt);
    }
    decrement() {
        this.count.update( (cnt) => --cnt);
    }
    static{this.ɵfac = (__ngFactoryType__) => {
        return new (__ngFactoryType__ || Counter)();
    }
    ;
    }static{this.ɵcmp = i0.ɵɵdefineComponent({
        type: Counter,
        selectors: [["app-counter"]],
        inputs: {
            name: [3, "name", "name", null]
        },
        decls: 6,
        vars: 2,
        consts: [[3, "click"]],
        template: (rf, ctx) => {
            if (rf & 1) {
                i0.ɵɵtext(0);
                i0.ɵɵdomElementStart(1, "button", 0);
                i0.ɵɵdomListener("click", () => {
                    return ctx.increment();
                }
                );
                i0.ɵɵtext(2, "Increment");
                i0.ɵɵdomElementEnd();
                i0.ɵɵdomElementStart(3, "button", 0);
                i0.ɵɵdomListener("click", () => {
                    return ctx.decrement();
                }
                );
                i0.ɵɵtext(4, "Decrement");
                i0.ɵɵdomElementEnd();
                i0.ɵɵconditionalCreate(5, Counter_Conditional_5_Template, 2, 1, "div");
            }
            if (rf & 2) {
                i0.ɵɵtextInterpolate1(" Count: ", ctx.count(), " ");
                i0.ɵɵadvance(5);
                i0.ɵɵconditional(ctx.show() ? 5 : -1);
            }
        }
        ,
        encapsulation: 2
    });
    }
}
function Counter_Conditional_5_Template(rf, ctx) {
    if (rf & 1) {
        i0.ɵɵdomElementStart(0, "div");
        i0.ɵɵtext(1);
        i0.ɵɵdomElementEnd();
    }
    if (rf & 2) {
        const ctx_r0 = i0.ɵɵnextContext();
        i0.ɵɵadvance();
        i0.ɵɵtextInterpolate1("Hello ", ctx_r0.name());
    }
}

It's Just the Beginning

There's so much more to learn about the Angular compiler, including registering and linking components, directives, pipes, and injectables, handling complex control flow syntax, providers, and more. Angular's compilation still needs global analysis of its dependencies in order to generate the correct output for templates. This is what makes selectorless pretty important if the Angular team continues to explore the direction towards true single file compilation. Using Gemini as a research tool helped me understand the internals of Angular Compiler APIs, generate working code that was understandable for a prototype, and provided a feedback loop for understanding and fixing errors.

Check out the GitHub repo: https://github.com/brandonroberts/angular-compiler-gemini

I'm looking forward to iterating on this more, as it gave me much more clarity, having implemented Analog SFCs as a translation layer to an Angular component.

If you enjoyed this post, click the ❤️ so other people will see it. Follow AnalogJS and me on Twitter/X, and subscribe to my YouTube Channel for more content!

DEV Community: Brandon Roberts

AnalogJS 2.7: Server Functions, Streaming SSR, Agent-Ready Projects, and more!

Server Functions 🚀

Defining a Server Function

Calling a Server Function

Interceptors

Security by default

Streaming SSR (experimental) 🌊

Agent-Ready Projects 🤖

Stricter Template Checking in Tests ✅

Upgrading

Partner with Analog 🤝

Join the Community 🥇

Choosing Angular in the Age of Agents

Where Angular Actually Sat

The Thing Angular Was Always Good At

Why That Matters More With Agents

Vibe Coders Building Safely

What the Roadmap Says

So Should You Choose Angular?

Distributing AnalogJS CI with Nx Agents and One Prompt

The starting point

One prompt

The result

Conclusion

Angular Compilation, Type-Checking, and Build Bottlenecks

How Angular compilation works

Four pipelines, two architectures

Webpack + @ngtools/webpack (whole-program AOT, legacy)

Angular application builder (whole-program AOT, esbuild — the modern default)

AnalogJS fastCompile (per-file transpile)

Oxc Angular Compiler (experimental, Rust — per-file transpile)

The numbers

What per-file compilers still need

What the gap comes down to

Conclusion

Looking ahead: a native type-checker

Deploying Angular applications to Cloudflare with Void

Creating a new Angular application

Installing Void

Configuring the build for Void

Deploying

Shaping requests at the edge

Deploying from CI

Adding a custom domain

Conclusion

Using Cypress Component Testing with Angular and Vite

Installing the Vite plugin

Configuring Cypress

Updating the support file

Configuring TypeScript

Running tests

Conclusion

AnalogJS 2.5: Runtime i18n, Fast Compilation Mode, Hierarchical Content, and more!

Runtime i18n 🌍

Setup

Message Extraction

Switching Locales

Fast Compilation Mode ⚡️

Hierarchical Content 📚

Slash-containing slugs

Recursive prerendering

AI Integrations Guide 🤖

Upgrading

Partner with Analog 🤝

Join the Community 🥇

AnalogJS 2.4: Vite 8, Vitest Snapshot Serializers, Astro v6 Support, and more!

Vite 8 Support ⚡️

Vitest DX Improvements 🧪

Reusable Snapshot Serializers

teardown.destroyAfterEach Option

Astro v6 Support & Strict Style Placement 🚀

Astro v6 Compatibility

strictStylePlacement Option

Upgrading

Partner with Analog 🤝

Join the Community 🥇

Using a Headless CMS with Angular and Analog Content Loaders

Understanding the Default Content System

The Content Loader Tokens

Webpack + `@ngtools/webpack` (whole-program AOT, legacy)

`teardown.destroyAfterEach` Option

`strictStylePlacement` Option