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

Feature Request: option for publicDir to override the default public root in dev mode #2587

Closed
GrygrFlzr opened this issue Mar 18, 2021 · 7 comments
Labels
enhancement New feature or request

Comments

@GrygrFlzr
Copy link
Member

Is your feature request related to a problem? Please describe.

Currently, even though publicDir is set to a directory inside vite.config.js, in addition to serving those files statically, all files in the current directory are also still served as static files in dev mode.

For example, http://localhost:3000/package.json will always show the project's package.json regardless of the publicDir.

Describe the solution you'd like

One of:

  • Disable the "default root is always public" behavior when the publicDir is set (is this a breaking change?)
  • An option in the config to disable the "root is public" behavior, if the above is not feasible.

Additional context

Some devs have tripped up and accidentally referenced /public/image.png in their code, which works in dev but breaks in production, as the project root is no longer served as static.

@patak-dev patak-dev added the enhancement New feature or request label Mar 20, 2021
@rdmurphy
Copy link

We also hit this and it made me wish it was possible to just copy <publicDir> right into <build.outDir> without putting those files in the root + maintaining the same directory structure. Then the path-ing would work as you'd expect even after building and still be compatible with any import.meta.env.BASE_URL concatenation in JavaScript.

It feels counter intuitive that everything else paths the way you'd expect except for files in the <publicDir>. I was trying to explain to another developer that <publicDir> is unique and they should "pretend" it's in the root and it really didn't click. (Especially because it does work in dev mode as @GrygrFlzr notes!)

I'd probably advocate for control of where <publicDir> ends up in builds (or a breaking change that makes it work as I suggested above) vs. purposely making the dev server work not as you'd expect to force this mechanism.

@rdmurphy
Copy link

(I do recognize that would lead to favicon.ico and robots.txt not being in their "default" locations, but that's already true if you are using base, correct?)

@rdmurphy
Copy link

@patak-js Did this actually get addressed with that commit? I may have overlooked it but that seemed to be only changes related to Stylus.

@GrygrFlzr
Copy link
Member Author

Nope. That's a typo in the commit message, they intended to close #2857, not this issue. Reopening.

@GrygrFlzr GrygrFlzr reopened this Apr 15, 2021
@dallonf
Copy link

dallonf commented May 2, 2021

What's the rationale for this being a feature that the dev server currently works differently than production in this way? I was actually just coming here to report a bug when a member of my team imported some assets from the root directory instead of putting them in "public", which would have caused it to break in production had I not caught it.

@hyf0
Copy link
Contributor

hyf0 commented Aug 22, 2021

For now, vite will warn about the unexpected requests for publicDir. See details in #4631. Do we still need an explicit option to disable "root is public"?

@benmccann benmccann added this to the 3.0 milestone May 2, 2022
@patak-dev patak-dev removed this from the 3.0 milestone Jun 20, 2022
@patak-dev
Copy link
Member

I agree with @hyf0 here. After #4631, the main problem the new option is trying to solve shouldn't occur as the users will see a clear warning: Playground.

We also discussed in a team meeting that the Vite server should keep working as an enhanced static server over the root directory, as this is part of the mental model of Vite.

@patak-dev patak-dev closed this as not planned Won't fix, can't repro, duplicate, stale Apr 7, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Apr 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants