Ignite NG

Start a new Angular 22 app with authentication, guards and a feature-based structure already in place.

Every new Angular project starts with the same chores: folder structure, lazy-loaded routes, JWT auth, route guards, an HTTP interceptor, login and register pages. Ignite NG generates all of it in one command, so you can start on your actual product.

npx ignite-ng my-app

Status: early (v0.1). Ignite NG targets the latest Angular only (v22) and generates a client-side app (no SSR). Feedback and issues are very welcome.

A standard Angular 22 project (created with ng new) plus:

src/app/
├── app.config.ts        # HTTP interceptor, session restore at startup, API URL
├── app.routes.ts        # lazy-loaded routes with guards
├── core/                # app-wide singletons
│   ├── config/          # API URL and auth endpoints
│   ├── guards/          # authGuard, guestGuard
│   ├── interceptors/    # auth interceptor (token + 401 handling)
│   ├── models/          # User, AuthResponse, ...
│   └── services/        # AuthService (signals)
├── shared/              # reusable UI pieces (button, field errors)
└── features/            # one folder per feature, lazy loaded
    ├── auth/            # login and register pages (Signal Forms)
    └── dashboard/       # a protected page to build on

• Standalone, signal-based Angular: AuthService exposes signals, forms use Signal Forms.
• Lazy loading per feature.
• Route guards: authGuard protects pages, guestGuard keeps signed-in users away from login.
• Smart interceptor: adds the token to requests sent to your API only, and on a 401 refreshes the session once and replays the request (cookie strategy).
• No flash of "logged out": the session is restored before the first navigation.
• Themeable: colors, radius and fonts are CSS variables at the top of styles.css, with automatic dark mode.

Requirements: a Node.js version supported by Angular 22.

npx ignite-ng my-app
cd my-app
npm run mock-api     # terminal 1: a fake backend (if you kept the mock API)
ng serve             # terminal 2

Open http://localhost:4200 and sign in with demo@example.com / password123.

The CLI asks a few questions:

? How does your backend handle sessions?
❯ Access token in memory + refresh token in an HttpOnly cookie (recommended)
  Single access token stored in localStorage
? Include a mock API to try the app right away? (Y/n)
? Base URL of your API:            # only asked if you decline the mock API

Angular's own ng new may also ask whether you want to share usage data; that question comes from Angular, not from Ignite NG.

Anything you pass as an option is not asked again. Without a terminal (CI) or with --yes, defaults are used.

npx ignite-ng my-app --yes --session storage --api-url https://api.example.com/v1

Choose cookie whenever your backend can support it. Choose storage when you need the simplest possible setup and understand the trade-off.

Ignite NG does not generate a backend. The generated app expects this contract (paths are configurable in src/app/core/config/api.config.ts).

For the cookie strategy:

• The refresh token is sent by the backend as Set-Cookie: refreshToken=...; HttpOnly; Secure; SameSite=.... The frontend never sees it.
• If the app and the API are on different origins, the API must send Access-Control-Allow-Credentials: true and a specific Access-Control-Allow-Origin (a wildcard * is refused by browsers when credentials are involved).
• Requests to the auth endpoints are sent with withCredentials: true.

If you keep the mock API, the CLI adds mock-server/server.mjs and an npm run mock-api script. It implements the contract above with real signed JWTs and a rotating HttpOnly refresh cookie, with no dependencies.

• Runs on http://localhost:3000/api, expects the app on http://localhost:4200.
• Access tokens last 15 minutes. To watch the automatic refresh, use a short lifetime: ACCESS_TTL=15 npm run mock-api (on Windows PowerShell: $env:ACCESS_TTL=15; npm run mock-api).
• For local testing only: data lives in memory, passwords are stored in clear text, the signing secret is hard-coded.

• Colors and fonts: edit the CSS variables at the top of src/styles.css.
• API URL: API_URL in src/app/app.config.ts.
• Endpoints: AUTH_ENDPOINTS in src/app/core/config/api.config.ts.
• A new feature: add a folder in src/app/features/, expose its routes, and lazy load it from app.routes.ts, the same way dashboard is wired.

The generated code is yours: it is plain Angular in your repository, not a runtime dependency.

• Server-side rendering. Apps behind a login rarely need it, and it complicates token handling. It may become an option if there is demand.
• A backend.
• Generated unit tests.
• Support for Angular versions before 22.

Issues and pull requests are welcome, especially bug reports from real projects.

git clone https://github.com/wilfriedtankwe/ignite-ng.git
cd ignite-ng
npm install
npm run build
npm link            # makes the `ignite-ng` command available locally

The code that ends up in generated projects lives in templates/; the CLI itself is in src/. Templates are plain Angular code that compiles on its own, so the quickest way to work on them is to copy templates/base/src/ over a fresh ng new project and run ng build.

MIT — see LICENSE.