<commit_before>---
layout:     post
title:      Manygolf and TypeScript (Part 1: Build Pipeline)
categories: manygolf
summary:    A summary of the long and arduous road to setting up a TypeScript + Babel + Webpack build system.
---

As I detailed in [my last post]({% post_url 2016-04-18-manygolf %}), I chose to build my newest project, [Manygolf](http://manygolf.disco.zone), using [TypeScript](http://www.typescriptlang.org/). TypeScript, if you're not familiar, is a superset of JavaScript that includes static typing, developed at Microsoft.

Typed JavaScript has always been interesting to me, especially for games. While I don't always find myself wanting types while doing "normal" web development projects, there are lots of reasons why I think games lend themselves to static typing:

- Developing games usually involves working with browser APIs such as [Canvas](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API) or the APIs of third-party libraries like [p2](https://github.com/schteppe/p2.js) that I don't have as well-memorized as libraries I use for every day development. Having type checking on function params and return values is very useful here. I don't have to worry about looking up whether, say, p2 stores positions as a two-point array or an object with `x` and `y` fields - my editor well yell at me if I get mixed up.
- Games are often hard to test due to the complexity of interacting systems. Obviously, type guarantees aren't a replacement for tests, but can at least help somewhat in making certain guarantees in untested logic.
- Games often contain a lot of state in a lot of places that is hard to keep track of, and having type guarantees means I won't forget where and how I've stored state.

In the past, I've used Facebook's TypeScript alternative, [Flow](http://flowtype.org/), to help me build games with [Coquette](http://coquette.maryrosecook.com/). Both [Monotron](https://discozone.itch.io/monotron) and my platformer prototype [Blorp](http://disco.zone/blorp/) were built with Flow. I found Flow easy to integrate into an existing build pipeline - the "compiler" is simply a Babel transform - and it was very useful in a "closed system" where I wasn't worrying too much about external libraries. I didn't have to worry about the lack of useful third-party Flow type definitions, since I wasn't using any libraries beyond Coquette, which was rather easy to write my own definitions for (or simply not annotate).

However, for Manygolf, I wanted to use many libraries that had TypeScript definitions but not Flow definitions, including p2 and [Immutable.js](https://facebook.github.io/immutable-js/) (which, to be fair, has recently added Flow support). TypeScript has a huge community repository of Immutable type definitions, and some libraries, including Immutable and p2, even maintain type definitions officially.

Thus, it seemed like TypeScript would be a solid option. I was rather disappointed, however, to find that TypeScript was pretty difficult to set up in an existing build pipeline. I thought I'd document how I added TypeScript to Manygolf, a universal JS app with both a server and client.

## Adding TypeScript to a Babel+Webpack Setup

Before I introduced TypeScript to Manygolf, I was already using Webpack and Babel to build. On the server, I was being lazy and just using the babel-runtime transform to compile the server code when I ran, which ended up being an issue later. On the client, a Webpack watcher compiled the app using a pretty standard config:

```js
var createVendorChunk = require('webpack-create-vendor-chunk');
<commit_msg>Fix parsing error in post frontmatter<commit_after>---
layout:     post
title:      "Manygolf and TypeScript (Part 1: Build Pipeline)"
categories: manygolf
summary:    "A summary of the long and arduous road to setting up a TypeScript + Babel + Webpack build system."
---

As I detailed in [my last post]({% post_url 2016-04-18-manygolf %}), I chose to build my newest project, [Manygolf](http://manygolf.disco.zone), using [TypeScript](http://www.typescriptlang.org/). TypeScript, if you're not familiar, is a superset of JavaScript that includes static typing, developed at Microsoft.

Typed JavaScript has always been interesting to me, especially for games. While I don't always find myself wanting types while doing "normal" web development projects, there are lots of reasons why I think games lend themselves to static typing:

- Developing games usually involves working with browser APIs such as [Canvas](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API) or the APIs of third-party libraries like [p2](https://github.com/schteppe/p2.js) that I don't have as well-memorized as libraries I use for every day development. Having type checking on function params and return values is very useful here. I don't have to worry about looking up whether, say, p2 stores positions as a two-point array or an object with `x` and `y` fields - my editor well yell at me if I get mixed up.
- Games are often hard to test due to the complexity of interacting systems. Obviously, type guarantees aren't a replacement for tests, but can at least help somewhat in making certain guarantees in untested logic.
- Games often contain a lot of state in a lot of places that is hard to keep track of, and having type guarantees means I won't forget where and how I've stored state.

In the past, I've used Facebook's TypeScript alternative, [Flow](http://flowtype.org/), to help me build games with [Coquette](http://coquette.maryrosecook.com/). Both [Monotron](https://discozone.itch.io/monotron) and my platformer prototype [Blorp](http://disco.zone/blorp/) were built with Flow. I found Flow easy to integrate into an existing build pipeline - the "compiler" is simply a Babel transform - and it was very useful in a "closed system" where I wasn't worrying too much about external libraries. I didn't have to worry about the lack of useful third-party Flow type definitions, since I wasn't using any libraries beyond Coquette, which was rather easy to write my own definitions for (or simply not annotate).

However, for Manygolf, I wanted to use many libraries that had TypeScript definitions but not Flow definitions, including p2 and [Immutable.js](https://facebook.github.io/immutable-js/) (which, to be fair, has recently added Flow support). TypeScript has a huge community repository of Immutable type definitions, and some libraries, including Immutable and p2, even maintain type definitions officially.

Thus, it seemed like TypeScript would be a solid option. I was rather disappointed, however, to find that TypeScript was pretty difficult to set up in an existing build pipeline. I thought I'd document how I added TypeScript to Manygolf, a universal JS app with both a server and client.

## Adding TypeScript to a Babel+Webpack Setup

Before I introduced TypeScript to Manygolf, I was already using Webpack and Babel to build. On the server, I was being lazy and just using the babel-runtime transform to compile the server code when I ran, which ended up being an issue later. On the client, a Webpack watcher compiled the app using a pretty standard config:

```js
var createVendorChunk = require('webpack-create-vendor-chunk');

{'fraction_non_alphanumeric': 0.06552863436123348, 'fraction_numerical': 0.003854625550660793, 'mean_word_length': 4.5458015267175576, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 8, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2479639', 'n_tokens_mistral': 1865, 'n_tokens_neox': 1794, 'n_words': 1051}