Build Time Mitigation on Larger Applications

[Brocktho]

Overview:

1. Purpose
2. Tree Shaking
3. Node Internals
4. EsBuild Bundle

Purpose

As Remix has gotten a larger following and adoption it's started to get some larger projects and with larger projects come longer build times. I've personally seen many people have issues with their build times on the Remix discord and there doesn't seem to be one central point of information to find good ways to help reduce your build times.

That's hopefully where this post (and possibly, a PR to add to the docs) comes in. Further discussion and additions are encouraged but here are a few examples of what I've seen as common suggestions and my own discoveries for easy build time wins.

Tree Shaking Large Libraries

Large libraries like (Material UI)[https://mui.com/] have a very large number of components and as such can easily make your bundle size explode. Material themselves have a good page on (documentation)[https://mui.com/material-ui/guides/minimizing-bundle-size/] for minimizing your bundle size and should definitely be read through if you use the package yourself.

Often times large libraries do have documentation for how to best tree shake them, so always check your library of choice to see what they provide so you can better minimize your bundle. Other libraries that are fairly large and I've run into personally are:

FontAwesome Icons,
Apache Echarts
Chartjs

Node Internals

Since Remix is a full stack application, you may want to leverage certain node modules, things like fs, or crypto. More often than not you really only want to use these modules in your server, but it's not always obvious to the compiler that you don't want to include it to the browser. The Remix team thought of this and added the .server file extension to ensure your code stays where you want it to stay. Personally I found the easiest and most reliable way to work with certain node modules I was interested in, was to declare a Node.server.ts file and export all my server only modules from that location. I mainly use this for node internals specifically "node:fs", "node:crypto" etc. But you could happily include other core modules in there.

When I made that simple change to my application, (and find + replaced all other imports for fs and crypto ) I was able to shave off about 3MB from my client bundle, which decreased my build times about 3s.

Example Node.server.ts:

import fs from "node:fs";
import crypto from "node:crypto";

export { fs, crypto };

EsBuild Bundle

Starting with Remix 1.19 you can now easily view your bundle! When you have your bundle you can go to (the Esbuild Bundle Analyzer)[https://esbuild.github.io/analyze/] and plop in your client and server bundles. It can be really great at helping you understand the largest parts of your application and see what's causing slower build times. For me personally I noticed that node:crypto and node:fs polyfills were being included to my browser even though I never directly called them in the browser.

If you're experiencing any dissatisfaction with your build times and you can, update your Remix application to 1.19 and take a look at your bundle, you may be surprised to find a couple of easy wins to shave off a lot of extra work from your build.

[runofthemill]

@Brocktho have you been able to figure out treeshaking with named imports in Remix for Material UI? The default/path import approach works, but is less dev-friendly than named imports. But since there's no exposed configuration for esbuild, I don't know if it's even possible 🤔