Long short of it is I’m using vs code and if I enable the eslint plugin (“even if only running at save”) I get major system-wide hangs while at the same time running phx.server
From the looks of it, it would almost seem as if vs code is causing live reload to freakout and trigger a bunch of webpack rebuilds at once. At the same time, eslint just hangs, vs code says it’s trying to save the file and my whole system poops the bed.
Thoughts, advice?
So far I can observe that:
- if I disable eslint in vs code, live reload and webpack bundles just fine
- if I stop the
phx.server from running while using the elint plugin in vs code eslint works just fine.
- If I use
phx.server and eslint at the same time. 
It might be the number of file watches happening. VS Code git integration uses a lot of them, the lint file watch will also use a lot of them, we pack rebuild will use some and then Phoenix reload will use quite a few as well. I’ve recently had quite a few problems with this (outside the elixir context) with larger repos in VS Code especially on Linux VMs when using plugins like eslint alongside webpack, disabling the git integration helps a fair bit for me at least. I tried throwing more CPU and RAM at the VMs on the off chance but there was no perceived difference between 8GB 4 cores vs 24GB 8 cores allocations combined with improved performance when disabling things that watch files is what makes me think the file watching can become an issue with some of these tools.
1 Like
Totally fair to say that it’s not the fault of anyone tool individually. I do try to consider how two or more tools interact with each other and I’m guessing at the moment I’ve found issues that raise from the order of procedure in which maybe these tools interact impacting performance.
Another idea was possibly they all race to use the same dependencies and the bottleneck is that shared recourse or maybe redundant use of resources exhausting memory because. As I’m literally typing this out I’m starting to ask myself what is the proper way to debug this. I’m guessing I should confirm the uses of resources. I was trying to figure that out with the activity monitor on osx but even that was crashing.
Edit: Also I did try disabling the few git libs I had lens included and it didn’t seem to make much of a diff in my case. The main offenders I could see were live reload, webpack, and eslint running in vs code. Outside of that, not much else seemed to make the diff. I should also add I’m running there all natively, the only docker sync stuff that could behave would be at the db layer as I did have Postgres running via docker so I’m not so convinced it would be due to a lack of system resources in that context, that said I’m on a 16gig MacBook pro 3.1 GHz Dual-Core Intel Core i5. I didn’t’ see any CPU spikes but it was harder to decern the memory use on account of activity monitor crashing
Is there any possibility that your ESLint is misconfigured and is picking up your webpack output files? It is also worthwhile making sure it isn’t going through your node modules either.
2 Likes
thanks for the tip, I’m gonna give that a try.
1 Like
now correct me if I’m wrong shouldn’t eslint respect my .gitignore?
I’m not an expert on ESLint by any means but from my limited understanding it does not, there has been discussion on the topic in the past and as far as I am aware it does not use gitignore in the absence of a .eslintignore but it is entirely possible that I’m behind on that as I’ve been riding on configs other people built a lot of the time lately and prior to that I mainly used TS and TSLint before TSLint started phasing out.
Edit: if you configured it to then it should, but I don’t believe it should by default
Oh man what a relief, I guess thats what I get for taking for granted plugins that respect my .gitignore
It looks like it was dipping into the node_modules folder after all.
2 Likes
Glad you got it sorted out 
