Let’s Build a Thing! (Part One)

Chris Shepherd
4 min readJun 22, 2019

My current run-rate for blogging is not fantastic. I have extremely good intentions, but I invariably either:

  • Stop doing “worky” things outside of the working week so that I can give my poor brain a rest. This I’m able to do with reasonable success of late, having learned how not to cope with burnout!
  • Get super caught-up in preparation for singing conventions/shows with my barbershop chorus (shameless plug but I don’t even care.)
  • Get super caught up in learning a bit of tech to satisfy my own curiosity, or to help me out with future client engagements.

So I thought I’d try to use this last reason as an opportunity to write something cool, and also try to blog my progress, too! So let’s get down to it. Let’s build…

A FRONT-END FRAMEWORK

Because let’s face it, there aren’t enough of them..

Given that there are already thousands of fully-mature frameworks out there that allow you to build beautiful, dynamic single page applications, and that they generally have great community support, tooling and developer satisfaction; why build another one?

Put simply — because I wanna. I’m not satisfied with the mysterious voodoo that happens behind the scenes when you render a React app. I’m deeply interested in how the observability of a data component might cause only a partial re-rendering of a DOM. I’m keen as a very keen thing to evolve a performant web rendering framework from the ground up, and learn heaps about TypeScript, virtual and shadow DOMs and Web Component architecture. But above all I just want to.

I’m a software engineer not because I’m chasing money or because I’m climbing the rungs of some career ladder — I’m a software engineer because I love to build shit 😉

So over the next X amount of days, weeks, months, years/til whenever I get bored; I am going to build.

First things first

I am a bloody great big Kanban-enthusiast, and like the majority of my engineer friends I love nothing better than listing the ever-loving shit out of my life. So first things first, let’s go and do a Trello thing:

This is quite nice because it seriously helps to order my thoughts. Moving stories/tickets/stickies across a board is comparable to the lovely little dopamine hit that you get from playing the slots in Vegas, or from seeing someone 👍 your post on Facebook.

Agile is a gateway drug. Discuss!!

Anyways, I digress. What features should I build, then? Well for a start there are a few teeny tech tasks to work on so that I can get my pen going:

First of all I want to configure Jest (my testing framework of choice!) to play nicely with TypeScript. Next I’m going to want Webpack to transpile whatever stuff I’m coding into JavaScript. I estimate this is going to take just a couple of hours of clicking around so let’s start with that right away!

Configuring the development environment

Rather than spending aaaaages describing how I got to this state, I’ve created a gist which contains each of the configuration files that I rolled to support TypeScript transpilation to native JavaScript, and the options for Jest to be able to understand TypeScript at runtime:

.jest.config.js

This file details some of the options that are needed to support files with the .ts extension. Note, too that we’re specifying the root folder for Jest to find any test files to run.

package.json

This snippet just lists the dev dependencies needed for NPM to be able to physically run my new NPM module.

tsconfig.json

The presence of a tsconfig.json file in a directory indicates that the directory is the root of a TypeScript project. This is going to be called under-the-hood by webpack, and contains a few compiler hints to improve our development experience (basically just a few imports to support ES16/17).

webpack.config.js

Finally this webpack configuration file outlines how our transpilation happens, and what the output of the build is gonna be, where it’s going to live etc. Crucially it says it’s going to use the ts-loader plugin to transpile the TypeScript into JavaScript. With all the above in place, we can go ahead and write a super-simple failing test!!

Proof!!

Look, I’m really tired now. But this is all awesome — We’ve been able to build a simple walking skelington that’s all wired up properly and we can start writing some tests to build our our functionality!

If you’d like to follow-along with this series of blog posts, there’s a repo you can take a look at over here!

Super.

Originally published at https://blog.thesheps.dev on June 22, 2019.

--

--

Chris Shepherd

Thoughtworks.com dev, barbershopper, homebrewer and human (not necessarily in that order).