fix(cli): after setting server.open, the default open is inconsistent…

[kinfuy]

… with the shortcut key (#11971)

Description

fix #11971

After setting server.open, the default open is inconsistent with the shortcut key，Now only the shortcut key processing has been modified

PS: Another point is that the displayed urls are also inconsistent. I don't know whether to handle them

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[bluwy]

PS: Another point is that the displayed urls are also inconsistent. I don't know whether to handle them

Do you mean the displayed URL in the CLI is inconsistent between runs? If there's a way to reproduce them, it would help identify where to fix.

[kinfuy]

PS: Another point is that the displayed urls are also inconsistent. I don't know whether to handle them

Do you mean the displayed URL in the CLI is inconsistent between runs? If there's a way to reproduce them, it would help identify where to fix.

The server. open is set, and the displayed URL is inconsistent with the default one (shortcut key)

 server:{
    open:'/test'
  },

[bluwy]

I believe that's intentional, the displayed URL shows the base path where it's being served, while server.open can be used to open another URL (e.g. for quick dev). I think it's fine to have them inconsistent as they serve a different purpose.

[kinfuy]

I believe that's intentional, the displayed URL shows the base path where it's being served, while server.open can be used to open another URL (e.g. for quick dev). I think it's fine to have them inconsistent as they serve a different purpose.

If open. server sets a string, maybe we can give a prompt and display an open URL separately.
If necessary, I can open a new PR

[bluwy]

If open. server sets a string, maybe we can give a prompt and display an open URL separately.

I'm slightly leaning towards not needing one for now because when --open is specified, it would open the browser immediately and the user knows what's the URL directly. The could use the o shortcut too if they forgot about it 🤔

[kinfuy]

If open. server sets a string, maybe we can give a prompt and display an open URL separately.

I'm slightly leaning towards not needing one for now because when --open is specified, it would open the browser immediately and the user knows what's the URL directly. The could use the o shortcut too if they forgot about it 🤔

This can also be done, because now it will cause a visual confusion, why the shortcut key and default open are not the displayed address.
Of course, I may know if I set it myself. It may be forgotten when developing by many people. This is a small feature. There is no problem without adjustment

[patak-dev]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI: Open

suite	result
astro	❌ failure
histoire	✅ success
iles	✅ success
ladle	✅ success
laravel	✅ success
marko	✅ success
nuxt-framework	✅ success
previewjs	✅ success
qwik	✅ success
rakkas	✅ success
sveltekit	✅ success
vite-plugin-ssr	✅ success
vite-plugin-react	✅ success
vite-plugin-react-pages	❌ failure
vite-plugin-react-swc	✅ success
vite-plugin-svelte	✅ success
vite-plugin-vue	✅ success
vite-setup-catalogue	✅ success
vitepress	✅ success
vitest	✅ success
windicss	✅ success

[patak-dev]

Looks good to me. Running ecosystem CI just in case. Nobody should be using startServer isRestart but it was part of the public API.

[bluwy]

The Astro fail seems to be a fluke, I just re-ran it. This LGTM too.