Pros and cons of adopting TypeScript for my blog

I’ve been a proponent for TypeScript for enterprise applications for some time.
TypeScript can be invaluable for teams and big applications. It reduces the occurrence of bugs and helps new developers understand the codebase.

But what about a small Gatsbyjs private project maintained by a single developer?

This blog fits the bill. After getting it up, I write articles during the weekend but code-wise I rarely add new stuff. I don’t want it to become my side project as I have other stuff that takes priority over making another blog.

Thus, I never spent the time to consider switching the starter template to TypeScript.

Adopting TypeScript in Gatsbyjs

Installing TypeScript is pretty much pain-free on Gatsbyjs. After installing the provided plugin, a basic tsconfig.json is all it is needed.

// basic tsconfig.json for gatsbyjs
{
  "compilerOptions": {
    "module": "commonjs",
    "target": "esnext",
    "jsx": "preserve",
    "lib": ["dom", "esnext"],
    "strict": true,
    "noEmit": true,
    "isolatedModules": true,
    "esModuleInterop": true,
    "noUnusedLocals": false
  },
  "exclude": ["node_modules", "public", ".cache"]
}

After turning the first file from .jsx to .tsx the first problem hits me: ESLint is not working.

Gatsbyjs ships without ESLint, so of course it is not working. The blog starter I used does have prettier enabled, but without ESLint no errors are displayed on vscode.

Enabling ESLint

I already have ESLint enabled for TypeScript at work. I can copy the config and add the relative Gatsbyjs plugin. That should be enough, right?

Configs are not always a walk in the park, and prettier + ESLint can feel exactly like the opposite.

After not getting anywhere with this, I started toying with vscode’s settings.json. After a few minutes, I managed to break ESLint error reporting for all my other projects as well.

And that’s when I noticed my vscode version was outdated. To update I had to change the whole package as Manjaro’s binaries were not getting updated.

I felt like Hal fixing a light bulb.

After fixing my vscode installation, I sat down and learned how ESLint and prettier work together.
It was luck that made the whole thing work for the project I work on. Now with this newly acquired knowledge, I could go back to convert the codebase to TypeScript.

Converting JavaScript to TypeScript

As I said earlier, the codebase is small. There are a dozen components files, another dozen styled-component files, and six pages. Since half of those have propTypes already in place, it should not take more than an hour to convert them.

Here you can read how to set up TypeScript, ESLint and prettier for Gatsbyjs.

TypeScript is the perfect tool to get to learn the graphql layer that powers Gatsbyjs. Most of the types I had to write were mirroring the graphql schemes.
TypeScript also highlighted optimizations in the data flow. Allowing me to delete a few doubled graphql requests.

Another big issue highlighted by TypeScript regarded the SEO component and schema.org markup. Many props were either missing or not used correctly. TS identified these problems that I wouldn’t have noticed otherwise. Things like meta keywords needing to be a string with keys separated by commas instead of an array.

TypeScript was able to direct me towards the little undetected bugs. My blog was working even before TS. With it, I am more aware of how things work thanks to typings. And I can better identify issues before they hit production.

Is TypeScript worth the hassle for a small one team project?

This was my original question, and why I waited more than six months to finally cave and convert the project. TS was able to give me a complete vision of props shape and requirements for all the libraries I use. This greatly increased the health of the application and the reliability of the code.
The total cost in man-hours to convert the whole project didn’t go over an hour. It also highlighted major hidden issues across the codebase.
If you have never used TypeScript, a small Gatsbyjs application is a perfect opportunity to learn it.

Bonus points: Email form was boom

While refactoring the code, I discovered the form on the /about page was broken. Google graced me with an unannounced change in API that broke it somewhere in the last few months. Luckily, I had also netlify in place catching all submissions. I can proudly say I didn’t lose any of the spam emails I received in these months.
I’ve now cleaned up the netlify integration and removed the broken google script I had set up. It works better with less code to maintain.