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

Copy files to public folder on change when watching #36

Open
KarelJanVanHaute opened this issue Nov 23, 2022 · 14 comments · May be fixed by #37
Open

Copy files to public folder on change when watching #36

KarelJanVanHaute opened this issue Nov 23, 2022 · 14 comments · May be fixed by #37

Comments

@KarelJanVanHaute
Copy link

You can now already do

watch: { reloadPageOnChange: true }

But in the system I'm using I refer to the files in the dest folder with a serverpath not a URL.
So it would be nice to have an option to also copy the file on change and then reload the page.

Something like:

watch: {
  reloadPageOnChange: true,
  copyToDest: true,
}
@sapphi-red
Copy link
Owner

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.

@sapphi-red sapphi-red added the needs more info Further information is requested label Nov 23, 2022
@KarelJanVanHaute
Copy link
Author

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

@KarelJanVanHaute
Copy link
Author

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

@sapphi-red
Copy link
Owner

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.

@KarelJanVanHaute
Copy link
Author

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.

@sapphi-red
Copy link
Owner

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'
        }
      ]
    })
  ]
}

@KarelJanVanHaute
Copy link
Author

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.

@sapphi-red
Copy link
Owner

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

@KarelJanVanHaute
Copy link
Author

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?

@sapphi-red
Copy link
Owner

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.

@sapphi-red sapphi-red removed the needs more info Further information is requested label Nov 25, 2022
@KarelJanVanHaute
Copy link
Author

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.

@mvaneijgen
Copy link

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?

@nickpoulos
Copy link

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?

@duoyue
Copy link

duoyue commented May 21, 2024

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

I also encountered the same requirement and found that "rollup-copy-plugin" can be used as a substitute. I hope this can help those who need it .

import copy from "rollup-plugin-copy";

export default defineConfig({
  plugins: [
    copy({
      copyOnce: true,
      verbose: true,
      copySync: true,
      hook: "buildStart",
      targets: [
        {
          src: "src",
          dest: "dest",
        },
      ],
    }),
  ],
});

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants