command to restart server or plugins without quitting vscode #164
Comments
kentor
changed the title
dbaeumer
added
feature-request
|
@kentor this is currently not possible. PR welcome. All that needs to be done is to add a command and then in the extension code call client.stop() and client.start(). |
|
seems like client.stop() is async, and client.start() will throw if it's already started |
|
Good catch. Will add a promise to stop. |
|
Added promise in latest. |
|
Hi @dbaeumer, is this feature still in progress/needing help? |
|
@robbawebba yes, a PR is still welcome. |
|
I notice this is a bit of a rough spot in VS Code. My partner and I have been using VS Code for a year, and we notice that a couple times a week, ES Lint hemmhorages and starts underlining stuff incorrectly. It usually happens when you have been using VS Code for a long time and/or have lots of open editors. I also notice that it seems to exacerbate the issue if you are making lots of small changes very quickly. Sometimes, all red underlines just go away and VS Code slows down. Restarting always fixes it though. I found my way into this thread because the way I fix the issue is to close VS Code and re-open it. It's kind of annoying and disruptive. I was trying to find a way to restart ES Lint or all extensions without restarting VS Code. Here is a screenshot @dbaeumer
I apologize for not being able to provide steps to reproduce, but I am and have been looking for a way. The best I can do is what I described:
I bet you will see something weird in the RAM or some async event fall on its face. It seems to do it the worst in large React projects as you rifle through lots of JSX. |
|
@agm1984 thanks for providing this. One tip: you can always restart ESLint by reloading the Window. You don't need to close and reopen VS Code. |
|
Yes, I observed the same yesterday. I was seeing some weird ES Lint behaviour and closing the tab changed the errors that were outputting but it was still in an error state. I pasted in a bunch of old HTML markup into a React component and that blew up ESLint instantly. I had to close VS Code and reopen it to fix it. VS Code seemed to really hate that the HTML markup didn't have proper self-closing tags in it and maybe 200 LOC. It made a big mess of the indentation of the code as well. If I was looking to reproduce, I would put an incongruent number of opening + closing tags in a giant block of code and see what happens. If I had to guess, I think it might be related to pasting. When I previously described "rifling through lots of files", I am usually pasting big chunks of code when I am doing that. Something hemorrhages occasionally. Closing the editor tab does cause an observable difference, however. My milage seems to vary with it. |
|
Actually closing and reopening the tab should clear the errors and re-compute them. If in this scenario the errors are still wrongly computed can you do the following:
and append the trace here. |
|
[GOOD DEBUG INFO ENCLOSED] Dang, I'm sorry Dirk. I had the most perfect reproduction last night of some ES Lint errors. I always roll with eslint tracing on verbose 24/7. I changed it to messages and back to verbose, but I wasn't able to see where the traces go. I was looking in the integrated terminal and none of the tabs had any info. The Problems Tab was showing the ES Lint errors, but no 'trace' kind of information. I Googled it and tried to find how or where to see server traces. I mostly found you recommending these steps to people. If you wouldn't mind giving me exact instructions, I will get you some all-star debug data. I have been heavily modifying a React app over the past few days and again, I can tell you it melts down wholesale when:
The more ES Lint errors there are and the faster you save files, the more often it melts down. Sometimes I close the tab and reopen it and it has incorrect errors still displaying. For example, last night, that one I was trying to get trace for was 2 unused vars that I removed but the ES Lint error persisted, and the red squiggly lines were in the wrong spot. They didn't go away when I closed the tab and reopened it.
Here is an example of what we see. When this output gets super size, you get problems: It's create-react-app, so it may have some kind of fascinating inter-dependency with Webpack. Sorry for verbose, |
|
@agm1984 thanks for getting back to me. The log appears in the ESLint Output channel. Go Vies > Output and then select ESLint from the drop down in the Output pane. As a side note: running in verbose tracing produces a lot of output and will very likely slow down your machine as well. Most of the time it is enough to run in |
|
Awesome thanks. Ok, I will update with new data when I can reproduce. |
|
Hey @dbaeumer, looks like my ESLint stopped working and took out some other extension that highlights colours in code (for highlighting CSS hexcodes, etc). I'm looking at the trace and I see: Everything looks fine above that. That error, the text in the tracing at various points in time, and my symptoms at this exact moment look very good in terms of uncovering a bug I see all the time that is impossible to reproduce. That last timestamp in there 7:34 PM was like an hour ago, so it's empty since then... no traces coming through. Must be because ES Lint pooped itself. I closed all the windows/tabs and no change in the trace window. She's pooched. I hope this is useful for you :) For posterity, there are no other errors of any kind in the trace messages window in the past 24 hours. I think I actually captured something, woot woot. -Adam |
|
Thanks for the trace. However it is very hard to say why ESLint stopped. The problem doesn't seem to be on the server side since the client seems to stop sending which on the server side triggers the problem computation. When this happens do you see high CPU load on your system. If so which process shows high load. And do other extensions still work ? For CPU load and other things you can execute code --status in a terminal. This should print some statistics about VS Code's processes. |
|
Hello again, my ES Lint is going haywire again today. It got tripped up on something, like I pasted in some code or otherwise typed in some terrible syntax while reasoning about a lambda function in a React render method, and it started throwing all kinds of non-existent errors. Closing the file did not help. In fact, there is an error in here and it isn't dismissing it. The error just moves around the file and reports all kinds of random errors that aren't legitimate, btu the fact remains that it always reports at least one error and there are no errors in the code. Here is my current tracing: NOTE: Scroll to the bottom and read up. I included lots, just in case earlier trends are important Here is a screenshot of what I currently see: If I comment out the code, the errors remain (pretty sure that's abnormal): If I delete the code, the error moves to another spot. If I keep coding, the error is attracted to random code like a magnet, and ES Lint will start throwing random errors in code with no errors: If I CTRL+Z the code back in, the error temporarily stays where it was after the code was deleted: Here is the tracing output after I just took those screenshots: NOTE: ie) chronologically after the previous tracing output NOTE: Most of the time, this incorrect error reporting starts with // if I start putting in a lambda or paste one in that has bad syntax,
// ES Lint can start to freak out.
someProp={() => { }}
// For example, today I did something like that but I started writing the if statement
// before I closed the inline function and that seemed to cause it to enter the bugged state.As soon as I do something and see |
|
Sorry for generating a second notification, should tag @dbaeumer |
|
Interestingly in the new trace there is no Without having steps on how to reproduce this it will be very hard to track down. @agm1984 is there anything you can distill? |
|
I absolutely notice high CPU. It's one of the reasons I know it is acting up. Sometimes I hear my fan turn on and pretty much stay on, and I always attribute it to VS Code starting to hemorrhage. I've been experiencing this issue for a few months. The problem is I've never found a way to reproduce it. I've been looking the whole time. I did QA for 5 years, so I know your pain. It's why I'm trying to give you as much detail as possible, so you can deduce it. Like I said before, it seems to occur most often while writing JSX and when I paste in code. I am generally always putting in DOM markup and JSX when ES Lint starts erroneously underlining things. Let me know what you think would be a good idea. I can set tracing to verbose if that will give better data. Our problem is we can't see the moment it starts failing. I do have a few JSX related extensions like auto-rename tags and now that I think of extensions, I remember that every time ES Lint dies, my colors stop highlighting. Sometimes I notice that before I notice CPU drain and ES Lint not working. This extension here: https://marketplace.visualstudio.com/items?itemName=naumovs.color-highlight The problem with reproducing it is there is no clear cut way. I experience it every 1-3 days. Honestly, the best way for me to trigger it is to open JSX and comment out like half the code and start pasting in chunks of malformed JSX. Over time, I notice activity like that contributes the most. |
|
@agm1984 thanks a lot for your willingness to help me track this down. The first thing we need to nail down is what causes the high CPU load. It could be the extension host as well. If it happens the next time and you hear your fan can you run |
|
@dbaeumer
`` bash
Collecting CPU and memory information. This might take a couple of seconds. Version: Code 1.21.1 (79b44aa704ce542d8ca4a3cc44cfca566e7720f1, 2018-03-14T14:46:47.128Z) adam@ADAMDEV C:\Users\adam |
|
Actually the CPU load of all processes is zero. |
|
Yes, after I closed all three VS Codes, there was a remaining VS Code process visible in the Task Manager, and it was maintaining 20% CPU load. |
|
Actually the CPU load of all processes is zero. |
|
Couple notes for @dbaeumer The other day I noticed WMI Provider Host was using a lot of CPU hovering around 20% CPU. I also noticed that I am running If you want to examine that further, "build-css": "node-sass-chokidar src/ -o src/",
"watch-css": "npm run build-css && node-sass-chokidar src/ -o src/ --watch --recursive",In terms of your environment, you should be using I mention this because sometimes I get a feeling that ES Lint is trying to read a file while it is locked. I might suggest taking a pass over related code and reason about weird use cases where a negative feedback loop is missing. If you can't do anything about that anomalous UX during the VS Code update process, I tried to word it such that you could just paste it to someone on that team. It was a UX anomaly, so they should know those sequence of events could happen to people at any moment. Otherwise, let me know and I'll create another issue about it. I bolded while watching in this reply because they are the two most important words in terms of contributing factors. EDIT |
|
Actually the ESLint server is only reading eslint configuration files from disk (e.g..eslintrc, .eslintignore, package.json). I never reads JS files or other files it is validating since the validation happens in memory. If you see problem with the VS Code installer I would like to ask you to file an issue against vscode itself here: https://github.com/Microsoft/vscode I still don't have a feeling why the ESLint server is stuck reporting errors as indicated in #164 (comment). What is very interesting is that computing code actions take a very long time. So it would be very help to know about the CPU usage when this happens. With the next update of VS Code you can even open a little windows (process explorere) that shows you the CPU and memory consumption of all VS Code owned processes. May that helps to see what is causing this. |
|
Update for you @dbaeumer. My VS Code was fine for weeks, and today I started working on some React Native stuff. Everything was all good, and then as soon as I activated ES Lint in this project, it piled in a ton of errors. It bogged down instantly and now its been super slow since. Almost all the errors are from:
I'm going to clear them all out before doing anything else and see if that does anything. I already did close VS Code and re-open it and it didn't have any affect. CPU seems fairly high, memory seems fine, disk usage seems fine. react-native kind of bombs out my machine resources to begin with, so I noticed it immediately when it started bogging down. It appears to be this bug we have been discussing. It started as soon as I got ES Lint working. I'll save the project now. You can download it from: https://github.com/agm1984/rn-clock-angle/tree/dirk I might recommend removing the ES Lint packages and then crank the heck out of your debug tooling and then install them all and see what happens when all the red underlines start. I'm really hoping this can get you some data. This seems to have made a big difference in available CPU. My computer isn't as bogged anymore. I didn't do anything but add these disablers: class Clock extends Component {
constructor(props) {
super(props)
const d = new Date()
this.state = {
sec: d.getSeconds() * 6, /* eslint-disable no-mixed-operators */
min: d.getMinutes() * 6 + (d.getSeconds() * 6) / 60,
hour: ((d.getHours() % 12) / 12) * 360 + 90 +
(d.getMinutes() * 6 + (d.getSeconds() * 6) / 60) / 12,
} /* eslint-enable no-mixed-operators */
}
componentDidMount() {
this.timer = setInterval(() => {
const d = new Date()
this.setState({ sec: d.getSeconds() * 6 }) /* eslint-disable no-mixed-operators */
this.setState({ min: d.getMinutes() * 6 + (d.getSeconds() * 6) / 60 })
this.setState({
hour: ((d.getHours() % 12) / 12) * 360 + 90 +
(d.getMinutes() * 6 + (d.getSeconds() * 6) / 60) / 12,
})
}, 1000) /* eslint-enable no-mixed-operators */
}Update: It still seems to be bogged down. I got it down to 0 errors now and its still lagged. I'm just going to reboot though. It's a bit too poop to handle. I will leave you with this for now. Let me know your findings so I can work alongside your latest ideas. |
|
Thanks for the test case. I was able to clone and see the ~100 errors however I can not reproduce the slow down. Typing is still normal and the CPU consumption on my machine peeks ~15% for the ESLint server process. The errors are updated in a second range. Is this what you observe as well? |
|
I haven't had any issues since. I'm running v1.23.1. I've also been maintaining about 3-5 VS Codes open at all times coding most hours of the day. I haven't noticed any significant bogs, so, well done team. I'll keep an eye out for any new conditions. I will try to submit them in a new ticket and tag you with steps to reproduce or very specific information. Thanks Dirk. I also noticed just now I have been polluting this thread about 'restarting without quitting'. I guess it is circumstantially related since performance issues can be impetus for restart-desire. |
|
@agm1984 good to hear that ESLint works fine right now. I will keep the issue open to not loose the initial feature request. |
dbaeumer
added
help wanted
|
Here's a Tweet here that is relevant to all my described issues in here: It makes me wonder. What if there was a function that ran when the number of open tab editors goes from 1 to 0. The function would re-init VS Code as if you restarted the program. That would stop people from having to close and re-open because they would get the same effect as closing all open tabs. What are your thoughts about an idea like that @dbaeumer ? There has been a bug in whatever area this is. It's been happening to me for 1-2 years as described in that Tweet by Sean Groff. The issue is when it happens, you can't fix ES Lint. The bug state cannot be reset without full close/reopen of VS Code. I assert that something needs to be available to the user to reset the application, preferably without them needing to know about it. For example even if ES Lint did a full reboot automatically every 30 minutes, that would solve it as well. The problem is I've never been able to replicate it without it just happening. Mine has been better lately. I think the new terminal changes had a big positive effect but this one ES Lint related bug is still in there somehow. Here's another way to look at it: There exists a condition during which one or more VS Code tab editors are incorrectly displaying an error such as:
If you close and reopen the tab, it's still there. ES Lint works fine, it's just confused about that one error. Sometimes there is only one or two, but other times the file might contain 5-10 errors in a giant file and all of them are offset weird and nonsensical. They do appear to have been correct at one point. Maybe there was a missing semi-colon or missing comma. It lacks the ability to forget or pass through an cyclically occurring negative feedback loop. If you can show me a way to submit a diagnostic report @dbaeumer I could provide it next time it occurs. Maybe you could gain insight from seeing what my state was in conjunction with a screenshot. My most reliable way is to open a new existing project with large files in it and go from zero linting to full blown Airbnb config and using I don't use TypeScript. That is also an interesting fact to me after reading Sean's Tweet. That could indicate that the problem exists somewhere in ES Lint reporting and in-memory cache logic where there is overlap between TypeScript, React, and Vue DOM markup, especially React classes and Vue instances. |
|
Thanks for reaching back on this issue. I know it is annoying (not just for you). If this happens (e.g you have one stale error) could you enable verbose tracing and see if the server is still sending the stale error. (
Only in the third case the error would surface in ESLint and TS. |
|
Current command My current workaround for kill $(ps aux | grep 'eslintServer' | awk '{print $2}')This command I add to my webpack config, and if it detects some build file changes which affects on eslint configs - just run it. VSCode automatically restarts killed eslint server as expected. |
|
Here is an animated GIF @dbaeumer
I have trace server set to messages, and I notice there has been no activity in there in the past 4 hours. That may be an issue. I will try repeating these steps for you over the weekend, including after rebooting and I will keep a very close eye on the symptoms I am seeing plus your instructions a couple posts up from this one. Here is another GIF after. I wanted to see what would happen if I closed the tab and reopened it. As you can see, the bug state remained. I also chopped up the code a bit so you can see how it is acting:
P.S. after reflecting, I realize you may have wanted to see if it was an ES Lint issue or an issue in the Vue plugin logic. I will report it to them if so. I also noticed this, which occurs to me fairly often also. Underlines go in weird places and also quite non-sensical:
Usually I notice it when colours are highlighted the incorrect colour. I am referring to this extension: Color Highlight Something causes it to do what is shown in the image. I will also report that to them if that is a good idea. [edit] I also had an issue where the tabs were not horizontall scrolling when I mousewheeled over top of them. That issue has also fixed itself when I restarted VS Code. Totally unrelated, but you never know. |
|
@agm1984 thanks for all the information. So it looks like the ESLint server is not validating the file anymore. This can be due to two reasons:
To better understand which one occurs can you let me know if:
|
|
Update: everything has been pretty solid @dbaeumer. After my last issues, I restarted VS Code and everything has been good since. I haven't detected any CPU or memory management issues. In the last two months, it just keeps getting better and better. Both React and Vue have been linting as expected with barely any anomalies, which is historically rare for me. I noticed last week I was running ES Lint I think the overarching integrated terminal changes in latest updates has had a pretty profound impact on my UX. I have to say nice job team. Sometimes I open like 5 VS Codes with monster projects in them, and CPU/memory management has been excellent lately. I have your instructions @dbaeumer, so I will update you if I have anything. I encourage everyone else to do the same. Read the last few posts and try to provide data and/or steps to reproduce your bug state. |
|
@agm1984 great to hear that things got better for you. I will leave the item open. Please ping if you see experience any problems. |
@nodkz May I know how did you add the command into Webpack config? Right now I can only manually run the command on terminal. |
|
So I'm still having issue that whenever I modified the alias section in my Webpack config, the ESLint doesn't pick up the changes and prompt me errors on my code unless I completely kill VSCode and reopen it. I think it's because of the ESLint server only read the Webpack config file on server startup but not monitoring the file. Is there any workaround except restarting VSCode? I don't wanna restart the editor every time I made some changes on the alias section. Thanks. |
|
@iamWing the best would be to make the ESLint server aware of this and re-read the configuration. I would accept a PR for this or if you give me an example (GitHub repository) which demos this I can have a look as well. |
|
PR to fix this is above, and it was just as simple as suggested. I thought it would take more than this, but I tested by switching out eslint with a much older version and it recovered well from that. |
|
The "restart" command is really necessary, I'm still struggling today, especially when I wanted to migrate javascript file to typescript, or even just rename some files, the ESLint server will break for sure. |
|
I just bumped into this edge case as well. Currently migrating from tslint -> eslint and to reuse config rules I have a function in a separate file that returns root eslint config based on some parameters. Default merging strategy is not a good option. Took me a bit to realize that changes in this js file ends up cached by node runtime as module is already imported! EDIT: Good that is JS, was able to do: delete |
|
Version 2.1.17 now contains a Restart Server command. |
This may be a rare use case, but I'm actually developing an eslint plugin. I live test the plugin by symlinking the package to node_modules, and load it up in my eslintrc file. So I develop and live test at the same time.
When I make changes to the implementation of a rule for my plugin, it doesn't get picked up by this extension. Is there a way to restart the eslint server or tell it to reload the plugins?
I guess the ability to restart would also be useful if we update an eslint plugin's version with npm (to load up new rules, for example)
The text was updated successfully, but these errors were encountered: