Next.js Awesome Typescript integration
A lot of people love Next.js. A lot of people love Typescript. So, eventually a bunch of people will want to use them together and, as you can guess, it’s already happening. So, what options do we have? The default one would be to use next-typescript package from Zeit, the official one. It uses ts-loader and it works fine, but there’s figure number two (if not even one) on webpack-typescript-loaders market: it’s awesome-typescript-loader. The main reason to use it is its performance optimizations: integration with babel (which is the perfect case for Next.js) and running type checker in separate process (you can also do it with fork-ts-checker-webpack-plugin, but having batteries included is a nice thing). Please be aware that it’s not always quicker than ts-loader, so don’t just blindly switch it without real measurement. But usually you’ll get a boost in compilation time just by using it properly, so let’s dive in and try to integrate Next.js with Awesome Typescript Loader, yay!
Disclaimer numero uno: ⚠️ this is only compatible with Next.js v5️, not v6, see this reasoning for more details
Disclaimer numero uno: if you’re interested in the details you can just jump straight and use my
next-awesome-typescriptplugin
So, first thing we want to do is to use this super nice Next.js v5 feature called Universal Webpack, cause it allows us to somehow alter the default Next.js webpack configuration. You can do it by supplying webpack function along with other configuration in next.config.js file.
Ok, let’s add awesome-typescript-loader.
Pay attention to the line with defaultLoaders.babel, because it basically means that we ran our files through both loaders, awesome-typescript-loader at first and then babel-loader with Next.js configuration. To make babel do most of the transpiling for us we need to notify typescript about our intentions. To do it we’ll create tsconfig.json (if you weren’t previously). Minimal one will look like this.
And that’s it, it should work! But right now our configuration are no better in terms of speed than the next-typescript. We start from babel integration. To do it we need to enable useBabel option in awesome-typescript-loader configuration and pass Next.js default babel config to babelOptions. The catch here is that Next.js default babel config contains cacheDirectory option which is inapplicable in context of babel integration because cache is common, so we need to omit it. I wrote small and simple omit helper right here, but you’re free to use any methods you want: lodash, ramda, object destructing etc.
Notice that we deleted defaultLoaders.babel. The next step we want to take is to enable cache.
And the last one is to use CheckerPlugin to run typecheck in a separate process to speed up compilation time even further.
So we wrote a quite compilation-performant Next.js typescript configuration. Of course, writing webpack configuration manually can be cumbersome, but fear not, I wrote a next-awesome-typescript plugin which does all of this and even more! Feel free to place a star, raise an issue, leave the comment and subscribe t̶o̶ ̶m̶o̶r̶e̶ ̶w̶e̶e̶k̶l̶y̶ ̶s̶c̶i̶e̶n̶c̶e̶ ̶v̶i̶d̶e̶o̶s , sorry, to my Medium :)
