Theme Build System

A Shopify theme ships hand-written JavaScript in the asset folder. There is no module system, no type checking and no bundler — which is survivable on one small theme and becomes the dominant cost across a dozen large ones. The same carousel is reimplemented four times, a rename breaks a template nobody opened, and every page downloads every script.

The constraint is that none of the fixes can change how a theme deploys. Shopify expects specific files in specific folders, and the CLI has to keep working.

Each section gets its own entry point, compiled to its own bundle. Anything imported by two or more entries is automatically extracted into a shared chunk instead of being duplicated. The output lands exactly where Shopify expects it, so deployment is unchanged and the theme remains a normal theme.

Babel does the transpiling and type checking runs in parallel as a separate process — TypeScript never emits. That keeps the watch rebuild fast while still failing the build on a type error, which is the combination that makes strict mode tolerable on a large theme rather than something the team turns off.

Rolling this across existing themes was the harder part, and it is mostly not a technical problem. A build step that a teammate does not understand is a build step that gets bypassed at the first deadline, and a bypassed build step is worse than none because now the repository has two conventions.

So it shipped incrementally, one theme at a time, alongside the onboarding and pairing that is a large part of my current role — and the measure of whether it worked is not the bundle sizes, it is that engineers who did not write it reach for it by default.