Squeezing maximum type safety out of Typescript with TypeStrict
Personally, I belive that Typescript is one of the best things that happened to the Javascript community. We got strongly typed language with familiar syntax backed by powerful companies like Microsoft, Google any many others (including Neufund! 😆).
Across the years Typescript got better in finding bugs in your code. Since the version 2.0 (in strict mode) we got safe nullable types and other goodies that help writing correct code. But still, there are a lot of situations where one cannot be sure that the code written by a programmer will behave the way it should.
Static analysis for the rescue
Tslint, a Typescript code linter is the right tool for enforcing these additional rules. There are a lot of useful rules out there in the wild which can help you.
Take for example the no-floating-promises rule. It will make sure that when you call a function which returns a promise you need to handle it somehow. Not doing so can result in hard to debug, “swallowed” rejected promises. There are plenty of similar, powerful rules that not only save a programmer’s time, but reduce the amount of bugs shipped in production.
TypeStrict — one ruleset to rule them all
TypeStrict is a set of rules for tslint that gathers all these various rules, scattered across different projects, which only care about type safety. Formatting and code style are ignored which makes TypeStrict perfect for the further extension in your own config (and to use alongside with tools like prettier.io).
TypeStrict currently consists out of 30 rules. They will warn you for example when the type inference for type parameters goes wrong (no-inferred-empty-object-type) or when you’ve most likely just made a copy paste error in conditional logic (no-all-duplicated-branches). It will make async programming even simpler with the previously mentioned no-floating-promises rule. You can browse the full rule list on github.
Going further, you can use the Tslint language service plugin to make tsc warn you about bugs as you write your code. A great thing about this setup is that you can configure it to only take into account the TypeStrict rule set — this will skip all auto-fixable code style related problems.
Conclusion
At Neufund, we’ve been using TypeStrict for a few months already and it’s been great. It’s super easy to add it to already existing projects — try it out! I am sure that it will save you plenty of time.
Follow me on Twitter for news, tips & tricks regarding Typescript, Javascript and blockchain.
Visit our subreddit to join the conversation and read all the information you need about Neufund in this post. Or join our telegram chat if you have questions or want to meet the Neufund community and team.
