-
-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Allow server.open to be passed readonly string[]
as per open
spec
#9572
Comments
readonly string[]
as per open
specreadonly string[]
as per open
spec
related but different request: |
In contrary to the docs, we actually have our own |
I've put this on the team board to discuss if we want to expand to using |
@bluwy thank for the information. Another solution would be to delete this line from the docs:
And the I'd love to know how to set it to specifically auto-open in Google Chrome, and in a cross-OS compatible way (Mac, Linux, Windows). (Chrome is not my main browser but it's the browser I use for development.) |
This is to reuse the existing tab. By using AppleScript, we can reuse it on macOS+Chromium base browsers. (It does not work with other OS/browers though...) |
@sapphi-red why to open a PR towards |
Thanks @sapphi-red for the find! I think it's nice if we can upstream the changes, we would probably have to have it as a normal dependency then, and re-export the |
Description
Currently, as per the vite types,
server.open
can only acceptboolean | string
→
vite/packages/vite/src/node/http.ts
Line 37 in 26bcdc3
Further more, the Vite docs say:
When checking the Open docs, for best cross-platform support, they suggest to set the browser like so:
Ref: https://github.com/sindresorhus/open#openapps
However, trying to use
open.apps.chrome
in Vite like so, gives a type error:Suggested solution
We need to be able to set Chrome but make sure it works for both Windows and MacOS.
My suggestion is to allow
readonly string[]
which is returned byopen.apps.chrome
so that we can use this option in the Vite config.Alternative
No response
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: