angular-challenges: 65 exercises for learning Angular by doing

A curriculum shaped like a monorepo

The repository description is plain, a set of Angular challenges to practise and train on Angular, and the repository is a pnpm and Nx workspace rather than a folder of scripts. The tree shows the parts: apps/ for the challenge applications, libs/ for shared libraries, a cli/ directory, docs/ for the documentation workspace, website/ for the published site, tools/ for repository tooling, and a challenge-number.json at the root that evidently indexes the challenges. There is also the usual modern workspace furniture, with nx.json, pnpm-workspace.yaml, tsconfig.base.json, an eslint.config.mjs, jest.config.ts and jest.preset.js, a .devcontainer/ for a reproducible environment, .husky/ with a commitlint.config.js, and an .all-contributorsrc. The published site is at angular-challenges.vercel.app, and the README links all 65 challenges from it. The interesting structural decision is that the same workspace holds the exercises, the documentation and the site, so a contribution to a challenge and a contribution to the docs are the same kind of pull request.

Three purposes, and an open door for anyone stuck

The project states three purposes, and they are worth quoting because they explain why the repository is shaped the way it is. The first is to assist you in becoming better at Angular and its ecosystem. The second is to share best practices and different implementations of the same problem, to gain diverse perspectives. The third is to lower the barrier to open source contribution. That third one is the unusual part, and the README backs it with an invitation: if you are struggling with a concept, open an issue, and the author says he will attempt to create a challenge based on that idea. The line that summarises the philosophy is that learning by reading is good but learning by doing is better. The second purpose has a concrete design consequence, since the same problem is solved several ways in the same repository, which is only sensible if the goal is to show the range of valid approaches rather than to ship one blessed implementation.

The contributor table is the governance model

The README's contributor section is the largest single block of it, and it is not a list of names but a map of who does what. Each contributor row carries a set of role links, and the roles are the interesting part: create a challenge, code, documentation, ideas, planning and feedback, design, and translation, with French and Russian translations called out as their own roles. That is a description of how a learning project actually gets maintained, and it is more useful than an onboarding document, because it tells a newcomer which of those they can take on. A contributor with a good idea for an exercise can add a challenge without writing any code, a contributor who writes the documentation is filling a role that is separate from the code, and the translation role means the exercises are intended for people whose first language is not English. The stated invitation is that you should feel free to share your ideas and that they are more than welcome.

The stack tells you what the exercises cover

The package manifest is the most informative document in the repository, because a curriculum's dependencies are its syllabus. The workspace runs Angular 22.1.2 across the usual packages, with the server-side rendering package at 22.1.4, and it includes @ngrx/component-store and @ngrx/operators at 21.1.1, which says that state management with NgRx is in scope rather than being an afterthought. It includes @ngneat/falso at 7.2.0, a fake data generator, which tells you the exercises are built around data you do not have to invent, and @tanstack/angular-query-experimental, which points at server state as a topic. Tailwind CSS 4.2.1 is there, so styling is part of what is being practised, and the tooling is modern rather than legacy: the Analog plugins for Vite and Vitest, the Nx Angular plugin at 23.1.1, and Express. The environment requires Node 22 or newer, and the package manager is pnpm at 10.23.0. The consequence for a learner is that the exercises are current Angular, not a museum of old patterns.

pnpm is enforced, not suggested

The first thing in the README is a warning, and it is about tooling rather than about Angular. The project now uses pnpm as its package manager, and you are asked to make sure pnpm is installed before running any commands, globally with npm install -g pnpm or by following the official installation guide. The enforcement is not advisory, because the package manifest contains a preinstall hook that runs npx only-allow pnpm, which fails the install if you reach for npm or yarn. There is also a postinstall step that runs playwright install chromium, so the browser used for end-to-end checks is fetched as part of installing dependencies, and a prepare step that installs the husky hooks. The scripts are thin wrappers over Nx, with ng mapping to nx, start to nx serve and build to nx build. One detail is worth knowing before you wonder why your test run only touches one directory: the test script is nx test forms-crossfield-validation-signal-form --ui --watch, which targets a single named challenge in watch mode rather than running the whole suite.

Where this is the wrong choice

Four limits are clear. The first is that the apps are exercises, not a product skeleton. Each challenge is a small problem with a solution, and a team that wants a starting point for a real application will find something that demonstrates a concept rather than something that structures an application. The second is that the repository is coupled to a moving target. It is pinned to Angular 22.1.2 and NgRx 21.1.1, and a curriculum of exercises that depends on the current major version will need revisiting when Angular moves, and a learner arriving a year from now may find the answers out of date even if the exercises still make sense. The third is the packaging constraint, because a preinstall hook that rejects npm means the repository cannot be cloned and run with the package manager most people already have, which is a real obstacle for the quick try-it that a challenge is supposed to encourage. The fourth is that the value is concentrated in the solutions, and the documentation site is the interface, so a reader who wants to solve rather than to read has to resist looking, which is the entire exercise.

Editorial conclusion

Adopt this repository if you are learning Angular or onboarding a team onto it, because a set of small exercises with published solutions is a better training surface than a tutorial series. Do not adopt it as a starter for a production application, because the apps are exercises rather than a product skeleton. Before you run anything, note the switch to pnpm, with the repository refusing other package managers through a preinstall hook, and that the current tree targets Angular 22 with Node 22 or newer, and that the test script is wired to a single challenge rather than to the whole suite.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. tomalaforge/angular-challenges on GitHub