For a good year and through a million versions of angular/typescript I've always had the angular language service eventually crash (or hang for 10+ minutes) from any number of bugs. This always requires me to restart VS code (which means killing my angular host and server debug too) which is a huge hassle. Lately I've been having crashes more often which is really making this annoying.
As a work-around for now and the future, can we have an option to restart the language service without restarting VSCode? I work with the .Net Core library and use VSCode for that too and it has a very similar service to this called OmniSharp which also likes to poop the bed at random intervals, however it has this amazing feature:

That would be a huge help. Thanks!
+1
fundamental
+1
Would also appreciate this feature. When my intra-project dependencies undergo a sufficient number of changes/rebuilds the language service seems to forget about them. I suspect a quick restart of the language service would be enough to get it going again.
This may be related to issue #224 as I often have to run ng build <module> several times in succession to get past the EPERM: operation not permitted, unlink... issue, and I wonder if the language service thinks those files are gone for good.
This seems like it should be trivial to add. Right now I have to restart VSCode which is incredibly annoying.
Thanks for the suggestion, this sounds like a useful feature. We'll prioritize it in the upcoming rework of the language service.
Adding a "restart" feature is useful on its own, but it is not solving this particular problem at the root. With the new rewrite of the language service, hopefully this won't be necessary anymore.
Thanks @kyliau! I mean ideally you'd never have to restart any piece of software, but...

I still think it could be a useful feature for any future issues that crop up. For example, OmniSharp can get confused by renaming folders or files too fast. Then it ends up with some cached copy of the file in memory and tries to parse this brand new version and complains that a class with that name already exists in that namespace and suddenly your entire screen is angry red squiggles. A couple key-presses and the service restarts and I'm back up and running.
There's always going to be some weird corner case no one thought of that will cause the service to act up, or hang. Even if you have some built in hang-detection that reboots itself, it's always nice for us impatient people to have a button to hammer.
Yes, you're right. I should clarify that adding the "restart" feature is absolutely the right thing to do, and we will do it. But we should not bank on users restarting the extension in order to keep it working. If we design the extension to work properly in the first place, hopefully such restart is only needed under rare circumstances.
Perfect. I thought you meant you weren't planning on adding this because the new version was so good 馃槃. But yeah, ideally we all forget this feature is there because we don't use it for months.
馃憤
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
Thanks for the suggestion, this sounds like a useful feature. We'll prioritize it in the upcoming rework of the language service.