This started as a run of videos I recorded between 2021 and 2022, messing about with the way I compiled CSS and JavaScript on Magento 2 themes. I've pulled them together here because the story they tell is a useful one, and because the asset pipeline is one of the quiet reasons I eventually walked away from the platform. The versions are dated, so read this as the shape of the journey rather than a step by step for today.

The thing Magento never made easy

Out of the box, Magento 2 expects you to edit LESS, run a static content deploy, flush a couple of caches, and reload. On a real project, with developer mode on, that loop is slow enough to break your concentration every single time you nudge a margin. The platform's own answer was Grunt, wired up with a config you copied out of the docs. It worked, in the sense that it ran, but it always felt bolted on, and the LESS setup never matched how I actually wanted to write styles.

So like a lot of Magento developers around that time, I went looking for something better. What followed was a few years of swapping one build tool for another, each time fixing the annoyance the last one left behind.

Grunt to Gulp

The first move was Gulp with Sass and Livereload. The win was speed and feedback. Sass over LESS meant I was writing in the syntax I used everywhere else, and Livereload meant a save in my editor refreshed the browser without me touching it. For day to day theme work that was a genuine jump. I could sit in a Sass file, tweak, and see the change land in well under a second.

It wasn't free though. You were now maintaining a Gulp setup that sat alongside Magento's own asset handling rather than replacing it, and when Gulp 4 landed it broke the older gulpfiles, so there was an afternoon of fixing the pipeline just to get back to where you were. That pattern, where the tooling needs its own maintenance, is worth remembering. It comes back.

Webpack, and asking too many questions

Next was Webpack mix to extend the Luma theme. The pull here was bundling and a more modern JavaScript story, and the ability to work on multiple themes independently. I got it running inside a theme, then started asking whether I could push it further: compile CSS for modules as well as the theme, support multiple sites, copy the compiled files into the right static folders automatically.

The answer was yes, but only by moving the build to the root of the project and writing an array describing every module and theme I wanted it to handle. That is the moment a build tool stops being a convenience and starts being a small application you own. I'll be honest about my own opinion here: I don't usually put a module's CSS inside the module. The way a module looks on the front end is almost always a job for the theme, so most of the time I keep the styling there. The Webpack setup could do the clever multi-module thing, but for most sites it was solving a problem I'd chosen not to have.

Laravel Mix, and the workflow I settled on

The last stop was Laravel Mix, which is a friendly wrapper over Webpack. By this point I cared less about bundling tricks and more about the daily workflow. Mix gave me a clean way to compile Sass, watch for changes, and trigger a reload, with far less config noise than raw Webpack.

The part I actually liked was tying my Magento commands into the build using Node's child process. Instead of typing bin/magento setup:static-content:deploy and then a cache flush by hand, I wrapped them as yarn scripts scoped to whichever instance I was working in. Type a short command, it deploys the static content and flushes the cache for that project. A full static deploy still took a handful of seconds, which is fine when it's running in the background while you tap away at CSS. Small thing, but multiplied across every day it adds up.

What the whole journey was really telling me

Look at that list. Grunt, then Gulp, then Webpack, then Laravel Mix, plus a Gulp 4 migration in the middle. Four build tools to do one job: turn my source styles into something the browser can read, quickly, while I work. Every step was a sensible fix for a real annoyance. But the annoyance kept existing because the platform's own front end was heavy, opinionated, and not built around a modern asset workflow. I was spending real time maintaining the thing that was supposed to save me time.

That is the bit that stuck with me. When you find yourself swapping out your build tooling every year to keep a platform's front end bearable, the tooling isn't the problem. The front end is. A modern stack, where the build step is a first class part of the framework rather than something you graft on, makes most of this disappear. That realisation is part of why I moved from Magento to headless, where the front end and its build are the same thing from day one, and I stopped reaching for a new tool every season.

If you're still on Magento, Laravel Mix with a few yarn shortcuts is a comfortable place to land, and far nicer than where this started. Just keep an honest eye on how much of your week goes into the pipeline rather than the work.