Extreme Angular is pre-configured with a strict and opinionated set of development tools that enforce best practices, ensure consistent code quality, and promote accessibility while remaining fully compatible with the official Angular documentation.
However, Extreme Angular is not a fully-featured dashboard or a component library. It contains no custom application logic, components, or complex modifications. Instead, it offers a clean, strict base for your Angular project. The underlining Angular project was generated with:
ng new --strict --style=scss --ssr=false
For additional utility like Angular Material, Server-side & hybrid rendering (SSR, SSG, Hydration), Internationalization (i18n), or End to End testing (e2e) check out the Optional Angular Schematics section.
If you have a suggestion or run into any issues then first search through the issues, and then create a new one if necessary! 📣
To contribute, fork the repository, check out a new branch, make your changes, and then submit a pull request. 🐙
Thank you for your contributions!
If you have a GitHub account, an easy way to get started is to select "Use this template" in the top right corner of the GitHub page for Extreme Angular and then select "Create a new repository". This will allow you to rename your repository and set it to private.
Alternatively, if you do not have a GitHub account, I recommend cloning only the most recent commit and renaming the remote branch to 'upstream'. (Replace new_project_name with the name of your project):
git clone --depth=1 --origin=upstream https://github.com/joematthews/extreme-angular.git new_project_nameChange to the new project directory and install the dependencies:
cd new_project_name
npm installUse the shortcut CTRL+SHIFT+H in VSCode to search and replace extreme-angular with your chosen project name.
To start the development server run npm start.
Tip
If you're using VSCode and Chrome, then press F5 on the keyboard to start the app in debug mode. For more information check out: TypeScript in Visual Studio Code.
Tip
The "Dev Tools Implemented" section below is project-agnostic -- consider adding it to your project's README.md or CONTRIBUTING.md!
The documentation and configuration files in this project are licensed under the MIT license.
I keep the copyright from Angular's license and add my own copyright.
If your project also uses the MIT license, then please consider adding a new copyright line to LICENSE.txt:
Copyright (c) 2010-2024 Google LLC. https://angular.dev/license
Copyright (c) 2024-2025 Joe Matthews, et al. https://github.com/joematthews/extreme-angular
Copyright (c) 2025 Your Name or CompanyIf your project is closed source or uses a different license, then please consider renaming the file to LICENSE-Angular.txt.
This section outlines how each tool is configured, and how they can be leveraged to ensure clean and maintainable code.
Use this script to run all checks against all project files:
npm run lint:allCaution
These tools are not perfect and they are not a substitute for learning and utilizing the best practices outlined in the Angular guides for Style, Security, Accessibility, and Performance.
In addition to setting "strict": true, Angular's template checking is set to 'Strict Mode' in tsconfig.json.
These compiler options have also been added to ensure strict type-checking for optional properties, eliminate unused variables and parameters to reduce clutter, and enforce explicit handling of potentially undefined values in arrays or objects:
To check for errors in *.ts app files:
npm run lint:tsc:app
To check for errors in *.spec.ts test files:
npm run lint:tsc:spec
To check for errors in all TypeScript files:
npm run lint:tsc:all
ESLint is used for linting JavaScript, TypeScript, HTML, and JSON files in the project. The linting configuration is set in eslint.config.js, with specific overrides for the following file types: *.js, *.ts, *.spec.ts, *.html, and *.json.
To ensure effective linting for all project files, the following ESLint plugins are used:
- @angular-eslint
- Enables all TypeScript and template rules unless explicitly disabled or modified.
- @angular-eslint rules configuration matrix.
- @angular-eslint/template rules configuration matrix.
- @typescript-eslint
- Uses both strict-type-checked and stylistic-type-checked rule sets.
- typescript-eslint rules configuration matrix.
- eslint-plugin-jasmine
- Uses
recommendedrule set. - eslint-plugin-jasmine rules configuration matrix.
- Uses
- eslint-plugin-jsonc
- Uses
recommendedrule set. - eslint-plugin-jsonc rules configuration matrix.
- Uses
- eslint-config-prettier
- Disables rules that may conflict with Prettier formatting.
To lint all relevant files in the project (not just those in src/):
npm run lintESLint output is formatted using eslint-formatter-mo. To use normal formatting, remove the -f mo option from the lint script in package.json:
"lint": "eslint -f mo \"**/*.{js,ts,html,json}\"",Tip
Suppress the urge to immediately set rules to "off" or "warn". First, look up the rule and the problem it is correcting for and discuss the rule with other developers on the project.
This project enables all the accessibility rules provided by angular-eslint by default (denoted by 
in the @angular-eslint/template rules configuration matrix linked above).
Includes rules for image alt text, form labels, no autofocus, valid ARIA, and more.
These rules are easier to work with if enabled early in the development process and early adoption of these rules is also very helpful for avoiding common accessibility antipatterns.
The Accessibility in Angular guide is a great place to start learning about accessibility in Angular, and it provides resources on the topic of accessibility.
Stylelint is used to lint CSS and SCSS files in the project. It is configured with the stylelint-config-standard and stylelint-config-standard-scss configurations.
Rules for linting are applied separately to .css and .scss files, and can be customized in .stylelintrc.json.
To lint all CSS and SCSS files:
npm run lint:stylePrettier is used to enforce consistent code formatting, reducing diffs by minimizing formatting changes.
In .prettierrc.json, the htmlWhitespaceSensitivity option is set to ignore to better format templates. This setting trims unnecessary whitespace around and inside HTML elements. Use (non-breaking space) when you need to explicitly maintain spacing between inline elements.
The following Prettier plugins are used:
- prettier-plugin-sh: Formats shell scripts, such as Git hooks.
- prettier-plugin-css-order: Automatically organizes SCSS/CSS properties using concentric-css
- prettier-plugin-organize-imports: Automatically organizes, arranges, and removes unused imports.
To format files within the project:
npm run formatTo check if all files are properly formatted:
npm run lint:formatCSpell is used for spell checking for all project files.
To add project-specific words, update .cspell.json.
The Code Spell Checker Extension for VSCode allows you to quickly add misspelled words to the configuration by selecting "Add to config: .cspell.json" from the 'Quick Fix' menu.
The following dictionaries have been enabled: bash, companies, cpp, csharp, css, filetypes, fonts, go, html, latex, misc, node,npm, php, powershell, python,softwareTerms, and typescript.
To find misspelled words in all files within the project:
npm run lint:spellingThe following VSCode extensions will be recommended when opening the project (.vscode/extensions.json):
The following VSCode settings have been set in .vscode/settings.json:
- Set Prettier as default formatter.
- Turn on format on save
- Turn on fix linting errors on save.
- Turn on auto-save and set delay for 3 seconds (doesn't format or fix errors).
- Disable VSCode linter for CSS/SCSS.
- Enable Stylelint linter CSS & SCSS.
Husky is used to manage the pre-commit, pre-push, and commit-msg git hooks.
Commitlint is used to enforce good commit messages according to the @commitlint/config-conventional configuration in the commit-msg git hook. Additional Commitlint configuration is kept in commitlint.config.js.
Lint-staged is used to run Prettier, ESLint, Stylelint, CSpell, and tsc-files in the pre-commit git hook against all staged files. Lint-staged configuration is kept in .lintstagedrc.json
You can bypass the git hooks using git commit --no-verify and git push --no-verify. Or, use the shove script in emergencies when progress needs to be backed up quickly:
npm run shoveThe shove script will stage all files, commit with the commit message wip: shoved, and then push.
Note
The shove script sets git config push.autoSetupRemote true to increase the likelihood that the push will be successful. If you prefer to set the remote branch names manually you may need to set this option back to false.
Warning
The --no-verify flag cannot be disabled. To protect against untested code use a Continuous Integration solution.
The on-pull-request.yml action checks all files and run tests when a branch is pushed that is associated with a GitHub pull request.
Pull requests on GitHub cannot be merged until all checks and tests pass. The output of these workflows can found in the 'Actions' tab on the GitHub repository.
To execute these checks and tests locally:
npm run ci:allLooking for an a11y-friendly, MIT-licensed, Angular component library that strictly adheres to the Material Design language and integrates well with Angular's core libraries, and comes with animations? Then check out Angular Material.
The Angular Material documentation is very good and covers many topics including Supporting Light and Dark Mode
For design-agnostic template utilities, consider installing the Angular CDK:
ng add @angular/cdkTo add animations to your own components, check out Introduction to Angular animations
Consider enabling Server-side & hybrid rendering to improve SEO and user experience (at the cost of increased deployment complexity).
Angular has powerful Internationalization capabilities.
If you plan to implement internationalization in the future, adding i18n attributes early on can make the process easier to scale naturally.
To enable the i18n ESLint rule, simply remove or configure the following rule from the *.html section of eslint.config.js:
"@angular-eslint/template/i18n": "off",Note
You may also need to configure the @angular-eslint/template/i18n rule according to your project's needs.
Tip
Using eslint --fix can automatically add i18n tags in many cases.
Angular has schematics available for several end to end testing frameworks. The Angular End to End Testing guide will walk you through the steps to set one up.
The eslint-plugin-playwright package has rules for the popular Playwright framework. To incorporate these rules, import the plugin in the eslint.config.js file and then add a new config object that targets e2e/**/*.spec.ts files:
import { playwright } from "eslint-plugin-playwright"; {
files: ['e2e/**/*.spec.ts'],
extends: [...playwright.configs['flat/recommended'], prettierConfig],
rules: { ...playwright.configs['flat/recommended'].rules },
},These are tips and tricks that are too opinionated or situational to include in the repository configuration or are not related to Angular project configuration.
To customize the indentation and line width, change the indent_size property in .editorconfig:
[*.{js,ts,css,scss,sh,html,json}]
indent_size = 2And then add the tabWidth and printWidth properties in .prettierrc.json:
{
"tabWidth": 2,
"printWidth": 80
}To use double quotes for JS/TS files, change these properties in .editorconfig:
[*.ts]
quote_type = single
ij_typescript_use_double_quotes = false
[*.{js,cjs}]
quote_type = singleAnd then set the singleQuote property to false in .prettierrc.json:
{
"singleQuote": false
}Finally, run npm run format to re-format all files, and check the result.
Here are some reasons for not changing the indentation, line width, and quote style:
- The Angular documentation and libraries use 2 space indentation and single quotes.
- 2 space indentation is traditional for various reasons.
- 4 space indentation can look pretty bad in JS/TS with an 80 character line limit.
- Changing the line width can make it more difficult to view editors side-by-side.
To automatically set the remote branch name to match the local branch name on push:
git config push.autoSetupRemote true
You can use VSCode to edit commit messages when using commands like git commit, git rebase, and git commit --amend. This will only work if the code command in the PATH. Follow these instructions to set up the vscode cli on macOS if it is not already set up. Run this command to set it up:
git config core.editor "code --wait"
If you use GitHub, and you'd prefer to not show your email in public commits, set your email to the one found on your GitHub account settings under the 'Email' tab. This is the same email used by GitHub Desktop, and when edits are made directly on the GitHub site.
git config user.email "[email protected]
Tip
You can add the --global flag to these commands to make them the default for all new projects.
I highly recommend enabling inlay hints in vscode. They give me the confidence to use TypeScript's type inference without feeling the need specify types 'for visibility'.
Add the following to the vscode user settings to enable all inlay hints for JavaScript & TypeScript:
{
"editor.inlayHints.enabled": "onUnlessPressed",
"javascript.inlayHints.enumMemberValues.enabled": true,
"javascript.inlayHints.functionLikeReturnTypes.enabled": true,
"javascript.inlayHints.parameterNames.enabled": "literals",
"javascript.inlayHints.parameterTypes.enabled": true,
"javascript.inlayHints.propertyDeclarationTypes.enabled": true,
"javascript.inlayHints.variableTypes.enabled": true,
"typescript.inlayHints.enumMemberValues.enabled": true,
"typescript.inlayHints.functionLikeReturnTypes.enabled": true,
"typescript.inlayHints.parameterNames.enabled": "literals",
"typescript.inlayHints.parameterTypes.enabled": true,
"typescript.inlayHints.propertyDeclarationTypes.enabled": true,
"typescript.inlayHints.variableTypes.enabled": true
}To temporarily disable inlay hints use CTRL + ALT (or CTRL + OPTION on Mac) -- Or, to reverse this behavior use:
{
"editor.inlayHints.enabled": "offUnlessPressed"
}VSCode is capable of using 'font ligatures' -- not everyone likes font ligatures, but I really enjoy them.
The two most popular fonts that support font ligatures are Fira Code and Jet Brains Mono. I typically use the 'Regular' *.ttf variant of each font.
After downloading and installing the font of choice, add the font to the fontFamily and enable font fontLigatures in the vscode user settings:
{
"editor.fontFamily": "'Fira Code', Menlo, Monaco, 'Courier New', monospace",
"editor.fontLigatures": true
}The fira code repository maintains a list of alternative fonts with ligatures.
- Oh My Zsh: Popular on macOS, where zsh is now default.
- Oh My Bash: Popular on Linux, where bash is usually default.
- Oh My Posh: Cross-platform. Popular on Windows. Works with many shells.
- Starship: Cross-platform. Written in Rust.
These are great frameworks for managing shell configuration. They include helpful functions, plugins, helpers, and themes.
Shell configuration frameworks are a quick way to add git branch & status information to the shell prompt.
Webstorm, Rider & RustRover are now free to use for non-commercial use!
Here are some tips for configuring the dev tools for this project in JetBrains IDEs:
- ESLint, Stylelint, Prettier
- Search for each name in the settings to easily find all relevant configuration.
- Double check all three plugins are installed.
- Set configuration to 'Automatic' for each and match the file extensions that are found in scripts section of package.json.
- (Optional) Set "Run on save" for each plugin if preferred.
- Install the "CSpell Check" plugin to reduce conflicts with JetBrains' built-in spell-checking.
- (Optional) Set keymap to 'VSCode' or 'VSCode (macOS)' for an easier transition
- (Optional) Search for 'ligatures' in the settings to enable font ligatures. JetBrainsMono is capable of displaying ligatures and is installed with the IDE
Warning
Depending on the maturity of the project, it may be better to look at the current configuration files for extreme-angular & release notes and then manually make changes instead of merging. If the Angular version has changed, then follow the guide to update Angular first before attempting to merge or make changes.
To pull in the latest changes, check out an 'update' branch and merging the latest changes from upstream/main:
git checkout main && git pull
git checkout -b update
git merge upstream/mainNote
The name of the remote may not be upstream depending on how this project was cloned.
There may be merge conflicts that need to be resolved. After a successful merge, install dependencies and then format, lint, test, and fix any new errors for all files:
npm install
npm run ci:all
