Stop serving static files from root directory

[benmccann]

Clear and concise description of the problem

Vite serves files under the root directory:

vite/packages/vite/src/node/server/index.ts

Line 558 in 1e9615d

middlewares.use(serveStaticMiddleware(root, server))

This has caused some collisions. E.g. a SvelteKit user recently reported that they cannot have a URL path of tests because the static serving will attempt to serve the tests directory (sveltejs/kit#4353).

It's also caused quite a bit of confusion with the publicDir and base options because files end up being available via multiple URLs. E.g. if you have public/image.png you could access it from both image.png and /public/image.png which has caused a number of users to be confused in the past

Having the source in the root directory has caused us issues because the root directory is then watched by Chokidar. The output is placed in a sub-directory within the root directory and having the output file being watched caused problems that were extremely difficult to track down and diagnose. It would be nice if the source lived within a subdirectory (SvelteKit projects use the src directory)

Finally, this has caused a number of people to have security concerns. A lot of people have sensitive files like .env in their root project directory. I think we may be special casing .env now, but a number of people have also been surprised to find that their files are being served. We've attempted to mitigated this with server.fs.allow, but have not yet found that to be a suitable solution. It is currently broken for many SvelteKit projects - though it may be fixed after 2.9 is released (#6518). It's also been quite complicated to configure correctly.

Suggested solution

Stop serving the root directory. Check that we still correctly serve source maps

Alternative

We could utilize the server.fs.allow config to make certain files unservable. Right now if you take package.json off the allow list you will get a 403 and it's impossible to create a middleware that will serve a URL like http://localhost:5173/package.json. But we could remove the 403 message and just continue on or we could serve allowed files, run the other middlewares, and then add a new 403 middleware after postHooks. I would recommend also changing the server.fs.allow default from the package root to something a bit safer like ['src', publicDir] and only watching those directories vs the whole project root

Additional context

@patak-dev and @aleclarson both indicated that they found the current behavior strange as well

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[bluwy]

This looks similar to #2587

[sapphi-red]

The following features depend on the root-static-serving behavior.

• import imgUrl from '/src/img.png' / import jsUrl from '/src/foo.js?url'
  • imgUrl will be /src/img.png by fileToURL
• files import in CSS (background: url(/src/img.png))
  • this also uses fileToURL
• import wasm from '/src/foo.wasm?init'
  • this also uses fileToURL
• import Worker from '/src/foo.js?worker' / new Worker(new URL('/src/foo.js', import.meta.url))
  • this also uses fileToURL
• new URL('/src/img.png', import.meta.url)
  • this syntax does not get any transforms during dev
• <img src="/src/img.png">

So it cannot be simply removed.

[benmccann]

In these examples, all the files live under /src, so I wonder if we couldn't just serve /src? (or some configurable set of directories)

Alternatively, though likely more controversial and so probably not preferable to the prior option, I wonder if absolute imports get much usage and must continue to be supported? I didn't know about them until now and have never used them, but have only used relative imports or imports starting with an alias.

[sapphi-red]

Defaulting root to /src/ could be an option.

I wonder if absolute imports get much usage and must continue to be supported?

IMO the support for users could be removed. But it is used internally. That's the reason I said it cannot be simply removed. One way to get around this is to add ?assets to internal ones in order to differentiate them.

[patak-dev]

I think we should explore this, and I have feedback from Astro that they also consider this request important. But we have already been in v3 alpha long enough now and we need to release the major before Astro 1.0 and Nuxt 3.0.
I also think that even if we manage to do this now, it will be risky as many plugins may be using the current behavior. I think the best path forward is to rework Vite's internals and then expose the new scheme as an option. Then SvelteKit can enable it by default but users still have a way out if their plugins are failing. This can be done at any time in v3 as it isn't a breaking change, so I'll remove this from the v3 milestone.

[7antra]

Any news 😰 here ?

🙏

[bluwy]

We discussed this in the last meeting, and decided it's better to have this enforced by metaframeworks instead. This is because this breaks how Vite works fundamentally (a simple static file server), as some examples sapphi pointed out. Fixing this would require a big refactor and breaking change so it's better to stick with what it has for now.

If extra strictness is needed, frameworks can inject middlewares to intercept requests to prevent serving some crucial routes. server.fs.allow would also be a solution otherwise.

Closing this as not planned.