TypeScript engineering
Most TypeScript conversations are really about change safety. A front end several people edit, a data shape that moved last month, and a tidy-up of the code that nobody wants to start.
01Capabilities
Four places the compiler pays for itself
TypeScript is a type system on top of JavaScript, not an architecture. The work below is where types earn their cost, and in each case the payoff arrives in the second year rather than the first sprint.
- Interfaces
Product front ends several people edit
Interfaces where more than one person is in the code and the data shapes are not trivial, built with React or Angular as part of a web build. Types are what let someone rename a field without reading every screen first.
- Contracts
Shared contracts between front end and back end
One set of types describing the API, shared or generated rather than hand-copied, with Node.js on the server. A great many front-end incidents are simply a contract that changed with nobody watching.
- Roles
Marketplace and multi-role platforms
Products where each kind of user sees a different slice of the same data, of the kind in our e-commerce and marketplace work. A type that spells out which combinations are legal beats a comment explaining which fields are set when.
- Adoption
Adding types to an existing JavaScript codebase
Turning a JavaScript codebase into one a compiler can check, without a rewrite and without a feature freeze. A staged operation with a measurable finish line, run under an ISO 27001:2022 certified information-security management system.
02Case studies
Two builds behind the advice on this page
Two published builds, one a consumer marketplace and one a building-security product.
See all case studies
MarketplacePet4MeA comprehensive pet adoption and community marketplace, designed from the ground up to connect animal lovers, eliminate hidden fees, and support responsible pet ownership.- SecurityiOS and Android apps for a building-security software companyunicrew contributed to the iOS and Android apps of a security software company, built on its existing web client, through to the production release.
03Fit
When TypeScript is the right fix
TypeScript is our default for any front end or Node service more than one person will edit, because what it buys is safety when the code changes rather than fewer bugs on day one. It is not free, and it is not the answer to every question that arrives with TypeScript in the subject line. Each row below says where that question is best answered, from TypeScript itself to runtime validation or a framework page.
| Your situation | What we recommend |
|---|---|
| A new product, several engineers, and code expected to live for years | Use TypeScriptThe cost at build time buys cheap renames and safe deletions later, which is where the money is. |
| What you are actually asking is which framework to use | Different pageSee React, Vue or Angular. All three take types, so the decision is about your interface and your team. |
| A large JavaScript codebase, a tight deadline, and nobody on the team has used TypeScript | Check-only mode firstSave the full conversion for a later quarter. Turn the compiler on in check-only mode, describe the boundaries, and let the rest ride behind feature work. |
| What you need is confidence in the data arriving at runtime | Runtime validationTypes are gone by the time the code runs. What you want is a check on the data itself at the edge, which is separate work and easy to mistake for this one. |
| A single script or a small automation with exactly one owner | Annotated JavaScriptPlain JavaScript with a few comment annotations is enough here, and the build tooling is not free to keep running. |
| Back-end services, and the team is strongest in C# or Java | Different pageSee C# or Java. Both are statically typed already, and moving to Node just to get types is a large cost with a small payoff. |
Scope
What we own is the strictness policy and what it costs. Which compiler settings are on. Where an escape hatch is allowed, and who signed it off. Whether the types describe what really happens, or only the case where everything goes right. A codebase that compiles and lies is worse than one with no types, because people trust it. unicrew has been writing typed front ends and services since 2012, with 100+ senior in-house engineers across six countries, under an ISO 27001:2022 certified information-security management system.
TypeScript makes a codebase safe to change for engineers who did not write it. We introduce it at the boundaries first, where it adds the most value, and extend it from there while delivery continues.
Andrii BurdaSenior Engineering Manager, unicrew04Delivery
Turning the strictness up without stalling delivery
Inherited TypeScript is usually partial: some strict directories, some untouched JavaScript, and a pile of suppressions. Four steps, in this order.
- Measure the error surface firstRun the compiler in check-only mode and count what it finds, per directory. That number decides whether this is two weeks of work or a quarter, and it settles the argument faster than any discussion.
- Type the boundaries before the internalsAPI responses, storage, third-party libraries and anything crossing a process. Wrong types at the edges are where runtime surprises come from. Wrong types three functions deep are mostly noise.
- Ratchet strictness and let CI hold the lineStrict settings arrive per directory, with a rule that the error count may fall and not rise. A big-bang strict flip on a large codebase produces thousands of errors and a branch nobody ever merges. Test automation goes in alongside, through the same QA practice as our own projects.
- Inventory the escape hatchesEvery remaining any and every suppressed compiler error gets written down with a reason and an owner. An untracked suppression is a permanent one, and it is what quietly turns a typed codebase back into an untyped one.
05Stack
What a typed project usually connects to
The decisions that arrive with this one, each with a page of its own.
06Questions
The questions a migration always raises
Answered the way we would answer them live. If yours is not here, it is a good first message.
Yes, and on a codebase you already own it is often the sensible shape. The type strategy is part of what our engineers own, because it is a set of decisions, and left undecided they produce a codebase that compiles and still breaks. An architect outside the delivery team reviews the design, and the work goes through the same QA practice as ours. Team extension is managed teams; the outcome is web development.
It depends on how many people are in the code and how long it has to live. One owner and a stable feature set, and JavaScript with a good linter is a defensible choice. Several contributors, or a product that will keep being reworked, and the absence of types is what makes every change expensive. The middle path is real and underused: keep the files as JavaScript, turn the compiler on to check them, and describe the boundaries in comments.
For a few days, yes, for anyone who already knows JavaScript. After that the cost is not the language, it is two habits: a build layer somebody has to maintain, and the temptation to write types as a puzzle. Clever type gymnastics nobody else on the team can read are worse than a plain interface, and we push back on them in review. Types describe the domain, they do not demonstrate range.
If the back end is already JavaScript, yes, and the shared-contract argument is the strongest reason: one definition of the API shape instead of two that drift. See Node.js for how we run that. If your services are in C#, Java or Python, do not move them to Node in order to get types. Rewriting a working back end to unify the language is a large cost with a small payoff.
A scoping call with an engineer rather than a salesperson. For an existing codebase we ask for repository access first, because half an hour with the compiler output tells us more than an hour of description. You get back a written read on what to describe first, what can wait, and what the strict-mode target should be. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Bringing the compiler to a codebase that already ships?
Send us the repository, or a description of where the type system is fighting you. You will get an engineer's read on what to describe first and what to keep as it is, starting with web development.