Dev server is proxying requests starting with @ that should be handled by Rails

[andrei4002]

• I have tried upgrading by running bundle update vite_ruby.
• I have read the troubleshooting section before opening an issue.

Description 📖

Adding this to rails routes:

get "/@:slug" => 'profiles#show', as: :profile_slug

and then going to localhost:3000/@some_profile

doesn't go through the rails router, and shows a page with:

The server is configured with a public base URL of /vite-dev/ - did you mean to visit [/vite-dev/@some_profile](http://localhost:3000/vite-dev/@some_profile) instead?

I can't say if this is an actual issue or some edge case I have that just needs some extra configuration, hopefully it's the latter

Reproduction 🐞

Vite Ruby Info

Run bin/rake vite:info and provide the output:

bin/vite present?: true
vite_ruby: 3.0.9
vite_rails: 3.0.6
rails: 6.1.4.1
node: v17.7.1
npm: 8.5.4
yarn: 1.22.17
pnpm: 
ruby: ruby 2.7.4p191 (2021-07-07 revision a21a3b7d23) [arm64-darwin21]

installed packages:
qonsult@ /Users/andrei/dev/qonsult
├─┬ @vitejs/plugin-vue@2.2.4
│ └── vite@2.8.6 deduped
├─┬ vite-plugin-ruby@3.0.8
│ └── vite@2.8.6 deduped
└── vite@2.8.6

[ElMassimo]

Hi Andrei! Thanks for reporting 😃

This is a known corner-case in the dev server proxy.

Please try the fix/strict-dev-proxy branch which includes a potential fix for this situation.

Since it's very unusual to have a root URL that starts with /@, I'm considering not merging that fix, since the dev server proxy is particularly sensitive to any regressions in Vite itself.

---

For historical reasons, Vite sometimes did not use the provided base when performing HMR, so it was necessary to add a workaround and detect imports of dependencies which start with /@id/, which happens often when importing npm packages.

Now that this and similar issues have been fixed, it should be possible to be more strict and require the dev server prefix to be present.

Unfortunately, there's no workaround available if using "publicOutputDir": "", but there's no reason to use that config in development, so it should be fine.

[ElMassimo]

Closed by 93d071b, released in vite_ruby@3.0.10.