vscode-jest: Unable to disable terminal on launch

In the 4.4.0 release notes, I see this new feature highlighted:

enhanced test output discovery by automatically opening TestExplorer terminal upon launch.

Is there an option to disable this? I personally use this extension for quick success/failure visualization in the code margins, and I switch to my terminal app (not a panel within VSCode) when I need more granular test output. I don’t use VSCode terminals and I’d prefer not to have to close them every time I launch or reload the window.

Thanks for all your great work on this extension — it’s invaluable!

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 4
  • Comments: 25

Most upvoted comments

feel free to try the pre-release 4.5.0, you should be able to turn off the terminal with "jest.showTerminalOnLaunch": false setting.

@KevinBatdorf, you raised good points!

You’re also assuming that every JavaScript project is using Jest (I’m guessing because it finds the executable?).

Not every javascript project, but those with a jest in node_modules will indeed activate the extension. I was a bit surprised that a project not using jest could still have jest in the node_module… Can you give us a bit more detail so we can see if we can improve the activation logic to avoid such false positive.

In any case, you convinced me that to treat “no test” as an error might not be the proper severity. I will change that to a warning in the next release.

Instead of flashing the terminal, could you just colorize the status bar like Prettier does?

I also agree with @jakemhiller that this is a great idea! 😃 With this visual cue, I think we could add a jest.showTerminalOnError setting, knowing the alert is not lost.

@jakemhiller Just want to make sure we are on the same page, the errors triggered the show-terminal is not regular test errors but operation or configuration errors that prevented jest from running normally. These should be relatively rate but I do agree we could enhance it as mentioned above.

Thanks for the video. I think I see what the disconnection is now. Let me see if I can make this more clear:

in v4.6 the terminal is unconditionally open in the “foreground” mode, i.e. it will add the bottom panels to you window if you don’t have it yet, and make itself the “active” terminal/panel. This is too intrusive, especially for those who prefer no panel view (like the use case @janaagaard75 mentioned), so we added the jest.showTerminalOnLaunch flag.

in v5, we used a “background” terminal by default, i.e. it does not force open the panels if it’s hidden, nor making itself the “active” terminal. In other words, the content is hidden unless it is the only or latest terminal; or when user explicitly click on the terminal label to bring it to the “foreground” (a.k.a. the active terminal); or when there is a “fatal” error…

When I say “show terminal”, I mean the operation to bring the terminal to the foreground or making it the active terminal. Right now, it only does this when there is “fatal” or execution error (not test error) that could prevent jest from starting. The setting I am considering adding will only control “when” to bring the terminal to foreground, it will not change the fact the terminal will remain to be in the background (you will see it in the terminal list on the right sidebar).

I can understand coming from 4.6, one could easily associate the background terminal with the “foreground” terminal we used to have. This all sounded more complicated than it really is. Please give it a few days and hopefully you can see the difference and find it useful… I did 😄

On the other hand, it is also possible there are bugs and the system is not working as it should. Lets examine each of your use case to make sure:

@janaagaard75:

While I do use VSCode’s terminal window, it’s not something that keep open, because I prefer having more screen real estate for my code, and to be less distracted.

If jest is running correctly, you should not see terminal window pop up if you have it hidden. Is that not the case in 5.1.0?

@jakemhiller:

The current UX forces me to deal with the failing test and actively gets in the way of any focus I might have had on the task i was doing, especially if I was actively working in the terminal.

It should not force you to deal with failing tests… or maybe I don’t quite understand what you really mean. If you have the jest terminal as your active terminal then yes you will see test output just like running jest on the terminal. If you are working on another terminal, then you should not be seeing the jest terminal output at all, if jest is running correctly… What did I miss?

@KevinBatdorf:

looking further into your use case, it seems it’s not a terminal issue, but we activate your workspace that you don’t intent to use jest. Even if we can hide terminal, the jest process might still be running in the background, which is not what you want. If it is in a multi-root project, you could exclude the workspace with jest. disabledWorkspaceFolders; if it’s a single-root, even easier, just use vscode to exclude this extension from the given workspace.


Sorry for a very long reply. I don’t mind implementing the change we discussed above, but want to make sure I understand the actual root cause, so we don’t waste time fixing the wrong issue…

@KevinBatdorf <strike>I was not able to reproduce a forced terminal open for the project with no tests… No test is not an error, I was wrong to assume that it was. So now I am puzzled why you will see the terminal open… Do you happen to have a multi-root workspace, and some other folders have errors that caused the terminal panel to show up?</strike> never mind, I found it…

Does it pop open the terminal whenever a test fails, or whenever a config item fails?

not test failure:

the errors triggered the show-terminal is not regular test errors but operation or configuration errors that prevented jest from running normally.

i.e. the errors that caused jest process not able to run/start.

I think with the change that was made to show the terminal when there is an error you’ve inadvertently ended up in the same situation that led to creating the showTerminalOnLaunch flag. The current UX forces me to deal with the failing test and actively gets in the way of any focus I might have had on the task i was doing, especially if I was actively working in the terminal. I agree with @KevinBatdorf that flashing the status bar or some other more subtle way of showing an error by default (or as an option at least) makes a lot of sense here.