Milestone map
Milestone map
3 milestones
Convert one real module to strict TypeScript
1–2 weeks (1 hr/day)
Pick a real JavaScript project. Convert one meaningful module to TypeScript with strict mode on. Type every function signature and data shape the module touches. This proves you can read errors and model real data, not just annotate toy code.
Proof required
Link a commit or PR that converts one module (at least 300 lines) to TypeScript with `strict: true`, plus a screenshot of `tsc --noEmit` passing.
What gets checked
- Strict mode on, not loosened per file
- Real data shapes typed as interfaces or types, not `any`
- Module still works: tests or a run shown
Common mistakes
- Turning strict off to make errors go away
- Typing everything as `any` or `unknown` without narrowing
- Choosing a tiny file that proves nothing
Powstik Guide
One real module converted to strict TypeScript.
Steps
- Pick a module with real data flowing through it.
- Turn on strict in tsconfig before you start.
- Rename to .ts and fix errors from the top down.
- Model API and data shapes as named types.
- Run the module or its tests after converting.
Template
Conversion checklist [ ] strict: true in tsconfig [ ] 0 uses of any [ ] 0 uses of @ts-ignore [ ] Named types for each data shape [ ] tsc --noEmit passes [ ] Module still runs / tests pass
What gets sent back
- Strict mode turned off.
- `any` used to silence errors.
- A file under 300 lines.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Check tsconfig has strict: true
- Search the diff for `any` and `@ts-ignore`
- Ask why one type was modelled the way it was
You'll sign in first, then come straight back here.
Reach full strict coverage with zero any
3–5 weeks (1 hr/day)
Convert the rest of the codebase and add a lint rule that forbids `any`. Handle the hard parts: third-party libraries without types, dynamic data from APIs, and generic helpers. The lint rule is what keeps the codebase honest after you stop watching it.
Proof required
Link the repository at a commit where the whole codebase is TypeScript, `tsc --noEmit` passes in strict mode, and `no-explicit-any` is set to error in lint config with lint passing.
What gets checked
- Whole codebase converted, no .js source left
- no-explicit-any enforced as an error in CI or lint
- API data validated or narrowed, not cast blindly
Common mistakes
- Leaving some files as .js 'for later'
- Replacing `any` with `as` casts everywhere
- Lint rule set to warn instead of error
Powstik Guide
A fully typed codebase that forbids any.
Steps
- List every remaining .js file and convert them one by one.
- Install type packages for libraries that have them.
- Write small declarations for libraries that don't.
- Narrow API responses with checks, not casts.
- Set no-explicit-any to error and fix every hit.
Template
Coverage tracker
| File | Converted | any count | Casts | Notes |
|------|-----------|-----------|-------|-------|
Lint config
rules: { "@typescript-eslint/no-explicit-any": "error" }What gets sent back
- Any .js source file remaining.
- Casts used in place of `any`.
- The lint rule only warns.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Run tsc and lint on a fresh clone
- Grep for `as unknown as` and ts-ignore
- Check one API boundary for runtime narrowing
You'll sign in first, then come straight back here.
Defend your type design to a senior engineer
1 week
Walk a senior TypeScript engineer through the codebase's types. Ask them to change a requirement. Show how the types catch the ripple effects. Good types make changes safe; this milestone tests that yours do.
Proof required
Submit review notes (250+ words) with the reviewer's background, the requirement change they proposed, which type errors it surfaced, and one type you redesigned afterwards.
What gets checked
- Reviewer is a senior engineer who uses TypeScript at work
- A real requirement change was traced through the types
- At least one type was improved after the session
Common mistakes
- A reviewer who only skims and approves
- No requirement change tested
- No change made after feedback
Powstik Guide
Your type design, stress-tested with a changed requirement.
Steps
- Pick the three types the app depends on most.
- Explain each in one sentence before the session.
- Ask the reviewer to change one requirement.
- Make the change and count the errors it causes.
- Commit one type improvement afterwards.
Template
Review session log Date: Duration: Reviewer name: Reviewer role and experience: Challenge 1 (a requirement change): What they asked: My answer: Challenge 2: What they asked: My answer: Change I made after the session:
What gets sent back
- A reviewer who doesn't use TypeScript at work.
- No requirement change traced.
- No follow-up commit.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm the reviewer's TypeScript experience
- Check the requirement change is specific
- See the follow-up commit
You'll sign in first, then come straight back here.