Be Type Strict Without Typescript*
*Ok, you still need VSCode and Typescript installed, but you don’t have to write in it. I just wanted a clickbait title...
If you prefer to write in Pure Javascript™️ but still wish you could ride the 2019 hype train of static type warnings in your IDE, have no fear! Around August 2018, Typescript introduced JSDoc support, which means we can now infer variable types in our Javascript files based on @typedef and @param flags.
There are a lot of benefits to JSDoc in general such as cleaner code, better documentation, and built-in VS Code and Webstorm warnings, but adding Typescript to the mix adds an extra layer of protection when dealing with complex object properties or dealing with types in functions.
Let’s dive right in to getting VS Code setup. If you’d like a deeper explanation of why you might want to go this path instead of writing Typescript, scroll to the end. To get started, make sure you have the latest VS Code installed, then enable these settings. It’s the power of the combined CheckJS and JSDoc support that lets us leverage these abilities.
Ok, let’s write some code! We’ll setup a basic ES6 class and extended class to show how we can create some class properties and function arguments. It’ll also give us a chance to explore documenting destructured parameters for our function parameters.
Let’s jump into some of the errors! First off, it won’t let us create a new object without the proper destructured argument parameters. The TS hint provides insight to the required and optional fields along with their types.
Once we fix that pesky problem, you’ll notice it won’t let us set the original class’s boolean flag to a number. Again, strict typing to the rescue!
Additionally, it won’t let us mix up our default values with our property types!
Even if we fix that, VSCode and Typescript are smart enough to stop you from overriding class methods and changing the type behavior.
These are just a few examples, but hopefully it gives you an idea of some of the benefits you can get from this setup. It does take a bit of guess work on some of the more complex JSDoc structures, but VS Code is there to guide you along the way. I’ll discuss below some of my personal opinions on the subject.
I think the main driver for me has been the personal conflict of hearing the daily buzz about Typescript but wanting to continue writing in Javascript. We’ve made the team decision to not have a compile step on our NodeJS repos but we want the benefits of strict type warnings. Webstorm’s intellisense has taken us really far, but type warnings were never a part of their solution.
Additionally, we already have a ton of JSDoc in our codebases, so it was merely a matter of cleaning up the documentation as we worked on code. Both VSCode and Webstorm provide nice ways to auto-add doc blocks too.
At the end of the day, you need to weigh your options within the constraints of your company and project, and make the best call. For us, this was the path of minimal resistance to improving our ability to work as a team while reducing the mental burden of remembering the codebase. I’d love to hear your approach too!
