Richard Gill's blog
Starting a project and building a team? Use a TypeScript monorepo.

Starting a project and building a team? Use a TypeScript monorepo.

If you're starting a new project and hiring a team: Use TypeScript in a monorepo and hire fullstack TypeScript engineers

Richard Gill's photo
Richard Gill
·

4 min read

This recommendation applies to a large subset of software projects. Projects which involve more than 1 of:

  • Website app

  • App

  • Desktop app

  • A Backend

    • Server-side code which exposes an HTTP API, talks to a database, does batch jobs/queue stuff.

AND

There is no compelling reason to use another tool for the job. For example: writing an operating system? Use C++, Rust or Zig. Doing some Machine learning? Use Python.

I would guess this recommendation applies to 80%+ of software projects / startups.

Why use TypeScript?

Staffing

If you use TypeScript everywhere, you can staff fullstack TypeScript engineers on your project and make them responsible for all the code end-to-end.

Higher ownership

Engineers can fully own the features they are building and the product. They will have an improved appreciation of what they're building and why they're building it because they're building the frontend which users interact with. This leads to better micro-decisions as they work and an overall better culture of engineers owning the product.

Less communication overhead

Having individual engineers building entire features reduces communication overhead. What was previously the work of two people is now the work of one, this makes project management easier you just need to find 1 engineer to work on a feature rather than 2. There are fewer misunderstandings, when the engineer is writing backend code, they know what they need for the frontend code. If you need a status update on a feature, there is only one engineer responsible.

Staffing your project with fullstack Typescript engineers that can work on everything is going to let you ship code faster. This means you can hire fewer engineers, which also means less overhead.

More flexibility

Because all your engineers can do everything your minimum team size decreases to 1, good for projects which are just starting.

If part of the system, for example the backend, becomes a bottleneck, you can allocate any or all of your engineers to work there.

Large talent pool

TypeScript has a large talent pool, so recruiting new engineers to the team should be easy. However, it can be challenging to find TypeScript engineers with solid engineering backgrounds.

Code infrastructure

As a secondary bonus, monorepos come with a bunch of benefits:

  • You can share code between your app, website and server.

  • Your code formatting and linting can be setup just once and shared across the entire monorepo.

  • You can have one pull request per feature, covering the code changes needed in both the client and the server.

The Tech Stack

Let's break down the various areas and how it might look

Traditional languages:

  • Website: JavaScript / TypeScript with React

  • App: iOS: Objective C or Swift | Android: Java or Kotlin

  • Desktop App: Objective C or Swift or C++

  • Server: Any

If you use Typescript:

  • Website: TypeScript with React

  • App: TypeScript with React Native

  • Desktop: TypeScript with React website wrapped in Electron

  • Server: TypeScript with Node.js

React Native, Electron or Node.js are not without tradeoffs. They all have issues. However, the benefits of only having fullstack TypeScript engineers that can work on everything outweighs the issues above.

A good starter stack here is the T3 stack with Turbo for monorepos: https://github.com/t3-oss/create-t3-turbo

Why now

TypeScript, Microsoft's JavaScript-like typed language, has taken off. In 2022 engineers were writing more TypeScript than JavaScript in their projects.

A few years ago using TypeScript created extra friction for engineers. Many libraries didn't always come with TypeScript types. But TypeScript's widespread adoption means nearly all libraries today work great with TypeScript.

TypeScript isn't perfect. It still compiles to JavaScript, which is itself imperfect. But in my experience, it's rare to run into any issues with TypeScript.

Monorepos got good

A few years ago, setting up a monorepo with the last gen tooling (Yarn + Lerna) was painful.

But in the past couple of years, the tooling for monorepos in TypeScript got good.

A new package manager became popular: pnpm.

pnpm has a feature called 'workspaces' which lets projects in a monorepo depend on each other. Other package managers had similar features in the past, but the difference with pnpm is: 'it just works'.

TypeScript has some excellent new monorepo tooling which work great on top of pnpm:

These tools make working with your monorepo on the command line easier. Their main job is allowing you to define the inputs and outputs of each of your monorepo's tasks, and then use a cached result when a task has already been run. This speeds up big mono repo builds.

Conclusion

The suggestion to build your entire product with TypeScript is partially a technical recommendation, but predominately it's about the staffing. Lower communication overheads, higher ownership and better productivity.

If you're starting a new project and building a team, a TypeScript monorepo is worth a look.

TypeScriptmonorepoproduct