Craig Kaminsky

Seconding (thirding?) what Eric and Sharon wrote. I really like these sort of quick-hitters. I've known and, on occasion, used ensure before but seeing this, I realize there are several places in our apps at work that I can use/should have used ensure more.

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!

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.

After watching this episode - https://gorails.com/episodes/live-reload-esbuild-rails - 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").

Thanks!