Our engineers came to the conclusion that outsourcing build improvements was the optimal path forward. Outsourcing build improvements requires relatively little ramp-up compared with outsourcing feature work. Further, they found that the folks who were available had qualifications beyond reproach. These consultants were core contributors to and owners of the build libraries we use. After speaking with a number of consultants we hired Tobias Koppers (webpack's founder) and John Reilly (ts-loader's primary contributor / tech lead). Hard to beat, right?
Even if the average build time was 45 seconds, that's definitely long enough where you'll stop whatever you're working on, switch over to Hacker News or Reddit or get up to refill your coffee.
Now, the amount of time wasted on disrupting an individual's workflow is difficult to quantify. But if you've got 40-50 engineers, like we do here at ExtraHop, that time spent waiting on builds starts to add up.And how many builds does ExtraHop do on a given day?
AB: A typical engineer rebuilds his/her code at least 50 times a day, sometimes even hundreds. In the past, when we had 10 or so engineers, that length of time didn't make as big of a dent in terms of engineering resources. But now that we have 40 or 50 engineers on staff, it's five times worse. So the value in trying to optimize for efficiency was really obvious. The overarching goal was to accelerate build times so that we didn't get sidetracked by something else. It's hard to quantify how much of a difference that makes, but in terms of engineering resources, if you can reduce a 34-second build time to 13 seconds, that shaves off 21 seconds. You multiply 21 seconds by the number of engineers, that's a lot of time had been spent each day waiting around.But then you factor in the amount of time spent getting back into your "flow state"…
It's much longer, because if you get sidetracked, you say "well, while this is building I'm going to look at my email." So your flow is totally disrupted and it takes even longer to get back into work mode. So we're talking about a number of minutes per interruption, really, not just seconds.How did webpack's founder and ts-loader's primary contributor come on board?
To me, this seemed like the obvious approach—what better way to speed up our builds than by reaching out to the contributors of these core communities that exist out there. These folks know more than we do about this technology. Better yet, we didn't have to spend time ramping them up on ExtraHop and our code because all they would be dealing with is the build. So there was very little friction.
Now, there's another project out there called HappyPack, which makes webpack builds faster by allowing you to transform multiple files in parallel. It splits up the compilations across various different processes, which consequently speeds up your builds. I was aware of someone raising a PR for ts-loader which added support for that. So, if I took HappyPack and fork-ts-webpack-checker-plugin—one of which allows you to split up ts-loader builds across multiple processes and the other which says "I can handle catching and reporting the errors"—I though that might be the answer for speeding up the builds. And it turned out to be very successful. Tobias was then able to take the principles which underpin HappyPack and create a further optimized approach in the form of thread-loader with cache-loader.
And the results so far…?
Check out John Reilly's article "TypeScript + webpack: Super Pursuit Mode" on Medium.
If you're interested in joining an award-winning team committed to doing awesome stuff like this, check out our Careers page.
This is a companion discussion topic for the original entry at https://www.extrahop.com/company/blog/2017/extrahop-webpack-accelerating-build-times/