Poor performance with mid-size monorepo Follow
I am long time user of WebStorm and love it so much.
At the current company we're progressively moving to mono-repo which makes is great in terms of team development, but for some reasons, WebStorm is really slow for me in this project.
What I mean by slow?
e.g. double-shift brings results in seconds after typing, while normally they come up immediately in different projects. I use double-shift all the time, so it makes my really tired by its lack of responsiveness.
It is NX + TypeScript + ESLint project.
I am wondering what can be done to improve it?
One thing I've noticed is that it often indexes some dist folders which are hard to exclude as they are often somewhere deep etc (why WebStorm exclusions cannot use similar format to gitignore so could autoignore every dist?)
Please sign in to leave a comment.
distto Ignore files and folders list in Settings | Editor | File Types - does it make things any better?
Unfortunately it does not help at all, even more (as mentioned in the YT ticket) it was breaking some autocompletion.
Any other suggestions for fixes the crazy bad performance?
I tried to invalidate caches, reinstall node modules etc but nothing help.
Did you try marking all build target folders 'excluded' manually, with Mark directory as right-click menu action?
Hi, yes. It does not help at all. Double-shift provides suggestions few seconds after typing.
It hurts DX so much.
Anything you can do to help?
If it matters, we use pnpm to install dependencies.
please try taking CPU snapshots (https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems) when it runs slow and submit them along with the logs (Help | Collect Logs and Diagnostic Data) within a youtrack ticket
In case you need a guide: https://medium.com/@devnullnor/typescript-in-a-webstorm-monorepo-391b898ed60b
Our company recently moved to a Monorepo using NX (also about mid-size) and Webstorm is tremendously slow. Our entire team had to switch to another editor.
Code completion was extremely slow, to the point of being unusable.
I've tried the following:
- Increasing WebStorm memory allocation
- Invalidating Caches and restarting
- Adding all dist and tmp folders to ignore
- Turning off all extra plugins
- Disabling Github Co-pilot
Unfortunately none of the above seemed to help.
For reference the machine i use:
2022 MacBook Pro 14"
16 GB memory
please try taking CPU snapshots when it runs slow
1) Help > Diagnostic tools > Start CPU usage profiling
2) perform the actions which are causing high CPU usage, try to reproduce the performance problem several times while the snapshot
3) Help > Diagnostic tools > Stop CPU usage profiling
and submit them along with the logs (Help | Collect Logs and Diagnostic Data) within a youtrack ticket
Maybe you guys from Jetbrains can try yourself. My whole team experiences this and actually the whole company I bet. We pay you money for an IDE. I expect a pro-active approach for making sure everything works normally, not automated robo-replies. Monorepo's are the future. If you don't fix this you're going to loose your customers to VSCode.
Okay! Nevermind... it started happening again after about 20mins. :(
Edited the text to be more clear.
Update from my side:
I disabled all Inlay Hints and ML Code assitance
This did improve the experience, but as edit 1 mentions, it become slow after a short time. Also, as Paalthingbo pointed out, this is not ideal and defeats the point of paying for a IDE over a text editor.
@Dewaldifels That's bad advice. Those are some of the reasons for using an IDE in the first place.
Appreciate the feedback, but it wasn't advice. Just letting you know what I'm trying :)
I and a couple of engineers I work with, recently faced the same issue. We use NX as well, and NX mental model https://nx.dev/more-concepts/applications-and-libraries#mental-model suggests that:
So we have many small libs, with own tsconfig files, etc. WebStorm is 'red' 90% of time not being able to analyze ts references, etc.. Probably WebStorm team can use this as an example: https://github.com/nrwl/nx-examples.
It's not an option to open every lib as own project, because it's not align with an idea of what we are trying to achieve with NX.
Sadly, I'm catching myself to use VSCode more and more and it's slowly becomes a way to go, for at least a monorepo project I'm working on.
Alex Di You seem to be doing it wrong. If you read in your own link: "Note, these libraries don’t necessarily need to be built separately, but are rather consumed and built by the application itself directly. Hence, nothing changes from a pure deployment point of view."
Libraries you build separately, should probably be treated as their own projects.
d Nothing in my message tells, that I build them separately. Those libraries that I'm doing are exactly what articles states - are not built on their own and just consumed by application. However - whole NX setup still connects all that together by separate tsconfig, eslint, test config files.
If you would like to check how it works - you can generate you repo and create a couple of libraries, please note you need to use` bundler: none`, to make library not buildable on their own (https://nx.dev/packages/react/generators/library#bundler).