# The type-transformations workshop makes you solve before it shows the answer

> This repository is the exercise half of Matt Pocock's Total TypeScript course, and its design principle is stated plainly: the video explains a problem, you are asked to find a solution, and the tests tell you whether you succeeded. Every exercise is a pair of files, a .problem and a .solution, and the runner lets you switch between them at the command line.

**total-typescript/type-transformations-workshop** — Master transforming types in TypeScript

- Repository: https://github.com/total-typescript/type-transformations-workshop
- Website: https://totaltypescript.com
- Stars: 915 · Forks: 339
- Language: TypeScript
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/total-typescript-type-transformations-workshop

## The pedagogical bet: you try before you are told

The README describes the course format in a way that is unusual for a repository, and it explains the choice of material.
The course is split into exercises, and each exercise is split into a *.problem and a *.solution. The README says the course encourages active, exploratory learning. In the video, the author explains a problem, and you are asked to try to find a solution.
The instructions for taking an exercise are a loop. Run npm run exercise, choose which exercise you would like to run. Then check out TypeScript's docs, try to find something that looks relevant, and give it a go to see if it solves the problem.
The feedback signal is the test suite. You will know if you have succeeded because the tests will pass.
And then the design decision that makes it work: if you succeed, or if you get stuck, unpause the video and check out the *.solution. You can see if your solution is better or worse than mine.
That last sentence is the whole course in miniature. The answer is always available, but it is positioned after the attempt rather than before it, which is the difference between a tutorial and a workshop. Comparing your solution against the author's is where the learning about TypeScript idioms actually happens, since a passing test tells you the behaviour is right but says nothing about whether the types read well.
The audience is developers who already write TypeScript and want to get better at the type level rather than at the runtime level.

## Every exercise is a problem file and a solution file

The repository layout is small and follows from that format.
The top level entries are .github/, .gitignore, .vscode/, README.md, an og-image-new.png, package-lock.json, package.json, renovate.json, src/, tsconfig.json and vite.config.mts.
The src/ directory holds the exercises themselves, and the convention is that each exercise directory contains two TypeScript files with the same base name, one suffixed .problem and one suffixed .solution. The CLI can swap between them, so the same directory serves as the working copy for the attempt and the reference for the answer.
The test runner is Vitest, configured through vite.config.mts, and vite-tsconfig-paths is in the dependency list, which matters because it lets the project use TypeScript path aliases in the tests rather than relative imports everywhere.
The tsconfig.json at the root is the single source of type configuration, and the exercises rely on it heavily, since a workshop about type transformations needs a strict compiler configuration to be meaningful.
There is also a .vscode/ directory, which is a small detail with a real effect on a workshop: opening the repository in an editor that already knows the path aliases and the strict settings removes the friction of an exercise failing to resolve an import for reasons unrelated to the type you are trying to write.
The result is a repository that is a course, a test suite and an editor configuration at the same time, and the whole thing is designed to be cloned and run rather than read.

## One command per exercise, and a separate command for the answer

The script names are the interface, and they are deliberately uniform.
```json
"exercise": "tt-cli run",
"solution": "tt-cli run --solution",
"e": "npm run exercise",
"s": "npm run solution",
```
Running the exercise script with no argument opens a prompt for choosing which exercise you would like to run, and the alias lets you type the shorter form. The solution script is the same thing with the --solution flag, which switches the runner to the .solution files instead of the .problem ones.
Then there is a numbered set, which is the part that makes the course scriptable.
```json
"e-01": "tt-cli run 01",
"s-01": "tt-cli run 01 --solution",
```
Every exercise has an e-NN and an s-NN script. That means a CI job can run exercise 07, and a colleague who is stuck on exercise 12 can jump straight to the solution for that one without losing their place in the rest of the material.
The runner itself is a separate package, @total-typescript/exercise-cli, and the README only documents one command from it, npm run exercise, whose behaviour is to open a prompt for choosing which exercise you would like to run.
Two other scripts are worth knowing about. The prepare script runs tt-cli prepare-stackblitz, which prepares a StackBlitz workspace, and the README mentions that you can open the repository in Gitpod as an alternative to cloning it. The ci script runs the test suite from a scripts/tests directory with npx vitest run, and there is a matching update-snapshots script that runs the same thing with the -u flag.

## StackBlitz and Gitpod: the browser is a supported way to take the course

Two details in the README tell you the course is meant to be taken by people who do not necessarily have a local TypeScript setup ready.
The quickstart says to clone this repo or open in Gitpod, and the prepare script calls tt-cli prepare-stackblitz. StackBlitz is a browser based development environment that runs Node in the browser, so a learner can open an exercise, edit it and run the tests without installing a toolchain.
For a workshop about types, the toolchain is not a trivial hurdle. Type checking, a test runner and an editor that understands path aliases is a fair amount of setup for someone whose goal is to practise writing mapped and conditional types rather than to configure a project.
The trade-off is that the browser path is slower and more constrained than a local checkout, and for someone who already has a TypeScript project set up the local path is faster.
The stack of dependencies explains what the exercises are made of. There is ts-toolbelt at version 9.6.0, which is Matt Pocock's own type utility library and almost certainly the source of much of the type level vocabulary the exercises teach. There is jsdom and cross-fetch, so exercises can involve DOM types and fetching, which is where the trickier type transformations tend to live.
There is prettier at version 3, TypeScript at 5.4.5 and Vitest at 2.0.0, and the whole dependency set is devDependencies only, because nothing here is meant to be imported into a production project.

## The CI script and the snapshot tests

The repository tests itself, which is worth a moment because the subject is type level behaviour and the usual complaint about such exercises is that they are only checked by their author.
The ci script runs the test suite from a separate scripts/tests directory.
```json
"ci": "(cd scripts/tests && npx vitest run)",
"update-snapshots": "(cd scripts/tests && npx vitest run -u)",
```
The presence of a snapshot update script tells you these are snapshot tests, where the expected output of a type level expression is recorded and compared. That is the right approach for this subject, because the interesting question is often what a type evaluates to as a string, and a snapshot captures that without writing an assertion by hand.
The risk with snapshot tests is the obvious one, that they accept whatever the current behaviour is. The -u script is the escape hatch for when the behaviour is supposed to change, and it exists as a separate command rather than a flag on the normal run, which is a mild guard.
There is also a renovate.json at the root of the repository, which is how the dependency versions in package.json get updated. For a workshop that depends on specific TypeScript and Vitest versions, and where a type error can be a genuine difference in behaviour rather than a mistake, automated dependency bumps are a risk worth noticing, and the presence of the tool at least makes it visible.

## A companion to a paid course, not a standalone curriculum

The README is direct about where this repository sits in the wider product.
The acknowledgements section asks readers to say thanks to Matt on Twitter or by joining his Discord, and to consider signing up to his Total TypeScript course at totaltypescript.com. The homepage for the repository is totaltypescript.com as well.
So the exercises here are the workshop half of a commercial course, and that is a reasonable arrangement for a subject like this. Type level programming in TypeScript is one of the areas where reading documentation is slow and working through problems is fast, and a set of graded exercises with solutions is a better teacher than a chapter.
The practical consequence for an evaluator is that the repository is self contained for the exercises it contains, but the explanations live in the videos. The README asks you to open TypeScript's docs yourself and find something that looks relevant, which means the repository deliberately does not hand you a hint sheet for the harder problems.
On the licence, the package.json says GPL while the repository licence field says unknown, and there is no licence file among the top level entries. The package.json is the more specific statement, but for a repository that is explicitly a teaching aid, it is worth reading what applies before you fork it.
On activity, the last push was on 2026-08-08, the repository is not archived, and there are no GitHub releases, which is expected for a course repository whose version history lives in the package.json version field rather than in tags.

## Conclusion

Adopt this workshop if you already write TypeScript and want to practise mapped, conditional and template literal types with instant feedback, and you are comfortable reading the compiler errors as hints. Do not adopt it as a standalone curriculum, because the explanations live in the accompanying videos and the package.json identifies it as the exercise half of the Total TypeScript course. Before you start, check the TypeScript version in your own project against the 5.4.5 used here, since type level behaviour can differ between releases, and read the licence situation, because the package.json says GPL while the repository licence field says unknown.

## FAQ

### How do I start the type-transformations workshop?

Clone the repo or open it in Gitpod, run npm install to install all dependencies, then run npm run exercise, which asks you which exercise you would like to run and runs it. You can also open the repository in a StackBlitz workspace.

### How are the exercises structured?

Each exercise is split into a *.problem and a *.solution file. The runner switches between them, so you attempt the problem file and can compare with the solution file when you are done or stuck.

### Can I run a single exercise by number?

Yes. Every exercise has a numbered script pair, e-01 runs exercise 01 and s-01 runs the solution for exercise 01, both through the tt-cli run command with the --solution flag for the latter.

### Which tools do the exercises use?

The devDependencies list Vitest for the tests, ts-toolbelt for type utilities, TypeScript 5.4.5, vite-tsconfig-paths so the tests can resolve path aliases, jsdom and cross-fetch, prettier, and the @total-typescript/exercise-cli runner that drives the exercise and solution commands.

### How are the tests run in CI?

The ci script runs npx vitest run from the scripts/tests directory, and there is a separate update-snapshots script that runs the same suite with the -u flag to rewrite the recorded expectations.

## Sources

- [Issues](https://github.com/total-typescript/type-transformations-workshop/issues)
- [Project website](https://totaltypescript.com)
- [README](https://github.com/total-typescript/type-transformations-workshop/blob/main/README.md)
- [total-typescript/type-transformations-workshop on GitHub](https://github.com/total-typescript/type-transformations-workshop)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/total-typescript-type-transformations-workshop