# ng-matero: Angular Material Admin Template Setup and Architecture

> ng-matero supplies an Angular Material-based admin foundation with layouts, authentication, permissions, internationalization, dark mode, and route generation schematics. It fits teams that want a configurable TypeScript admin interface, but it also couples application choices to its Angular and Material compatibility matrix.

**ng-matero/ng-matero** — Angular Material admin template.

- Repository: https://github.com/ng-matero/ng-matero
- Website: https://ng-matero.github.io/ng-matero/
- Stars: 1,474 · Forks: 385
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/ng-matero-ng-matero

## Why ng-matero targets Angular administration interfaces

ng-matero addresses the front-end work required to build an administration interface in Angular. Its starting point is an Angular Material template rather than a general-purpose component library, so the intended users are TypeScript developers assembling dashboards, management pages, authenticated areas, and route-driven applications. The repository describes multiple admin layouts, a configurable color system, CSS helpers, dark mode, and right-to-left support. It also includes feature areas that commonly sit below the visual shell of an admin product, including authentication, HTTP interceptors, permissions management, and internationalization.

That scope makes the template more useful than a collection of isolated Material examples, but it does not make it a complete admin product. The repository contains Angular application code, schematics, configuration, tests, and build tooling. It does not document a server, database, account provisioning model, or production authentication flow. ng-matero therefore solves the starter and scaffolding side of an admin application. The team still has to connect pages to its own data sources and decide how users, roles, sessions, and business operations behave.

The choice is particularly direct for teams that already use Angular Material. Adopting ng-matero means building on the visual and interaction conventions of that ecosystem. If the planned interface instead requires an existing company design system built on another component library, the template's Material foundation may create more replacement work than value.

## Layout, feature, and schematic structure in ng-matero

The repository layout separates the running application from the code that scaffolds new application areas. The main Angular application is under `src/`, with files such as `angular.json`, TypeScript compiler settings, ESLint configuration, Stylelint configuration, and Playwright configuration at the repository root. Dedicated `schematics/` and `tools/` directories provide a different path from runtime UI code: they generate project structure for consumers. The `e2e/` directory is also separate from the main application source.

At runtime, ng-matero combines Angular Material components with the application capabilities listed in the README. These include multiple administration layouts, authentication, permissions, HTTP interceptors, translations, dark mode, and right-to-left behavior. The available details do not document the internal class hierarchy or every guard and interceptor, so it would be misleading to imply a specific server protocol. What can be confirmed is that these concerns are part of the template, while the actual business APIs remain application responsibilities.

The schematic workflow has a more visible structure. A module schematic creates a lazy-loaded module in the `routes` directory by default, and `--module-root=pages` changes that destination. A page schematic creates a component inside a selected module. An `-e=true` option creates an entry component intended for dynamic content such as dialogs, without adding route configuration. This separation lets a team choose a conventional routed module or a component that is opened dynamically, but generated files still need application logic and API integration.

## Installing ng-matero with Angular CLI schematics

The documented installation path creates a new Angular application and adds ng-matero through `ng add`. This is preferable to cloning the repository when the intention is to create an application, because the starter repository exists as an alternative but the README explicitly says that cloning it is not recommended.

First create the Angular project and enter its directory:

```bash
$ ng new <project-name>
$ cd <project-name>
```

Angular CLI should create the project and change the shell to its directory. The angle-bracket names are placeholders defined by the README, so they must be replaced with the intended project name.

Add ng-matero to that application:

```bash
$ ng add ng-matero
```

In a workspace containing multiple applications, the README documents a project selector for versions 21 and above:

```bash
$ ng add ng-matero --project=<project-name>
```

That option is specifically relevant to multi-project workspaces. The documentation does not provide automated acceptance steps or a statement about which files the installer changes, so a successful CLI completion should not be treated as evidence that every configured backend feature is present.

## Generating the first lazy route and page with ng-matero

After installation, the shortest documented path to a routed example uses one module schematic and one page schematic. These commands generate `abc` and then a `def` page associated with it:

```bash
$ ng g ng-matero:module abc
$ ng g ng-matero:page def -m=abc
```

The module command creates the lazy-loaded area under `routes`, unless a different module root is specified. The page command then adds `def` to module `abc`. According to the README, the resulting route is available at `http://localhost:4200/#/abc/def` during local development.

Developers who prefer a project-specific location can place the generated module under `pages`:

```bash
$ ng g ng-matero:module <module-name> --module-root=pages
```

Not every generated component needs a route. The entry-component form is intended for dynamic content such as a dialog:

```bash
$ ng g ng-matero:page <page-name>/<entry-component-name> -m=<module-name> -e=true
```

The distinction matters during application design. A feature page belongs in the generated module and receives route configuration, while an entry component can be created for content loaded dynamically. The README does not document authentication behavior for generated routes or whether permissions are enforced automatically, so those controls must not be inferred from file generation alone.

## Version compatibility across Angular 8 through Angular 22

ng-matero publishes release lines aligned with Angular and Angular Material major versions. The compatibility table associates Angular v22 and Material v22 with ng-matero 22.x.x and Extensions 22.x.x. Earlier rows pair each supported Angular major with a specific ng-matero and Extensions line. This is more than a broad claim that the template works with Angular. Adopting an old Angular application means selecting a matching historical release rather than installing the newest package and expecting compatibility.

The package manifest reflects that coupling. Its current dependencies use the Angular 22.2 range, including `@angular/core`, `@angular/material`, `@angular/cdk`, forms, router, and related packages. It also depends on `@ng-matero/extensions` and its date-fns adapter, along with Formly, translation, and overview packages. Dependency alignment should therefore be checked against both the target Angular application and the package manager instructions in the repository.

The root `package.json` requires Yarn `>=1.22.0 <2` for repository development and asks users to use Yarn rather than npm for dependencies. This requirement concerns working on ng-matero itself. The `ng add ng-matero` tutorial operates inside an Angular application and does not state that the consumer must use the template repository's Yarn setup. Upgrade planning must cover ng-matero, Extensions, Angular Material, and the generated application rather than updating only the template package.

## Where ng-matero imposes cost and friction

The primary cost is framework coupling. A team gains a substantial Angular Material starting point, but it also accepts ng-matero's layouts, extensions, schematics, and release compatibility. The compatibility matrix exposes this boundary clearly: there are separate version lines rather than one package version intended for every Angular major. Upgrading Angular across major versions requires matching package lines and checking generated application conventions.

The feature list also needs careful interpretation. Authentication, permissions management, and HTTP interceptors are present as template concerns, yet the README does not define an identity provider, token format, refresh policy, API contract, or authorization model. Teams with existing server-side session rules cannot assume those rules are automatically satisfied. Likewise, internationalization requires application translation resources, while permissions require application-specific roles and checks. The template provides an area to implement those concerns, not evidence that a backend has been configured.

Another practical limitation is customization. Multiple layouts, color configuration, CSS helpers, dark mode, and right-to-left support increase the available design choices, but this is not a detached component package that can be dropped into any renderer. It is an Angular application template. A team that has standardized on another UI approach may spend more effort replacing Material components and template conventions than it would implementing the same administrative shell from scratch.

## Comparing ng-matero with a blank Angular Material application

The most direct alternative is to create an Angular application with Angular Material and assemble the admin structure without ng-matero. The difference in approach is substantial. A blank application gives the team direct control over routes, layouts, interceptors, authentication, translations, permissions, and code generation. It also avoids adopting ng-matero's extension packages and schematic conventions. The trade-off is that the team must identify and implement the administrative scaffolding itself.

ng-matero is more productive when the desired application resembles its documented feature set: Material components, several admin layouts, dark and right-to-left modes, permissions, authentication, HTTP interceptors, and internationalization. Its `ng add` flow and schematics also reduce repeated setup for modules and pages. That makes it a stronger starting point for an Angular Material team than an empty workspace.

The separate starter repository offers another documented path. It can be cloned and installed, but the README says this is not recommended and presents it as an alternative for starting from an existing starter. That differs from `ng add` because the developer receives a repository laid out as a ready-made application instead of adding the schematic package into a newly created Angular workspace.

## Maintenance, licensing, and upgrade boundaries in ng-matero

The repository is not archived, and its last push was on 2026-10-04. Recent releases include v22.0.0 on 2026-10-04, v21.1.0 on 2026-05-05, and v21.0.0 on 2026-01-17. Those facts indicate recent project changes, but the README points development plans to GitHub Projects rather than documenting a support window or a long-term compatibility policy. Projects should therefore base their planning on the published compatibility table and each selected release's actual migration needs.

The repository uses the MIT License. That is the license fact stated by the project. It does not remove the need for teams to check dependencies separately, because Angular, Material, Extensions, Formly, translation packages, and adapters can carry their own license obligations. This review does not provide legal advice or interpret how a particular distribution arrangement affects compliance.

Maintenance also involves generated code. Before accepting a major-version upgrade, a team should compare its Angular and Material versions against the ng-matero and Extensions entries in the compatibility table. It should then review the differences in its generated modules, authentication integration, interceptors, translations, and build configuration. The repository provides `yarn.lock`, `angular.json`, `eslint.config.js`, `.stylelintrc`, `playwright.config.ts`, and separate application and schematics build paths, so upgrade review is not limited to one application source folder.

## Conclusion

Angular teams building an internal admin application should evaluate ng-matero when the Angular Material component model, built-in administration features, and schematic workflow match their requirements. Projects based on another UI framework, teams unable to follow Angular and Material release compatibility, or developers expecting a finished backend should not adopt it as a complete application. Verify first that the selected ng-matero and Extensions versions match the target Angular version, then confirm that authentication, permissions, and internationalization fit the planned application model.

## FAQ

### How do I install ng-matero in an Angular application?

Create an Angular project with `ng new`, enter its directory, and run `ng add ng-matero`. For multiple applications in a workspace, versions 21 and above support specifying the target with `--project=<project-name>`.

### How does ng-matero generate a routed page?

Generate a lazy-loaded module with `ng g ng-matero:module abc`, then create a page in it with `ng g ng-matero:page def -m=abc`. The README places that example at `http://localhost:4200/#/abc/def` during local development.

### Which ng-matero version should I use with Angular?

Use the compatibility table rather than selecting a version independently. The current table pairs Angular v22 and Material v22 with ng-matero 22.x.x and Extensions 22.x.x, while earlier Angular majors have their own release lines.

## Sources

- [License: MIT](https://github.com/ng-matero/ng-matero/blob/main/LICENSE)
- [ng-matero/ng-matero on GitHub](https://github.com/ng-matero/ng-matero)
- [Project website](https://ng-matero.github.io/ng-matero/)
- [README](https://github.com/ng-matero/ng-matero/blob/main/README.md)
- [Releases](https://github.com/ng-matero/ng-matero/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ng-matero-ng-matero