vite-plugin-ngp
On this page

Changelog

What changed in vite-plugin-ngp, newest first. The plugin isn't on npm, so there are no releases: this page is how you find out what landed since you last looked. Every entry links to the page that documents it.

19 October 2026#

Repo#

Docs site#

  • The ngp benchmark is public, so its links on Performance, Benchmarks and Comparison work for everyone and no longer say "private repo". It has the generator behind the test apps, the methodology, and the audits the plugin's design started from.
  • A new logo: an Angular "A" between two parentheses, inside a gear, in cyan to magenta. It's in the header, on the home page, as the favicon, and in the repo's README. The inside of the gear is transparent, so it looks the same on the light theme and the dark one.

18 October 2026#

Type-checking#

  • What the idle-triggered first check gains on a cold start is now measured on the generated 5,000-component app, with the plugin before and after the change started in the same rounds: first paint went from 1.84 s to 1.70 s, every sample of the old plugin slower than every sample of the new. A restart paints before the old one-second delay ever fired, and didn't move. Type-checking

Docs#

  • The Performance page is remeasured on the plugin with the tsrs option merged and the first dev-server check waiting for an idle server: the four generated apps on the laptop, now with typeChecker: 'tsrs' as a row of its own in every table. tsrs shows a type error at 5,000 components in 1.02 s where tsgo takes 1.36 s, and takes about half a gigabyte off the dev server's peak during edits and off a production build's; starts, edits and build times are within the run-to-run drift with either. Every other number moved by a few percent either way. Performance
  • The Benchmarks page is remeasured too, on the same plugin: the two real apps on GitHub's runners and on the laptop. The change that shows is Super Productivity's cold start on a 4-core runner, 10.5 s against ng serve's 17.4 where the morning's run had 21.4 against 23.1, at a peak of 3.0 GB instead of 4.9, now that the first type-check waits for an idle server; the runners were faster this time too, and the page says how much of the drop is which. Benchmarks

17 October 2026#

Type-checking#

  • New option typeChecker: 'tsrs' runs the type check with tsrs, Oxc's Rust port of TypeScript 7, instead of tsgo. You install tsrs yourself; the plugin hands it the same tsconfig and errors land in the same places. On the 5,000-component app a planted template error reaches the terminal in 1.12 s instead of 1.56 s, measured in one run; on the playground the two are even. Checking with tsrs

Docs site#

  • The site has search. Press ⌘K (Ctrl+K off a Mac) or the search button in the header, and it finds any page and the section of it that matches, such as allowedHosts in Server rendering. The index is built with Pagefind when the site is, and nothing of it loads until you open search: about 165 kB compressed then, most of it Pagefind's WebAssembly and the index.
  • A link to a section, from "On this page", from search or from a URL with a #, leaves the heading below the header instead of under it, on a phone too. Try What it checks.

Type-checking#

  • The first type-check of a dev-server session waits until the server is idle, half a second with no request and no module compile, instead of starting one second after the server starts. Generating every component's type-check block ran on Vite's thread while the first page was compiling; on Super Productivity that was 0.67 s of the thread, and first paint went from 6.72 s to 6.00 s on a warm restart once the check waits. The first errors show up later, after the page instead of alongside it. Checks after edits are unchanged. Type-checking

Server rendering#

  • The dev server pre-bundles and caches the server's Angular libraries, in node_modules/.vite/deps_ssr, instead of linking and transforming them on every start. On the playground the first server-rendered page after a warm restart went from 1.3 s to 0.74 s. The server bundle has no source maps: a stack trace from inside Angular points into the readable pre-bundle. Server rendering

Editing in the dev server#

  • A save can no longer be undone by a module Vite read just before it: components compiled afterwards see the saved file. How it works
  • Template edits reach the page about 50 ms sooner on macOS. The plugin's 50 ms wait for the rest of a save now counts from when the template was written, not from when Vite's watcher reported it, and the watcher usually reports later than that. At 1,000 components the median template edit went from 169 ms to 120 ms. How it works, Performance
  • A class edit could reload the page twice, a second after the first reload. That happened when the plugin read the .ts file between a save truncating it and writing it. The plugin now waits out an empty read, the way Vite does. How it works
  • DEBUG=vite-plugin-ngp also logs how long each step of a template update took. Configuration

Performance#

  • Every number on the Performance page was measured again on the current plugin, in one run on 17 October: cold starts, restarts, edits, type errors, builds and bundle sizes for all four toolchains on all four apps, instead of the 16 October run with the plugin's edit row patched in from a later one. The results barely moved, which is the point: at 5,000 components the plugin shows the first page in 1.74 s where ng serve takes 28.3 s, a template edit lands in about 120 ms, and a build takes 20.2 s against 30.1 s. Performance
  • The page has a Memory section now. The generated apps were measured for memory the way the real apps are: at 5,000 components the plugin's dev server holds 1.0 GB after a restart where ng serve holds 6.0 GB, and 1.4 GB after the edits where ng serve holds 6.6 GB. Builds are even: 5.0 GB against 5.1 GB. Performance
  • Both benchmark pages have figures. Each table of medians now has a chart above it, one bar per tool and app on a shared scale, with the plugin in violet and the fastest edit marked. They're drawn from the result files by node bench/charts.mjs and follow the site's dark theme. Performance, Benchmarks on real apps
  • Bundle size has figures too: all the JavaScript a build writes and the initial part, gzipped, per tool and app. On the generated apps the plugin's output is within 3% of ng build's; on Super Productivity it's 10% smaller than the CLI's, on Ghostfolio 3% larger. Performance, Benchmarks on real apps

Benchmarks on real apps#

  • A new page, Benchmarks on real apps: the plugin against the Angular CLI on Super Productivity and against Nx on Ghostfolio, two open-source apps, for dev-server starts, edits, production builds and memory, measured on GitHub's runners and on a laptop. On GitHub's 4-core runners the plugin restarts Ghostfolio's dev server in 4.5 s where Nx takes 21 s, updates a template in about 130–150 ms on both apps where the CLIs take 3.3–3.7 s, builds Super Productivity in 18 s where ng build takes 32 s, and holds a third to a half of the CLIs' memory while you work; its cold start of Super Productivity, 21.4 s against 23.1 s, is the one number that barely moves. It also lists what each app needed to run on a per-file compiler at all. The bench-real workflow reruns it on demand.
  • Status and limits now says real apps, Linux and memory have been measured, and what still hasn't.

Internationalization#

  • A translation file with a unit the parser can't read in full, such as a { in a translation that isn't an ICU expression, no longer fails vite build. The error is logged and the build goes on, as ng build does with the same file. Ghostfolio's Catalan translations have two such units. Internationalization

This site#

  • A new page, Compared with alternatives, sets vite-plugin-ngp next to ng serve, Analog (its default path and fastCompile) and @oxc-angular/vite: when each compiles, whose compiler it runs, type-checking, HMR, SSR, linking, and how you get it, with a source for every claim and where the plugin is weaker.
  • A new page, Migrating inside an Nx workspace: how to move one app of an Nx workspace to the plugin while the rest stays on Nx. Vite's root in the app's folder, tsconfig.base.json's paths as Vite aliases, libraries compiled from source with the app, export type and decorator metadata, Nx targets, and why nx build my-lib stays on ng-packagr. Checked on Ghostfolio, with Vite's root at the workspace root and at the app's folder.
  • Status and limits says library builds aren't supported, and Migrating from ng build lists a library project under what can't move.
  • Migrating from ng build now says where localize and i18nMissingTranslation go, since i18n works. It listed them as not yet possible.
  • An editing pass over every page: stale counts fixed, and the Server rendering page's prerender timing remeasured on the current 14 pages. Server rendering
  • The repo, push-based/vite-angular, is public. Getting started now starts with git clone instead of asking for access, and no page calls the repo private any more.
  • Tables no longer break option names or types mid-word. The Options table puts each option's type and default in one cell so it fits the docs column, and on a phone every table with three or more columns stacks each row into labeled lines.

16 October 2026#

The first day: from an empty repo to a plugin that compiles, serves, renders, tests and type-checks Angular through ngp.

Compiling and building#

  • Every .ts module compiles on request with ngp's optimize mode, from the code Vite hands over, with no whole-program pass first. How it works
  • Angular libraries are linked, in dependency pre-bundling and in builds, so the browser never needs the JIT compiler. How it works
  • The plugin defines Angular's compile-time globals (ngDevMode, ngJitMode, ngServerMode, ngHmrMode) the way the CLI does. How it works
  • vite build runs Angular's build optimizer, which brings the playground's JavaScript to within 2% of ng build's. How it works
  • ngp builds inside the repo with one command, pnpm toolchain, with no Rust installed beforehand. Building ngp

Editing in the dev server#

  • Component HMR: an external template edit updates the running component in place, keeping its state. How it works
  • A .ts edit that only changes a component's inline template or styles updates in place too, with the CLI's rules for what's safe. How it works
  • One save that changes a component's class and its template reloads once, instead of applying a template the class can't run yet. That holds however far apart, and however often, the watcher reports the two files, as macOS's does. How it works
  • Adding, renaming and deleting files compiles as a fresh build would. Deleting a file that's still used is an error until it's back, and a missing templateUrl file reports NG2008 instead of rendering a blank component. How it works

Styles, type-checking and tests#

  • Component stylesheets (styleUrl, styleUrls) go through Vite's CSS pipeline, so Sass, PostCSS and CSS HMR apply. Component styles
  • Templates and TypeScript are type-checked with TypeScript 7 over ngp's type-check blocks, in a separate process, with errors in the terminal and the overlay. New option: typeCheck. Type-checking
  • Angular specs run under Vitest, compiled ahead of time with ngp. Testing with Vitest

Moving from ng build#

  • New options fileReplacements, budgets and polyfills, in angular.json's shapes. Replacements reach ngp's analyzer too, budgets print the CLI's messages and fail the build on errors, and zone.js apps get async/await rewritten so change detection still runs after an await. Every other build option is mapped to Vite config. Migrating from ng build

Internationalization#

  • New option i18n: Angular's i18n attributes and $localize, with a dev server in one locale and a vite build that writes one translated folder per locale, server bundles included. Internationalization
  • ngp-extract-i18n writes the app's messages as XLIFF 1.2 or 2.0, XMB, JSON or ARB, like ng extract-i18n. Internationalization
  • The compiler reads enableI18nLegacyMessageIdFormat and i18nNormalizeLineEndingsInICUs from angularCompilerOptions, and the plugin defines ngI18nClosureMode, so message ids match ng build's. Internationalization

Server rendering#

  • New option ssr: pages render on the server in the dev server, and vite build builds a server bundle beside the browser one. Server rendering
  • Server builds bundle and link every Angular library in your dependencies. Server rendering

Performance#

  • The first end-to-end numbers, against ng serve, Analog and @oxc-angular/vite: at 5,000 components the plugin shows the first page in 1.9 s where ng serve takes 28.5 s, and a template edit in about 150 ms where ng serve takes 1.8 s. The harness is in the repo's bench/ folder. Performance

This site#

  • Docs at https://push-based.github.io/vite-plugin-ngp/, built with the plugin itself and prerendered with Angular SSR. They redeploy on every push.
  • Dark theme, copy buttons, heading links, the file name on each snippet, and llms.txt for AI assistants.

Last updated . View as markdown.