Using TypeScript by default in 2021
Vitor Capretz / January 26, 2021
9 min read • ––– views
Been there, done that.
So when I decided to take it slower for my own mental sanity, TypeScript was one of the technologies I deliberately chose to scope out of the things I would spend my time learning and let it evolve, and if needed I would learn it.
We were growing fast, a few months later we were reaching 200-300 developers working in the same app and still hiring.
Some developers with previous TypeScript experience and willingness to try it out started looking for guidance, better tooling, and official support from the teams who supported the app. It eventually got enough traction, knowledge was being spread, we started understanding the benefits and we were open to taking the time in our smaller teams so we could assist whenever possible.
The thing is that for it to happen I believe everyone (or most of the people at least) should be involved.
Say you are consuming services or modules from different teams and they decide not to collaborate with the migration, then a few
any typings start spreading and soon you lose a lot of the value that having a strongly typed codebase brings.
That's why I believe having started with knowledge sharing was the right step for us.
We are around 300 developers now and I would say at least 80% of our codebase is strongly typed, I feel more confident with a change I introduce, as soon as I see the TypeScript compiler screaming at me because I'm trying to use a component with missing props without the need to actually wait for the app to build and see it as a warning in the console instead, I thank the TypeScript gods.
It's hard to reach 100% typing in such a large codebase, even tho I still strive for it and we should continue to do so, we are still building products, shipping new features, and fixing bugs.
We can't always stop the train.
It's also important to keep your eyes open, as new developers join the company they will not have the same background, so have internal docs with guides and make sure knowledge is being constantly spread.
Keep looking for improvements and know it's not a one-time event. I strongly believe the benefits do pay off.
Everything in tech (maybe in life?) comes with tradeoffs, you choose one thing and you need to understand what's the cost, can you roll back from your decisions easily? Are the benefits strong enough to keep you on the same path?
Here are some of the things I personally struggle with:
I spend most of my time writing React Native code in a codebase that also compiles to Web, so it happens sometimes that the same file
MyComponent will have
.native.ts and then
.web.ts extensions, I am not sure if we just didn't quite find the right setup yet but navigating to those files by
CMD + Click on VSCode doesn't really work well in our huge codebase.
We have to declare a common
MyComponent.d.ts file that exports the correct typings for all platforms, which also makes it harder to split between native or web-only props a component might receive.
There will be moments where you're in the flow building a cool feature, then get stuck in a type that's giving you some trouble.
TypeScript inference system works great for simple things, but try adding
ramda and using
pipe with multiple curried functions and you're lost.
There are other particular scenarios where a function might not be properly typed, then you have to use
ReturnType and hope it works.
You'll lose some time every now and then just trying to figure out the types, which will make you wonder if it's all even worth it.
Adding TypeScript to your codebase will be a larger barry to entry for everyone working on your project.
It's one step more in your onboarding and a culture mindset you're going to have to train people for, that includes having more documentation and people willing to spend some more time with the new person. Or even adjusting the expectations so you're not pressuring a new developer to start delivering projects when they are still adapting to your codebase.
Hiring can also be more difficult, it's a tricky situation since one might say "make it a requirement for new candidates" and you possibly leave a lot of good people out from your interview process because they didn't have the opportunity to learn TypeScript yet.
For me, the best approach is to make it clear in the interviews that you don't expect them to know it right away, but they should be comfortable and willing to learn in the first few weeks/months when hired (that applies to React Native developers too since it's hard to find people with experience in it we often hire Web Developers who are willing to step on the native land).
Yeah, this applies to anything in tech really, programming languages also die. But we do have to keep it in mind when making decisions. You get the point.
Part of a decision in betting in TypeScript was that it eventually became what seems the standard approach for the community. Remember I mentioned we also had files typed with
Flow instead? What if we bet hard on TypeScript just so it died after a while? That's one of the reasons not to jump too early in some decisions that may cost too much to revert.
Every personal project I do now start by bootstrapping it with TypeScript, and the experience is great! If you can't move an existing codebase, try starting with the new ones you're still setting up, or introduce TypeScript while allowing files in JS so there's no need to migrate all at once.
Tip: Most commands to bootstrap a project nowadays have a TypeScript template, try using them more often! Some examples are:
npx react-native init AwesomeTSProject --template react-native-template-typescriptfor apps or
npx create-next-app --example with-typescript with-typescript-appfor websites.
TypeScript still has a long way to go, but I believe now we are not anymore in the "too soon" moment, it has been proven to work for many different types of projects in all sizes and the support from the community is great!
So if you haven't yet, give it a try!
At this point there are tons of resources out there so you can learn how to setup TypeScript in any kind of project, no matter if you are using Vue, React, Svelte, or even just setting up a small server with Node.js. Go to your favorite search engine and look for
TypeScript + [your favorite cookie flavor], you'll find it.
Personally, I keep coming back to TypeScript's website since I know it will contain the most updated information.
I've been using a lot of GraphQL recently and I've been benefiting from the TypeGraphQL framework to generate typed schemas from my Back-end services that then can be shared with the applications consuming it.
Ben Awad's incredibly long and useful YouTube tutorial was also a great refresher for me on one of the ways a modern application can be built.
My good friend and one of my TypeScript mentors, @Yurick_, also recommended tsdx for when you need to start new TypeScript out of the React realm. I didn't personally use it but it might be worth it to take a look!
So, do you already use TypeScript? Do you now hate me for even suggesting it? Let's chat on Twitter so I can hear your thoughts!
I hope I gave you a nice perspective from my own experience, I know it's not the same for everyone but I'm curious to learn as well 😃
Have a great day! 👋