vite-plugin-ngp: Angular on Vite, one file at a time

As Angular applications grow, development workflows can become increasingly demanding. Longer startup times, higher memory consumption, and slower feedback loops can make working on large applications particularly challenging.

But what if Angular could compile only the files needed for the part of an application you're working on?

On 8 October 2026, Angular merged ngp, a new experimental preprocessor with its analysis rewritten in Rust. Unlike the existing Angular compiler, ngc, which relies on building a TypeScript program for the project, ngp can process Angular files individually.

We wanted to explore what this architectural change could mean for Angular development. So we built vite-plugin-ngp, a Vite plugin that compiles Angular modules on demand, and benchmarked it against the existing development setups of two real open-source applications.

The results show promising improvements in startup times, memory usage, and template update speed. In this article, we explain how the plugin works, share our first benchmarks, and explore what per-file compilation could mean for developing large Angular applications.

Why a plugin

ngc, the compiler behind ng build and ng serve, can't compile one file until it has built a TypeScript program for the whole project. So every dev server built on Angular's compiler compiles the whole app before it serves a single module, the bigger the app, the longer you wait and the more RAM it takes.

ngp compiles one file at a time. That's exactly what a Vite plugin needs, so we wrote one: vite-plugin-ngp compiles each Angular file when the browser asks for it. Vite owns the module graph, and nothing compiles the whole program first. The work now scales with the page you're looking at, not with the size of the app:

• A template edit regenerates one component and swaps it in place, keeping its state.

• The dev server holds only the modules the browser has requested.

• On large apps, it does on its own what teams otherwise do by hand with trimmed route files or module federation: compile only the part of the app you're working on.

First results

We measured the plugin against the CLI each app ships with, on two open-source apps: Super Productivity (Angular CLI, 252 components) and Ghostfolio (Nx, 157 components). GitHub ubuntu-latest runners, 4 cores, medians of 5 runs (10 for edits).

The bigger the app, the bigger the gap. On a generated app of 5,000 components, the dev server shows its first page in 1.6 s where ng serve takes 28.4 s (Apple M2 Max). The compiler isn't doing the work faster there; it's doing less of it: only the files the first page imports.

Where it gains least: cold starts on Super Productivity, and production builds, which peak at about the same memory as the CLI's. Super Productivity's ng serve is a JIT build, as the app configures it. Ghostfolio's initial JavaScript comes out 17% larger gzipped. All of this, and more, is on the Benchmarks page.

We've also run it on a large enterprise app, where ng serve needs more than 16 GiB. That's the subject of a follow-up article.

Reproduce it

You need macOS or Linux (Windows via WSL 2), Node 26, pnpm 10, git, curl and a C compiler. ngp isn't on npm yet, so the repo builds it from Angular's source; the first build takes about two minutes on a 12-core machine.

git clone https://github.com/push-based/vite-plugin-ngp.git
cd vite-plugin-ngp
nvm use
pnpm install
pnpm toolchain   # builds ngp into toolchain/out
pnpm build
pnpm dev         # playground on http://localhost:5173

To rerun the benchmarks on both apps:

cd bench && pnpm install
node real.mjs super-productivity && node real.mjs ghostfolio
NGP_TOOLCHAIN="$PWD/../toolchain/out" node run.mjs --apps super-productivity,ghostfolio --tools ngp,cli,nx
node report.mjs results/*.json

Or start the bench-real workflow from the repo's Actions tab. To put your own app on Vite, follow Getting started: https://push-based.github.io/vite-plugin-ngp/getting-started

Before you try it

This is a prototype on a prototype. Every @angular/* package must be pinned to exactly 22.3.0-next.2, and the plugin can break with any Angular commit. Apps written before isolatedModules was the default may need their type-only re-exports fixed. Use it to try per-file Angular compilation, not to ship production apps.