Ask A Question


You’re not receiving notifications from this thread.

Runaway Memory Leak/Usage with esbuild reload

Craig Kaminsky asked in Gems / Libraries

After watching this episode - - we implemented the live reload functionality across several of our apps. Overwhelming it's amazing!

However, our primary app (ye ole Monolith) goes bonkers! If you run bin/dev with yarn build --reload, rebuild immediately eats up 13-24GB of RAM!

The monolith is on Rails 7.0.2 and I stripped down the package.json to almost nothing (so that the libraries used matched another app that does not exhibit this issue) but got the same results.

I'll be trying the same with Gems but wanted to post a question here in the event that someone maybe had a similar issue and/or found a solution (i.e., found a culprit who was causing the "leak").



For anyone coming along ... it's not Gems but it does appear that Stimulus Controllers, Chart.js and CKEditor give it fits when they're included in the application.js entry point.

If I comment those out, esbuild will run around 1.5-2GB and not lock up the CPU.


Final note in case someone comes across it: after a day of researching and playing, the runaway memory issue with esbuild was twofold: (1) an older version of Chart.js (3.5.x) and once updated (to 3.7.x), I could load that library in application.js and (2) CKEditor 5 doesn't really play so nicely with esbuild (they even note that v5 is specifically built for/with webpack5) - and we had old versions of it downloaded (d'oh) and a double import of it in application.js (d'oh-d'oh).

Long story short, if you have any weirdness with esbuild using GBs of RAM when using the --reload argument, check for old JS libraries like Chart.js and watch out for your version CKE5!

Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 82,969+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.