Add exclude option for build.copyPublicDir

[Plumbiu]

Description

When I use vercel to deploy the vite application, I need to write files to the public folder, so I added the .gitkeep file, but vite also uses .gitkeep as a package file.

This problem is because I need to use the web program packaged by vite as a cli tool, but I also want to deploy it to the vercel server for users to view the effect. In order to facilitate API requests, I use the public folder.

Suggested solution

export default defineConfig({
  build: {
    // add exclude option
    copyPublicDir: { exclude: ['.gitkeep'] }
  }
})

Alternative

No response

Additional context

No response

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]

I don't think we need a new feature for this since it could be fixed with a post-build step to remove the .gitkeep? We usually try to reduce the API surface area.

But also, (depending on your usecase) could you dynamically create the directory instead of using .gitkeep?

[Plumbiu]

The plubic folder will also be used for development, dynamic creation seems a bit cumbersome, remove .gitkeep with a post-build step will be great, thanks!

The. getkeep file is not very large, so preserving it is not a problem, I just hope this option can handle various situations, I brought up a PR and if it's not needed, it can be turned off.

[bluwy]

I think we'd want to make public more opinionated, in that it simply copies it entirely to dist. So I think it's best to not add this new option.

It could also be done as a Vite plugin with the generateBundle hook to manually remove the unwanted files too.

I'll see if others have thoughts on this though.

[Plumbiu]

Yeah, this application scenario is really limited, so only the .gitkeep file was ignored in the latest PR

[patak-dev]

Let's close this issue, I also think it is better to avoid adding extra complexity to Vite core if possible. See also #14304 (comment)