DEV Community: Brandon Roberts

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 🤝

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, Nx, and House of Angular, 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!

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!

Announcing AnalogJS 2.0 ⚡️

Brandon Roberts — Mon, 03 Nov 2025 15:20:19 +0000

We're excited to announce the 2.0 release of AnalogJS! This release includes many features that help developers ship websites and applications, faster, with Angular.

This release marks the second major release of Analog, providing developers many new features and improvements to build with Analog.

Features ⭐️

Analog is the meta-framework built on top of Angular, powered by Vite, a next generation open-source build tool, and Nitro, an open-source server engine framework. Here are some of its features, including:

First-class support for the Vite ecosystem (Vitest, Playwright, Storybook, and more)
Filesystem-based routing
Support for markdown pages and blogs
Support for API/server routes
Hybrid SSR/SSG with sitemap and RSS feed support
Supports Angular CLI/Nx workspaces
Server and deployment support
And more!

What's New

Analog 2.0 contains many new features including content resources, smaller install and bundle size optimizations, and Vite ecosystem upgrades.

Content Resources 📜

As Angular continues to evolve with the introduction of Resources, Analog now also includes resources for displaying content lists and content files.

Content Files resources are used to display lists of loaded content.

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

import { PostsComponent } from '../../components/posts';
import { Post } from '../../data/posts';

@Component({
  selector: 'blog-posts',
  imports: [Posts],
  template: `
    @defer(hydrate on hover) {
      <posts [posts]="postsResource.value()"></posts>
    }
  `
})
export default class Blog {
 readonly postsResource = contentFilesResource<Post>();
}

Content file resources retrieve content as a signal, integrating with Angular's latest primitives for reactivity.

import { Component } from '@angular/core';
import { MarkdownComponent } from '@analogjs/content';
import { contentFileResource } from '@analogjs/content/resources';
import { RouteMeta } from '@analogjs/router';

import { Post } from '../../data/posts';
import { postMetaResolver, postTitleResolver } from './resolvers';

export const routeMeta: RouteMeta = {
  title: postTitleResolver,
  meta: postMetaResolver,
};

@Component({
  selector: 'post',
  imports: [MarkdownComponent],
  template: `
    @let post = postResource.value();

    @if (post) {
      <div class="flex flex-grow justify-center min-h-screen">
        <article class="w-screen max-w-4xl p-8">
          <h2 class="text-gray-600 text-2xl">{{ post.attributes.title }}</h2>

          <span class="font-light text-sm">
            {{ post.attributes.publishedDate }} -
            {{ post.content }} min read
          </span>

          <analog-markdown [content]="post.content"></analog-markdown>
        </article>
      </div>
    }
  `
})
export default class BlogPost {
  readonly postResource = contentFileResource<Post>();
}

As Resources are still experimental in Angular, there will be future updates, and we're looking to further support these new APIs in Analog.

Installation and Bundle Size Optimizations 📦

We've continued to improve Analog projects, including installing project dependencies and optimizing bundle sizes. A few changes include:

Smaller install footprint for Angular CLI workspaces without any Webpack dependencies.
All Angular builders are shipped as ESM.
Replacing packages with smaller equivalents, such as using tinyglobby instead of fast-glob.
Direct usage of the Vite CLI for serve/build in addition to ng serve
Direct usage of the Vitest CLI for testing in addition to ng test
Generated bundle output size reduction of 100Kb+ for full-stack projects.

These optimizations decrease the installation time of Analog projects in development, and reduce the amount of code built and shipped.

Vite Ecosystem Upgrades ⚡️

Analog continues to integrate and support many Vite ecosystem integrations:

Angular v17-v20 with upcoming support for Angular v21
Vite 6.x and 7.x, including support for the latest Rolldown-Vite releases
Vitest 3.x and 4.x including support for the Vitest VSCode extension
Nx 22.x
Storybook 10.x, including support for component testing with Vitest
Astro 5.x

Angular support for Vitest 🧪

In Angular v21, stable support for Vitest directly through the Angular CLI was introduced for new Angular projects. While both Analog and Angular support running tests with Vitest, there are some similarities and key differences.

The table below shows the features available across both choices.

Vitest	Analog	Angular
Angular Versions	v17+	v21+
Vitest Versions	2.0+	4.0+
Support	Community	Angular Team
Builders	✅	✅
Schematics	✅	✅
Migrations	✅	✅
Fully Configurable	✅	⚠️
Vitest CLI	✅	❌
Vitest Workpsaces	✅	❌
Custom Environments	✅	❌
Custom Providers	✅	❌
IDE extensions	✅	❌
Buildable Libs	✅	❌
Module Mocking/Graph	✅	❌
Plugins/Types	✅	❌

The table above is not to compare the two solutions, but to provide the information on what features are supported by each implementation. Choose the solution that best fits your needs and priorities.

Check out our guide on how you can add Vitest to any existing Angular project.

Contributions and Community 🤓

AnalogJS would not be where it is without a team of core contributors and collaborators.

Robin Goetz
Marko Stanimirović
Luis Castro
Chau Tran
Joshua Morony
Andrés Villanueva

Also, thanks to the 150+ contributors to the project, whether through code, documentation, tests, or even just trying out the project.

The project already has nearly 3000 stars on GitHub, 1000+ members on Discord, 1000+ followers on Twitter/X, and was accepted into the first GitHub Accelerator Cohort.

Partner with Analog 🤝

Continued development of Analog would not be possible without our partners and community. Thanks to our official deployment partner Zerops and longtime supporters Snyder Technologies, Nx, and House of Angular, 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 me on Twitter/X, and subscribe to my YouTube Channel for more content!

Announcing NgRx 19: NgRx Signals Features, Action Signals, and more!

Brandon Roberts — Thu, 19 Dec 2024 17:22:37 +0000

We are pleased to announce the latest major version of the NgRx framework with some exciting new features, bug fixes, and other updates.

Updated NgRx Signals Features🚦

The NgRx Signals was released as stable in v18 as a new library built from the ground up with Angular Signals, opt-in RxJS interoperability, and entity management out of the box. the NgRx Signals library has continued to receive quality updates and improvements to enhance the developer experience.

New Props SignalStore Feature

One highly requested feature was the ability to define props for a SignalStore during its creation. To support this, the withProps base feature was added to allow static properties or observables to be defined as SignalStore members.

export const BooksStore = signalStore(
  withEntities<Book>(),
  withRequestStatus(),
  withProps(({ isFulfilled }) => ({
    fulfilled$: toObservable(isFulfilled).pipe(filter(Boolean)),
  })),
);

It can also be used for defining all dependencies in a single place:

export const MyStore = signalStore(
  withProps(() => ({
    service1: inject(Service1),
    service2: inject(Service2),
  })),
  withMethods(({ service1, service2 }) => ({
    method1() {
      service1.foo();
    },
    method2() {
      service2.bar();
    },
  }))
);

The new withProps feature integrates together with new Angular Signals features including resource and linkedSignal:

const booksStore = signalStore(
  withProps(() => {
    const bookResource = resource({
      loader: () => Promise.resolve({ id: 1, title: "'Lord of the Rings' }),"
    });
    return {
      _bookResource: bookResource,
      bookResource: bookResource.asReadonly(),
    };
  }),
);

The above exposes bookResource as readonly resource, and keeps the writable resource.

The next example exposes prettyTitle as linkedSignal, and keeps the writable state internally.

signalStore(
  withState({ id: 1, title: "'Lord of the Rings' }),"
  withProps((store) => ({
    prettyTitle: linkedSignal(() => \`${store.id()}: ${state.store()}\`),
  })),
);

The new withProps features allows you customize and extend the SignalStore even further with Angular Signals. Thanks to Marko Stanimirović for his continued work on improving NgRx Signals!

Signal Method Utility Function

The rxMethod utility function was introduced to provide a way to connect async work done with RxJS to Angular Signals. We've also introduced the signalMethod utility function that gives you the same benefits of rxMethod with the ability to use only use signals.

signalMethod is a factory function that processes side effects on signals or static values.

import { Component } from '@angular/core';
import { signalMethod } from '@ngrx/signals';

@Component({ /* ... */ })
export class NumbersComponent {
  // 👇 This method will have an input argument
  // of type `number | Signal<number>`.
  readonly logDoubledNumber = signalMethod<number>((num) => {
    const double = num * 2;
    console.log(double);
  });
}

At first sight, signalMethod, might look the same as an effect. However, signalMethod offers three distinctive advantages over effect:

@Component({ /* ... */ })
export class NumbersComponent {
  readonly num = signal(2);
  readonly logDoubledNumberEffect = effect(() => {
    console.log(this.num() * 2);
  });
  readonly logDoubledNumber = signalMethod<number>((num) => {
    console.log(num * 2);
  });

  constructor() {
    this.logDoubledNumber(this.num);
  }
}

Flexible Input: The input argument can be a static value, not just a signal. Additionally, the processor function can be called multiple times with different inputs.
No Injection Context Required: Unlike an effect, that requires an injection context or an Injector, signalMethod's "processor function" can be called without an injection context.
Explicit Tracking: Only the Signal of the parameter is tracked, while Signals within the "processor function" stay untracked.

Read the docs to learn more about signalMethod.

Development Mode Checks for State Mutations

Ensuring that state updates are immutable is crucial for Signal to emit correctly and trigger necessary DOM updates, derived signals, or side effects. To mitigate this issue the patchState function applies a deep freeze on the state in development mode.

Before:

const userState = signalState(initialState);
patchState(userState, (state) => {
  state.user.firstName = 'mutable change'; // mutable change which went through
  return state;
});

After:

const userState = signalState(initialState);
patchState(userState, (state) => {
  state.user.firstName = 'mutable change'; // throws in dev mode
  return state;
});

This ensures that state changes remain immutable, providing a path to retaining performance and best practices.

NgRx Store Support for Dispatching Actions on Signal changes

NgRx Store remains the defacto choice for global state management within Angular applications. NgRx Store previously introduced support for selecting state as a signal, and now introduces an ergonomic way to dispatch actions that read signals.

class BookComponent {
  bookId = input.required<number>();

  constructor(store: Store) {
    store.dispatch(() => loadBook({ id: this.bookId() })));
  }
}

The dispatch method executes initially and every time the bookId changes. If dispatch is called within an injection context, the signal is tracked until the context is destroyed. In the example above, that would be when BookComponent is destroyed.

When dispatch is called outside a component's injection context, the signal is tracked globally throughout the application's lifecycle. To ensure proper cleanup in such a case, provide the component's injector to the dispatch method:

class BookComponent {  
  bookId = input.required<number>();
  injector = inject(Injector);
  store = inject(Store);

  ngOnInit() {
    // runs outside the injection context
    this.store.dispatch(
      () => loadBook({ id: this.bookId() }),
      { injector: this.injector }
    );
  }
}

Thanks to Rainer Hahnekamp for adding these features!

NgRx Signals, the new Default 🤝

NgRx Signals is a ground-up approach to managing state reactively, and is opt-in for RxJS usage. It also has other utilities for working with Angular Signals in a structured way that helps developers scale up. NgRx Signals is now the recommended local state management library to integrate into your Angular applications. For new applications, start with NgRx SignalStore. For existing applications, consider migrating to the new @ngrx/signals package.

NgRx Workshops 🎓

With NgRx usage continuing to grow with Angular, many developers and teams still need guidance on how to architect and build enterprise-grade Angular applications. We are excited to introduce upcoming workshops provided directly by the NgRx team!

Starting in Feburary, we will offer one to three full-day workshops that cover the basics of NgRx to the most advanced topics. Whether your teams are just starting with NgRx or have been using it for a while - they are guaranteed to learn new concepts during these workshops.

The workshop covers both global state with NgRx Store and libraries, along with managing local state with NgRx ComponentStore and NgRx Signals.

Visit our workshops page to sign up from our list of upcoming workshops.

New Docs site 💅

The new docs revamp is underway and is built up from scratch using AnalogJS and will have a brand-new design and revamped content. This will make sure to offer the best possible experience to our users and make it easier to find the information you need. It also ensures that the website will become easier to maintain and update. Because we're a community-driven project, we're keeping in mind that the website should be easy to contribute to.

Thanks to Mike Ryan for his work on the new version of the NgRx website.

Deprecations and Breaking Changes 💥

This release contains bug fixes, deprecations, and breaking changes. For most of these deprecations or breaking changes, we've provided a migration that automatically runs when you upgrade your application to the latest version.

Take a look at the version 19 migration guide for complete information regarding migrating to the latest release. The complete CHANGELOG can be found in our GitHub repository.

Upgrading to NgRx 19 🗓️

To start using NgRx 19, make sure to have the following minimum versions installed:

Angular version 19.x
Angular CLI version 19.x
TypeScript version 5.5.x
RxJS version ^6.5.x or ^7.5.x

NgRx supports using the Angular CLI ng update command to update your NgRx packages. To update your packages to the latest version, run the command:

ng update @ngrx/store@19

If your project uses @ngrx/signals, run the following command:

ng update @ngrx/signals@19

Swag Store and Discord Server 🦺

You can get official NgRx swag through our store! T-shirts with the NgRx logo are available in many different sizes, materials, and colors. We will look at adding new items to the store such as stickers, magnets, and more in the future. Visit our store to get your NgRx swag today!

Join our Discord server for those who want to engage with other members of the NgRx community, old and new.

Contributing to NgRx 🥰

We're always trying to improve the docs and keep them up-to-date for users of the NgRx framework. To help us, you can start contributing to NgRx. If you're unsure where to start, come take a look at our contribution guide and watch the introduction video Jan-Niklas Wortmann and Brandon Roberts have made to help you get started.

Thanks to all our contributors and sponsors!

NgRx continues to be a community-driven project. Design, development, documentation, and testing all are done with the help of the community. Visit our community contributors section to see every person who has contributed to the framework.

If you are interested in contributing, visit our GitHub page and look through our open issues, some marked specifically for new contributors. We also have active GitHub discussions for new features and enhancements.

We want to give a big thanks to our Gold sponsor, Nx! Nx has been a longtime promoter of NgRx as a tool for building Angular applications, and is committed to supporting open source projects that they rely on.

We also want to thank our Bronze sponsor, House of Angular!

DEV Community: Brandon Roberts

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

Fetching Custom Content at Build Time

Creating a Vite Plugin

Adding Types for the Virtal Module

Custom Loaders with Build-Time Data

Configuring Vite and Prerender Routes

Using the Content in Components

Angular Skills: Agent Skills for AI-Assisted Development

What Are Skills?

Installing Angular Skills

Available Skills

angular-component

angular-signals

angular-di

angular-forms

angular-http

angular-routing

angular-directives

angular-ssr

angular-testing

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

`teardown.destroyAfterEach` Option

`strictStylePlacement` Option