Skip to content
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

Split public and browser WS server #3138

Closed
4 tasks done
sheremet-va opened this issue Apr 5, 2023 · 1 comment · Fixed by #5765
Closed
4 tasks done

Split public and browser WS server #3138

sheremet-va opened this issue Apr 5, 2023 · 1 comment · Fixed by #5765
Labels
feat: browser Issues and PRs related to the browser runner

Comments

@sheremet-va
Copy link
Member

sheremet-va commented Apr 5, 2023

Clear and concise description of the problem

Currently, browser and public-facing API share the same web socket reporter. We should limit public usage and move browser methods into their own reporter so it's easier to manage and not break public API.

Suggested solution

Move browser methods from packages/vitest/src/api/setup.ts into their own reporter (or better just as create a separate rpc).

Alternative

No response

Additional context

No response

Validations

@sheremet-va sheremet-va added the feat: browser Issues and PRs related to the browser runner label Apr 5, 2023
@sheremet-va
Copy link
Member Author

@userquin I would recommend doing this. We have a workaround with browserPromise, but in fact, we can just use a regular RPC. Here is the line that setups a WebSocket:

;(await import('../../api/setup')).setup(project, server)

If we create a separate RPC, we can share it with the browser provider and reuse it in the pool to wait for a response.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feat: browser Issues and PRs related to the browser runner
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant