Stabilizing build.copyPublicDir

[patak-dev]

build.copyPublicDir

• Introduced in [email protected] by @bluwy
• Rationale in the Original PR
• Docs
• It is currently used by SvelteKit and Astro.

If you have feedback about this API, please share it here so we can evaluate moving this feature out of experimental in Vite 5.

[pbowyer]

It's working awesomely for us.

Situation: Building assets for a traditional (server-rendered) website, where a gulp build process is already copying the assets to the public directory. Yes, we're working towards completely removing gulp but that means redoing the component library so it's a slow process. I didn't want to add a bundler into gulp; let's move towards where we want to be.

Before this option, we ended up with a set of (gulp copied) assets where we wanted them, and then Vue added a second set at dist/assets. Now that doesn't happen.

[fvsch]

I'm using build.copyPublicDir for the Vite config used in a server-rendered PHP site, which happens to have a public directory that should not be copied in the Vite build.

Technically I could use publicDir: false, and had used that initially. So I don't have a use case for build.copyPublicDir per se, except that I find it more explicit.

[patak-dev]

In this case, publicDir should be used though. copyPublicDir will not disable the feature entirely and files in /public will still be treated in a special way by Vite.

[mohyddintash]

I wonder if it would be possible to copy the files from publicDir to dist/<custom_dir>/assets, the case for me is that I need to version the builds and then I would like all bundled files are under dist/1.0.0/ for example.

[GodlessLiu]

Same expectations as you！！

[graue]

This flag was helpful. My use case: my app allows user-uploaded files, which are saved under public/uploads. I was surprised to find that after uploading a file, I couldn't download it until I manually reran vite build. Obviously, I had expected the files under public/ to be passed through, not bundled. This, plus an explicit invocation of the serve-static library for production, fixed that.

I know it's more common to save user uploads on an external service optimized for file storage like S3, but this app is so small-scale that's not necessary.