-
-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extension fails to initialize when server.* properties are modified in Vite(st) configuration #226
Comments
Workaround, check if mode === 'test' to opt-out the plugin |
Any https configuration in I researched it a bit and it seems that multiple parts are at play here. I may be mistaken in any of them though tldrThe issue looks very similar to https://github.com/vitest-dev/vitest/pull/4855/files but extension currently has no way to know whether api is secure or not vitest partIt all starts with the fact that dev server in This https-configured server then gets saved in vitest context And then when the api setup is called But then does not respect this https in the logs here vscode extension partExtension run vitest api to get the config via executing it with cli api args vscode/src/pure/watch/vitestConfig.ts Line 64 in d62ca01
and then assumes that it's a non-secure url vscode/src/pure/watch/vitestConfig.ts Line 11 in d62ca01
which is not true and this is why connection just fails additional challenge is if https is configured with a self-signed certificate just using vscode/src/pure/watch/ws-client.ts Line 121 in d62ca01
resultsI was able to make this work by explicitly using possible solutionsforce non-secure for vitest apiThe fact that vite config https settings are leaking for vitest api/ui seems kinda counterintuitive for me and wonder if it should be the case. What problems may arise if vitest api will be made non-secure all the time? allow to opt out of secure vitest apiSomething like try both wss and ws (and maybe even rejectUnauthorized: false)Just try multiple variants of connecting and see which one works. This looks like a last resort for me. All of those may be related to the idea of splitting vitest api for different usecases vitest-dev/vitest#3138 cc @sheremet-va |
The current idea is to use Vitest API directly: #253 With this, we don't need to start a server with a user configuration at all. |
This is fixed in pre-release 0.5.0 and higher. Note that the extension now requires Vitest 1.4.0 or higher. We no longer start any server. |
Modifying the following server properties makes the extension broken:
The text was updated successfully, but these errors were encountered: