-
Notifications
You must be signed in to change notification settings - Fork 7
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
Plugin wrongly thinks Vite is in production mode #51
Comments
I have the same setup (building locally and then transfering all files to the server). Kirby Vite checks for a Normally I just run everything in on terminal window, so for deploying/building I stop the dev server first, run my deployment, and then start it again. Since I usually don't deploy many times a day, I didn't mind stopping/restarting the dev server. So I guess you want to keep the dev version running in one process while deploying in another process? I guess we could add a option to the vite plugin to prevent removing the |
Yeah it’s exactly that, Vite continues to run in dev mode. In my case it happens because I use Docker and it requires the container to have a command running to stay up. I run the build command in the container in parallel of the server. |
Ah okay, i use docker with DDEV which stays up once it started. But to support your use case I'm open for a PR (since I don't have much time right now). I would like to avoid a config flag that prevents the |
During my deployment process, I build Vite assets locally and transfer them to the server afterwards, so I don’t need to have Node & all the assets pipeline installed on the server.
This process writes the files on disk at the expected
build.outDir
location, making kirby-vite think it’s in production mode afterwards. This behavior forces me to manually delete the dist folder and restart the server after every deployment to pick up new changes.I appreciate the fact it works seamlessly out of the box, but I think it would be great to have a setting to be able to enforce one mode or the other for such cases. Would you be open to such feature?
The text was updated successfully, but these errors were encountered: