DEV Community: Alex

A year of the EAA — does your component library's CI catch a11y violations yet?

Alex — Mon, 22 Jun 2026 14:51:14 +0000

The EAA is one year into enforcement, and most component libraries still ship without a single automated a11y check. Here is how I closed that gap in an Angular workspace, on two levels — live during development, and as a hard fail in CI.

A year in, and we are still flying blind

This week marks one year since the European Accessibility Act became enforceable on 28 June 2025. Member states started accepting complaints. Market surveillance authorities started asking questions. And a lot of teams that had been treating "we'll do an a11y pass before launch" as a strategy noticed, quietly, that there was no launch — there was a constant trickle of releases, and the a11y pass had never actually happened.

Component libraries are where this hits first. They ship dozens or hundreds of building blocks, every one of them potentially the thing that makes your product fail an audit. Ask yourself, honestly: how many components in your design system pass axe-core against WCAG 2.2 AA today? You don't know. Your CI doesn't know either.

This post is about how to fix that for an Angular library — on two layers, both wired into the same tool, and both runnable in under an hour of setup.

The two-layer model

There are two distinct moments where a11y feedback should land for a component library:

Dev-time. When I'm building a component variant, I want to see a11y violations as they happen, against the exact variant I'm rendering, without leaving my workflow.
CI-time. When a PR opens, I want every variant of every component re-audited and the build to fail loudly if the library regresses past a threshold.

These are not the same job. Dev-time is about catching cheaply. CI-time is about holding the line. You want both, and the tool I'll show — ng-prism, an Angular-native component showcase — wires both into the same workspace.

Layer 1: Live a11y in the component lab

ng-prism is a showcase tool similar in spirit to Storybook, but built around Angular's component model — I wrote about why I built it in an earlier post. You put @Showcase on a component, ng-prism scans your library, and you get a styleguide app with controls, theming, panels — and an A11y panel built into the core.

The panel runs axe-core against the rendered variant every time the variant or any input changes. It has four tabs:

Violations — the live axe-core report, sorted by impact (critical, serious, moderate, minor), with a score ring that updates in real time.
Keyboard — tab-order overlay, focus trap detection, missing-tabindex warnings.
ARIA Tree — the component's accessible tree as the browser sees it, with the computed accessible names.
Screen Reader — what a screen reader would announce, as a list or step-through player with a "screen-reader perspective" toggle that dims the canvas so you stop seeing what users don't.

You don't add a plugin to get this. It comes with @ng-prism/core. The only thing you ship into your workspace is axe-core as a peer dependency.

When a component needs a per-component override — a decorative icon that should not be audited, or a rule you know is wrong for this widget — you tag the showcase config:

@Showcase({
  title: 'Toast',
  meta: {
    a11y: {
      rules: {
        'color-contrast': { enabled: false },
      },
    },
  },
})
export class ToastComponent { /* ... */ }

This is the cheap layer. It catches the issues that would otherwise survive review because nobody pulled up DevTools and ran axe by hand. But the moment a contributor doesn't open the panel, the issue ships. That is what Layer 2 is for.

Layer 2: a CI step that fails loud

Here is the design call I want to spend a minute on: ng-prism does not ship a built-in audit CLI. I tried that, and pulled it out.

Component libraries live in different stacks. Some teams already have Playwright. Some run @axe-core/cli in a Docker step. Some have a custom headless harness for visual regression and want a11y bolted onto the same browser session. A built-in CLI would either lock teams into one of those, or balloon into a config surface that mirrors every option of all of them.

So instead of a CLI, ng-prism exposes a small contract — call it the External Audit API — and lets your team bring its own auditor. The contract has three anchors:

Anchor	What it is	Why
`window.__PRISM_MANIFEST__`	A global with `{ components: [{ className, variants: [{ name, index }] }], pages: [...] }` set by the running app.	Discovery. The auditor needs to know what to audit.
`?component=<className>&variant=<index>`	URL params the app reads on navigation.	Drive the app to a specific variant from the outside.
`[data-prism-rendered="<className>:<index>"]` on `.demo-wrap`	An attribute on the renderer host.	Render-completion marker — wait for this to flip before injecting axe.

A working auditor against this contract is small. Here is the core loop in Playwright (adapted from the real script I run against my own library, ~250 lines total including a tiny static server and threshold checks):

await page.goto(baseUrl, { waitUntil: 'networkidle' });
await page.waitForFunction(() => globalThis.__PRISM_MANIFEST__);
const manifest = await page.evaluate(() => globalThis.__PRISM_MANIFEST__);

for (const comp of manifest.components) {
  for (const variant of comp.variants) {
    const url = new URL(baseUrl);
    url.searchParams.set('component', comp.className);
    if (variant.index > 0) url.searchParams.set('variant', String(variant.index));

    await page.goto(url.toString(), { waitUntil: 'load' });
    await page.waitForFunction(
      ([key]) =>
        document
          .querySelector('.demo-wrap')
          ?.getAttribute('data-prism-rendered')
          ?.startsWith(key),
      [`${comp.className}:`]
    );

    await page.addScriptTag({ content: axeSource });
    const { violations } = await page.evaluate(async () => {
      const target = document.querySelector('.demo-wrap');
      const r = await globalThis.axe.run(target);
      return { violations: r.violations };
    });

    results.push({ className: comp.className, variant: variant.name, violations });
  }
}

The script writes an aggregated a11y-report.json at the end. ng-prism reads that file at build time and embeds the totals into the runtime manifest, so a coloured pill (green/orange/red) appears in the styleguide header — visible to anyone reviewing a deployed PR preview.

The thresholds live in your prism config:

// ng-prism.config.ts
import { defineConfig } from '@ng-prism/core';

export default defineConfig({
  a11y: {
    reportPath: 'a11y-report.json',
    thresholds: {
      score: 85,
      critical: 0,
      serious: 0,
      moderate: 5,
    },
  },
});

If the report breaches any threshold, the build fails. Not a warning, not a soft error — the pipeline goes red, the PR cannot merge.

Putting it in CI

The three steps for a GitHub Actions job (adapt to your runner of choice):

- run: npx nx run my-lib-prism:build       # 1. build the prism app
- run: npx nx run my-lib:audit-a11y        # 2. your audit script writes a11y-report.json
- run: npx nx run my-lib-prism:build       # 3. re-build to embed the report into the manifest

Two builds, because the report is generated against the first build and embedded by the second. The header pill renders only after step 3 — useful if you deploy PR previews, because reviewers can see the a11y score next to the components without clicking through every panel.

The audit step is your own script. If you don't want to write one, the Playwright snippet above plus argument parsing and threshold checks is roughly 200–250 lines and lives in scripts/. It's yours, in your repo, in JS or TS you can edit when your CI changes.

Why this fits Angular libraries specifically

A small note on tooling fit, because Angular libraries have one constraint that bites tooling all the time: dialogs and overlays. CDK Overlay, MatDialog, anything that portals to the body — they break in iframe-based component labs. ng-prism renders components directly into the host document via ViewContainerRef.createComponent(), so overlays land where they should, and the a11y audit sees them as real DOM. That matters because most of the WCAG violations I catch are in dialogs and floating UI — exactly the surfaces other tools tend to miss.

Beyond that: signal inputs and outputs work natively, the showcase config is just a decorator on the component (no separate story file), and a11y is in the core — not behind a plugin you have to remember to install.

Try it

ng add @ng-prism/core

Then add @Showcase to a component, run the prism builder, open the A11y panel, and watch the score ring move when you change a variant. From there, the External Audit API documented in docs/guide/accessibility.md is enough to write the CI script in an afternoon.

The repo: github.com/dyingangel666/ng-prism. If this post saved your team a CI compliance scramble, a star is appreciated — and issues, PRs, and "this works / this doesn't" reports are very welcome.

A year of the EAA is enough. Stop shipping component libraries that can't tell you their own a11y score.

Why I think Component-Driven Development needs a rethink in the Signal era

Alex — Mon, 18 May 2026 13:23:59 +0000

Component-Driven Development assumed a render model that signal-based Angular has quietly left behind. The tooling has not caught up, and I am not sure simply patching it will be enough.

The moment that made me write this

I was building ng-prism, an Angular-native component showcase tool I maintain, and I needed to update a component's inputs from a controls panel. The naive version looked roughly like this:

const ref = vcr.createComponent(ButtonComponent);
const instance = ref.instance;

instance.variant = 'primary';
instance.label  = 'Save';
ref.changeDetectorRef.detectChanges();

It works on a pre-signal component. On a signal-based component it quietly breaks the component. variant and label are no longer plain properties. They are InputSignal objects, callable as variant(). Angular stores the InputSignal as a plain class field; there is no defineProperty setter or proxy to intercept the write. So the assignment just overwrites the field reference with a string, and Angular never finds out. The next render then blows up the first time the template evaluates variant(), because variant is no longer a function. I verified this against @angular/core 21.2.0: createInputSignal() returns a plain function with a [SIGNAL] symbol attached, no setter trap in sight.

The fix is one line:

ref.setInput('variant', 'primary');
ref.setInput('label',   'Save');

That is the version that lives in ng-prism today, in the renderer effect that drives every showcase:

// packages/ng-prism/src/app/renderer/prism-renderer.component.ts
// Simplified; real version also handles content projection and unknown-input warnings.
effect(() => {
  const inputs = this.rendererService.inputValues();
  const ref    = this.componentRef;
  if (!ref) return;

  performance.mark('prism:rerender:start');
  for (const [key, value] of Object.entries(inputs)) {
    ref.setInput(key, value);
  }
  // setInput() already marks dirty and schedules CD. The explicit
  // detectChanges() here forces it to run synchronously so the
  // performance.mark below wraps the actual render, not just the
  // dirty-marking. Also keeps timings predictable under zoneless.
  ref.changeDetectorRef.detectChanges();
  performance.mark('prism:rerender:end');
});

This is a tiny detail, but it is the symptom of a much bigger thing. The way Component-Driven Development (CDD) thinks about a component (props in, render out, args table on the side) was modelled on a world where component inputs were plain properties. That world is gone in Angular. And once you stop assuming it, a lot of the tooling we have built over the last decade starts to look like it is solving the wrong problem.

The implicit model behind classic CDD

Look at what almost every CDD tool, Storybook included, has agreed on for years:

A component is a pure-ish function of its inputs.
Inputs are configured as a flat dictionary, the “args”.
A “story” is a specific value of that dictionary.
Changing args triggers a discrete re-render cycle.
Addons (a11y, viewport, knobs, controls) hook into that cycle.

In the pre-Hooks era this was the right abstraction. React class components had setState. Angular had @Input() decorators and ngOnChanges. Vue had options API. All of them had a clear, discrete moment where a property got assigned, the framework noticed, and the component re-rendered top-down. Args tables map onto that perfectly. Whatever knob you turn becomes a property assignment, which becomes an ngOnChanges call, which becomes a render.

This is also why Storybook’s args model felt so natural for so long. Args are properties. Properties are state. State drives render. Story = scenario = property snapshot.

It was a beautiful, simple model. It is also, for Angular today, the wrong abstraction.

What Signals actually changed

I do not want to retread the “signals are great” territory. What matters for CDD is more specific.

Inputs are no longer properties. An InputSignal is a callable getter. From outside the component, the only correct way to push a value into it is ComponentRef.setInput(name, value). There is no property to assign anymore. Tools that still build their abstractions on “assign this prop” are not even wrong yet, they just produce broken components.

Components are nodes in a reactive graph, not pure functions of inputs. Half of a real-world signal-based component is computed() derived state. Those derived signals are part of the component’s behaviour. They are not inputs, but they are also not opaque internal state. An args table cannot represent them. A story shapes inputs, not derived state.

Lifecycle work is increasingly split between explicit hooks and reactive subscriptions. ngOnInit and ngOnDestroy still exist and are still idiomatic for a lot of cases (subscriptions, teardown, one-shot setup). What has changed is that ngOnChanges is largely irrelevant for signal inputs, and a growing share of the work that used to live in lifecycle hooks now lives inside effect() or computed() that is read by the template. The places where work happens have multiplied, and a chunk of it fires on a much finer-grained schedule than mount → change → destroy. CDD tools that visualise lifecycle as those three states are visualising a real but shrinking slice of what the component actually does.

Re-renders are continuous, not cycle-based. Zoneless Angular still has ApplicationRef.tick() and a ChangeDetectionScheduler. What is gone is the implicit tick driven by zone.js intercepting every async operation. In a zoneless app, change detection runs because the scheduler decided to run it, which in practice is because a signal flagged a view dirty. From the outside that looks less like a single render cycle and more like a graph of signals notifying their dependents at fine granularity. An addon that says “re-run my check on each render cycle” has no clean event to listen to, because there is no single render cycle visible at the public surface of the component.

The pre-signal mental model is not catastrophically wrong. It is just lossy. And every layer of CDD tooling pays the price of that loss somewhere.

Where the tooling lags, concretely

Three examples I have hit while building ng-prism.

1. Controls and args still treat inputs as a flat property bag.

The Storybook args object and ng-prism’s own variant config both look like this:

{ variant: 'primary', label: 'Save', disabled: false }

That is fine as a starting state. It is wrong as a model of how the component actually consumes its inputs. A signal-based input has a default expression, can be required, can be tied through computed() into other state, and can be read multiple times per render. None of that is in the args object. The args object is a snapshot of a tree it cannot see.

2. A11y, perf, and visual-diff addons assume “render happened, now check”.

axe-core, layout measurements, screenshot capture: they all rely on a moment where the DOM has settled and you can inspect it. Angular does give you some primitives here. afterNextRender() fires once after the next render. afterRender() fires after every render. ApplicationRef.isStable exposes a stable-state observable. None of those quite match what an a11y or visual-diff addon actually wants, which is closer to “the reactive graph has been quiet for N milliseconds across multiple microtasks, and I am now safe to walk the DOM”. That concept does not exist as a framework primitive. So you debounce, you wait for animation frames, you hope. In ng-prism the built-in a11y audit runs after a 500ms debounce on signal changes (A11yAuditService.scheduleAudit, default debounceMs = 500), which works in practice but feels like a workaround. I am not sure a true “graph is quiescent” signal even makes sense in a system designed to update continuously.

3. The “scenario” unit is too coarse.

A Storybook story is one set of args. A ng-prism variant is one set of input values. Neither can express “this component embedded in a parent that emits a signal stream over time”. The interesting bug in a signal-based component is rarely the static case. It is the transition. It is the moment when an upstream computed() updates twice in the same microtask and your effect runs once instead of twice. You cannot represent that with { variant: 'primary' }.

What I tried in ng-prism, honestly

ng-prism started life with the same implicit model as Storybook. Components have inputs. Inputs have values. Variants are named tuples of input values. The decorator looks similar:

@Showcase({
  title: 'Button',
  variants: [
    { name: 'Primary', inputs: { variant: 'primary', label: 'Save' } },
    { name: 'Danger',  inputs: { variant: 'danger', disabled: true } },
  ],
})

What ng-prism does that I think is on the right track:

Uses setInput() for every input push, never property assignment. So at least the signal contract is respected. This is the absolute floor and a surprising number of Angular-adjacent tools still get it wrong.
Drives the rendering loop with effect() on a signal of input values, not with a render-cycle event. The renderer reacts to whatever upstream signal happens to change.
Treats the scanner as a build-time concern. Signal inputs are recognised via the TypeScript Compiler API at build time, so the runtime never has to read decorator metadata. The decorator itself is literally a no-op, just a marker.
Supports zoneless via an opt-in flag in the ng add schematic (--zoneless), which wires up provideZonelessChangeDetection() and drops zone.js from polyfills. The default still ships with zone.js, but nothing in the renderer depends on an implicit zone tick; change detection runs because something signal-shaped told it to.

What ng-prism does not solve yet, and where I think the whole category is still stuck:

The variant model is still a flat input snapshot. I cannot describe a component as “embedded in a parent that pushes this signal stream over 2 seconds”.
computed() derived state is invisible in the UI. You see the inputs you set. You do not see the graph that hangs off them. For some components, that graph is the interesting part.
The a11y, perf, and box-model panels all hook into renderer output the way an old addon would. They debounce. They do not subscribe to the actual reactive graph the component is part of.
The “code snippet” feature generates a template string from input values. It cannot show how the component would behave in a parent where one of those inputs is itself a signal.

I am being deliberate about this in the docs. I do not want ng-prism to claim a level of insight into signal-based components that it does not yet deliver.

What I think the next generation should look like

This is the speculative part, so take it as opinion.

I think the unit of CDD will stop being “the component with these props” and start being “the component embedded in a reactive context”. A scenario will look more like a tiny fixture: this component, mounted under this parent, with these signal sources feeding it, over time. Closer to a Playwright scenario than a Storybook story.

I think tooling will need to render the reactive graph, not just the visual output. For a serious component, the dependency graph between inputs, computed(), and effect() is the documentation. We render the box and the controls. We should also be able to render the graph.

I think the addon model needs to flip. Instead of hooking into a render lifecycle that no longer exists, addons should subscribe to specific signals. Visual diff subscribes to the renderedElement signal. A11y subscribes to the same. Perf subscribes to a “graph quiescent” signal that the framework would have to expose. None of this lives in Storybook’s current architecture, and bolting it on is not obviously the right answer.

And I think “args” as a UI metaphor has run its course. A signal-based component is not configured by setting properties. It is wired up. The control surface should reflect that.

Closing

I am not arguing that Storybook is bad, or that the people maintaining it have missed something obvious. They built the right tool for the framework world of 2018, and that tool became a standard. Standards lag by definition. That is fine.

What I am arguing is that the abstraction is starting to leak in ways that matter. Signal-based Angular is a different kind of component runtime, not a faster version of the old one, and the surface area that CDD tooling was designed against has changed underneath it.

I am building ng-prism partly to test that hypothesis in code, not just in prose. I am also fully prepared to find out that I am wrong, that an args table plus setInput() plus a debounce is good enough for 95% of cases, and that the rest is academic. Possible. But I do not think it is, and I would rather find out by building than by predicting.

If you have hit the same kind of friction, or you have a counter-example where the args model still maps cleanly onto a signal-heavy component, I would genuinely like to hear it. That is more useful than another “signals are great” thread.

ng-prism is open source on GitHub. Feedback and counter-examples especially welcome.

Why I Built ng-prism — An Angular-Native Storybook Alternative With Zero Story Files

Alex — Sat, 02 May 2026 19:03:21 +0000

TL;DR: ng-prism lets you showcase Angular components by adding a single decorator to the component class itself. No story files, no parallel file tree, no framework mismatch. Just Angular.

The Problem Every Angular Team Knows

If you've ever maintained a Storybook setup for an Angular component library, you know the drill: for every component you write, you also write a .stories.ts file. Then you keep both in sync. Then someone renames an input, the stories break silently, and nobody notices until the designer opens Storybook two sprints later.

Storybook is a fantastic tool — but it was born in the React ecosystem. Angular support has always been a second-class citizen. The CSF format doesn't feel natural in Angular. The iframe rendering breaks MatDialog, CDK overlays, and portals. The webpack/Vite configuration is yet another build system you have to understand alongside the Angular CLI.

I wanted something different. Something that feels like Angular because it is Angular.

Introducing ng-prism

ng-prism is a lightweight component showcase tool built from the ground up for Angular. The core idea is radical in its simplicity: you annotate your component with a @Showcase decorator, and ng-prism discovers it at build time via the TypeScript Compiler API.

No story files. No parallel file tree. The documentation lives where the code lives.

  import { Showcase } from '@ng-prism/core';                                                                                                                                                                   
  import { Component, input, output } from '@angular/core';

  @Showcase({
    title: 'Button',                                                                                                                                                                                             
    category: 'Atoms',                                                                                                                                                                                         
    description: 'The primary action button.',
    variants: [                                                                                                                                                                                                  
      { name: 'Primary', inputs: { label: 'Save', variant: 'primary' } },
      { name: 'Danger', inputs: { label: 'Delete', variant: 'danger' } },                                                                                                                                        
      { name: 'Ghost', inputs: { label: 'Cancel', variant: 'ghost' } }                                                                                                                                         
    ],                                                                                                                                                                                                           
  })                                                                                                                                                                                                           
  @Component({                                                                                                                                                                                                   
    selector: 'lib-button',                                                                                                                                                                                    
    standalone: true,                                                                                                                                                                                            
    template: `<button [class]="variant()">{{ label() }}</button>`
  })                                                                                                                                                                                                             
  export class ButtonComponent {                                                                                                                                                                               
    label = input.required<string>();                                                                                                                                                                            
    variant = input<'primary' | 'danger' | 'ghost'>('primary');
    clicked = output<void>();                                                                                                                                                                                    
  }

That's it. Run ng run my-lib:prism, and you get a fully interactive styleguide with variant tabs, a live controls panel, event logging, and code snippets — all extracted from your actual component at build time.

How It Works Under the Hood

ng-prism doesn't guess your component's API. It reads it. At build time, a custom Angular Builder kicks off a pipeline:

TypeScript Compiler API scanner — Parses your library's entry point, walks the AST, and extracts every component annotated with @Showcase. It reads input() and output() signal declarations, infers types, detects defaults, and builds a complete component manifest.
Plugin hooks — Registered plugins can enrich the scanned data (e.g., extracting JSDoc comments, injecting Figma URLs from metadata).
Runtime manifest generation — The pipeline produces a TypeScript file with real import statements pointing to your actual component classes. No JSON serialization, no runtime reflection.
Angular Dev Server — The builder delegates to @angular-devkit/architect, so you get the Angular dev server you already know — HMR, source maps, the works.

The result: your styleguide is a regular Angular app. No iframe. Components render in the same document context. MatDialog? Works. CDK Overlay? Works. CSS custom properties from a parent theme? Inherited naturally.

Signal-Native From Day One

ng-prism was built for Angular 21+ and the signal API. It understands input(), input.required(), and output() natively. The controls panel automatically generates the right control widget for each

input type:

string → text field
boolean → toggle
number → number input
Union types like 'primary' | 'danger' → dropdown
Complex types → JSON editor

When you change a value in the controls panel, it flows through Angular's signal system. There's no @Input() decorator support — and that's by design. If you're starting a new component library in 2026, you should be using signals.

Built-In Accessibility Auditing

Accessibility isn't a plugin in ng-prism — it's a core feature. The built-in A11y panel provides four perspectives on every component:

Violations — axe-core audit with a visual score ring, sorted by impact severity
Keyboard Navigation — Tab order visualization with overlay indicators
ARIA Tree — The accessibility tree as the browser sees it
Screen Reader Simulation — Step through your component the way a screen reader would, with play/pause navigation

Switch to "Screen Reader" perspective in the toolbar, and the canvas dims while SR annotations overlay your component. It's a first-class development tool, not an afterthought.

Plugin Architecture — Extend Everything

ng-prism follows a Vite-style plugin model. A plugin is a plain object with optional hooks for both build time and runtime:

  import type { NgPrismPlugin } from '@ng-prism/core/plugin';                                                                                                                                                  

  export function myPlugin(): NgPrismPlugin {
    return {                                                                                                                                                                                                     
      name: 'my-plugin',                                                                                                                                                                                       

      // Build-time: enrich scanned component data
      onComponentScanned(component) {                                                                                                                                                                            
        component.meta = { ...component.meta, myData: extractSomething(component) };                                                                                                                           
      },                                                                                                                                                                                                         

      // Runtime: add a panel to the UI                                                                                                                                                                          
      panels: [{                                                                                                                                                                                               
        id: 'my-panel',
        label: 'My Panel',                                                                                                                                                                                       
        loadComponent: () => import('./my-panel.component.js').then(m => m.MyPanelComponent),
        position: 'bottom',                                                                                                                                                                                      
        placement: 'addon',                                                                                                                                                                                    
      }],                                                                                                                                                                                                        
    };                                                                                                                                                                                                         
  }

Official Plugins

@ng-prism/plugin-jsdoc — Extracts JSDoc comments at build time and generates structured API documentation, including parameter tables
@ng-prism/plugin-figma — Embeds Figma designs as interactive iframes to enable direct visual comparison with components
@ng-prism/plugin-box-model — Overlays CSS box model dimensions directly on rendered components for layout inspection
@ng-prism/plugin-perf — Profiles initial render and re-render performance using the browser Performance API
@ng-prism/plugin-coverage — Displays per-component test coverage based on Istanbul/V8 reports

Plugins lazy-load their components, so they don't bloat your initial bundle.

Setup in Two Minutes

  ng add @ng-prism/core

The schematic asks which library you want to showcase, creates a prism app project, wires up the builder targets in angular.json, and generates a config file. Then:

  ng run my-lib:prism

Your styleguide is running at localhost:4200. For the config, you get a typed prism.config.ts:

  import { defineConfig } from '@ng-prism/core';                                                                                                                                                               
  import { jsDocPlugin } from '@ng-prism/plugin-jsdoc';
  import { figmaPlugin } from '@ng-prism/plugin-figma';

  export default defineConfig({
    plugins: [                                                                                                                                                                                                   
      jsDocPlugin(),                                                                                                                                                                                           
      figmaPlugin()
    ],
    theme: {
      '--prism-primary': '#6366f1',
      '--prism-primary-from': '#6366f1',
      '--prism-primary-to': '#8b5cf6'                                                                                                                                                                            
      // ...
    }                                                                                                                                                                                                            
  });

Watch Mode

The serve builder watches your library sources and config file. Change a component, add a @Showcase decorator, modify an input — the manifest regenerates, and the Angular dev server picks up the change. No restart needed.

Component Pages & Custom Pages

Not everything fits neatly into a per-component showcase. Sometimes you need a "Patterns" page showing how multiple components compose, or a color token overview.

ng-prism supports Component Pages — free-form Angular components registered alongside your showcased components. They're defined in your main.ts via providePrism():

  import { PrismShellComponent, providePrism, componentPage } from '@ng-prism/core';                                                                                                                           
  import { ButtonPatternsPageComponent } from './pages/button-patterns.page.js';                                                                                                                                 

  bootstrapApplication(PrismShellComponent, {                                                                                                                                                                    
    providers: [                                                                                                                                                                                                 
      providePrism(manifest, config, {                                                                                                                                                                         
        componentPages: [
          componentPage({
            title: 'Button Patterns',
            category: 'Atoms',                                                                                                                                                                                   
            component: ButtonPatternsPageComponent,
          }),                                                                                                                                                                                                    
        ],                                                                                                                                                                                                     
      }),
    ],
  });

For static pages that don't need Angular components, use Custom Pages directly in prism.config.ts:

  export default defineConfig({                                                                                                                                                                                
    pages: [                                                                                                                                                                                                     
      { type: 'custom', title: 'Changelog', category: 'Meta', data: { version: '2.1.0' } },
    ],                                                                                                                                                                                                           
  });

Both appear in the sidebar navigation alongside regular components.

Content Projection & Directive Hosting

Real-world components use <ng-content>. ng-prism handles this with a content property on variants:

  @Showcase({                                                                                                                                                                                                  
    title: 'Card',                                                                                                                                                                                               
    variants: [{
      name: 'With Header',                                                                                                                                                                                       
      content: {                                                                                                                                                                                               
        '[card-header]': '<h3>Title</h3>',
        'default': '<p>Body content</p>'
      }                                                                                                                                                                                                          
    }]
  })

Need to showcase a directive instead of a component? Use the host property to specify what element it attaches to — either a plain HTML string or another Angular component.

Why Not Just Use Storybook?

Storybook is mature, battle-tested, and has a massive ecosystem. If it works for your team, keep using it. But if you've felt the friction of:

Maintaining a parallel .stories.ts file tree that drifts out of sync
Fighting iframe restrictions when your component uses overlays or portals
Configuring a separate build system (webpack/Vite) alongside the Angular CLI
Wrapping Angular-specific patterns (dependency injection, signals) in framework-agnostic abstractions

…then ng-prism might be worth a look. It doesn't try to be framework-agnostic. It's Angular, all the way down.

The Road Ahead

ng-prism is open source under the MIT license and follows Angular's versioning: @ng-prism/core@21.x targets Angular 21. The current release is v21.6.1. Why already v21.6.1? Because we already use it in my company for our component library, so it's already battle-tested.

What's coming next:

More official plugins
CI integration — Manifest validation in your pipeline (e.g. ensuring every public component has a @Showcase decorator)
Design token documentation — Automatic token overview extracted from SCSS / CSS custom properties
Export — Share your component catalog as a PDF or static HTML page

Get Started

🔗 Demo
📖 Docs
📦 npm install @ng-prism/core

dyingangel666 / ng-prism

Lightweight Angular-native component showcase — no story files needed.

ng-prism

Lightweight, Angular-native component showcase tool. Annotate components with @Showcase — no separate story files needed.

Live Demo · Documentation

Features

Zero-config discovery — TypeScript Compiler API scans your library at build time
Signal-native — works with input() / output() signals
Directive support — showcase directives with configurable host elements
Plugin architecture — JSDoc, A11y, Figma, Performance, Box Model, Coverage
Live Controls — auto-generated input controls with type-aware editors
Code Snippets — live-updating Angular template snippets per variant
Component Pages — free-form demo pages for complex components
Deep-linking — URL state sync for sharing specific component/variant/view
Themeable — full CSS custom property system, replaceable UI sections

Quick Start

1. Install

npm install @ng-prism/core

2. Add `@Showcase` to a component

import { Component, input, output } from '@angular/core';
import { Showcase } from '@ng-prism/core';
@Showcase({
  title: 'Button',
  category: 'Atoms',
  description

…

View on GitHub

                                                                                                                                                                        </p>

If you're building an Angular component library and want your showcase to feel like Angular — give ng-prism a try. Star the repo if you find it useful, and feel free to open issues or contribute plugins.