I refer to the files in the dest folder with a serverpath not a URL.

Would you expand this?

Also I guess you also need to copy files when the dev server starts.

Indeed, a copy on server start would be a good idea.

@sapphi-red I made a Pull request for this option. #37

I refer to the files in the dest folder with a serverpath not a URL.

Would you expand this first? Copying a file during dev is currently out of scope of this plugin.

So we refer to the public files from within PHP templates with absolute paths. And when in watch mode, it would be easy if these files get copied on change, so we don't have to quit the watch and run a build to get them into the public folder.

The changes I've made in the pull request do exactly that. And it works fine. So if you agree, then you can merge the pull request.

Are you directly reading those files from PHP (e.g. replacing text) and not simply referring in the rendered HTML?

If you just need to refer it, you can just use the file like <img src="/foo/bar/sample.jpg" /> when the config is:

export default {
  plugins: [
    viteStaticCopy({
      targets: [
        {
          src: 'images/sample.jpg',
          dest: 'foo/bar'
        }
      ]
    })
  ]
}

Exactly.
I'm not linking to the files in the rendered HTML. Because then I could indeed just link. I'm embedding files like .svg's directly into the HTML. So the files get read and then the SVG code is inserted into the rendered HTML.

Then, why do you need to copy the files? I think it's easier to just read the original files.

Because we try to keep production files and the dev file separate. So the site reads from the production public folder, but we add the files in the dev folder. And we then use this plugin to copy them over to the public folder. So the website code expects the files in the public folder. But we do not put them in directly, hence the copy.

If everybody would just put their files in the public folder, this plugin would be obsolete, no?

Have you had a chance to review my pull request? And do you have arguments, not to expand the scope of the plugin with this option?

Because we try to keep production files and the dev file separate.

I see. Thanks for explaining.

If everybody would just put their files in the public folder, this plugin would be obsolete, no?

Yes, I encourage that and documented that. I think the only case this plugin is needed is to use files in npm packages that needs to be served in a specific path.

Have you had a chance to review my pull request? And do you have arguments, not to expand the scope of the plugin with this option?

I've considered again but it's still out of scope of this plugin. This plugin follows the way Vite works: no bundling/copying when dev.
That said, in future when #30 were implemented, I think this feature could fit in because it's mostly the same thing.

Ok @sapphi-red I understand your point. If ever it gets in, please comment on this thread.
For now, I'm just going to use my forked branch for now for my use case.

I just ported my whole project from Gulp to Vite and this is the only step missing to make it complete. I work in a Wordpress environment and even in development the images get reverenced in the dist folder (I would love doing some post processing on the assets, but for now just copying them would be great).

Any plans to just make this an option when running dev?

Yep its a major glaring hole in Vite and related plugins like this. "Stick it in public" refrains are just braindead.

public is the build, developers keep source files outside of the build until runtime - either a watch or a build step.

Why is this plugin ever needed if developers should just toss everything in public?