We have a development server with lots of developers and lots of sites. We setup each site as a ghost and this makes it great to share with other staff and management and not have to worry about things like firewalls and DNS on lots of different machines.
However the recent switch to Vite seems to break this and I'm looking for advice on how to fix it.
I install a new project with laravel new some-web-site.co.uk --jet --stack=livewire and at the end of installation it automatically runs npm run dev which calls Vite's server. Doing the exact same thing locally with docker works fine, however on our dev server this obviously won't work because localhost makes no sense. It doesn't make a difference when I use --host either but I presume more would need configuring?
Is it possible to setup Vite for remote servers? It seems the documentation concentrates on docker and local development and not development servers.
This is something I am also struggling with. I have a local setup with a couple servers I host projects on. Since vite came into play, I have had to use a local (WSL) instance of laravel to get vite working properly. I would love to know how to do a setup with laravel on a remote sever as I switch between a desktop and laptop regularly.
I also have a huge problem with this.
I have always preferred remote vps development, i don't want to run absolutely anything on my machine and it seems to be impossible to setup vite frontend compiling on my laravel Forge/DigitalOcean.
It just boggles my mind that Laravel team would force us to chose our development environment (or at least make it really impossible/difficult to setup) just in order to be able to build frontend javascript.
For servers run the build. š¤·āāļø
you can't be seriously suggesting that we should manually tab to console, run build and wait 1 minute after i doing a single line change in js/css
@randomcast1 No. But I also donāt use completely different machines to the one Iām working on, to ābuildā assets.
@martinbean and this is your dev environment of choice. is it really that difficult to understand? just because you are used to develop locally doesn't mean everybody does. IDEs even have native support for remote development, it's really silly to force someone to a specific dev environment for the choice of a frontend bundler that runs its own web server (which is cool that it can but it absolutely should not do by default)
@randomcast1 I have no idea what youāre going on about.
I work on a computer. I run my projects on that computer. I run npm run dev on that computer whilst Iām developing. I then push my projects to production, where npm run build is ran to, well, build my assets for production.
If you are developing on a remote server for whatever reason, then Vite allows you to change the hostname assets should be served from. Thereās no issue whatsoever here; you just seem to have created an account to moan about Vite for the sake of moaning.
@martinbean No, you keep ignorantly talking about how you have no problem developing locally, while i say that i (and many other people) develop remotely and vite is not built for it. Because vite forces people to use it as actual server instead of having your project being served by whatever environment of choice you want (as it should be)
@lukevi below provided a useful answer of hacking vite into serving to actual server via port-forwarding (thank you @lukevi , gonna try this), but as you see this adds an additional layer of complications just because some frontend builder does things it should not
@randomcast1 If something is difficult, it usually means youāre doing it wrong.
@martinbean which could imply that vite-server approach is wrong for server-sided development
@randomcast1 Vite isn't for server-side development? š¤ It's a build tool for the front end that's it, it comes with a dev server for HMR but at the end of the day, it's a build tool.
I do have this working - here's what I did:
On the VPS I'm using docker, accessing it via VSCode SSH and my browser. Vite hot-reload runs on port 5173 by default, so I expose that port out of the container. Then I use VSCode port-forwarding to make my VPS port 5173 accessible as localhost:5173. Then within my .env file, I set ASSET_URL=https://localhost:5173.
With that, my VPS development environment works with hot-reloading in my desktop browser.
if anyone can help me with this
https://laracasts.com/discuss/channels/laravel/bug-in-sorting-values-in-filament-table?page=1&replyId=897475
Update: Thanks a lot 4wk for suggesting an improvement on the Gist of this! Updating here to reflect that change
We ended up achieving this by customising the Vite config. I'm not Vite/JS expert so I welcome feedback, but this solution works for 6+ developers on a remove development server. Additionally we store the config in our .env files and allow Vite to load from there.
https://gist.github.com/legecha/afccb720edc799c04a0d698a4f6f7823
/**
* This vite config allows you to run `npm run dev` in Laravel and access
* resources, including with hmr, in the same manner as if you were
* developing locally.
*
* All config is stored in your standard .env file and multiple users can
* have their own instance running by specifying a unique port.
*
* The certificates are required - use the same ones as used on your
* web server to secure your development domains (for instance letsencrypt).
*
* Add this to your .env file:
*
* VITE_ASSET_HOST="your.development.url.com"
* VITE_ASSET_PORT=5173
* VITE_PRIVKEY_PATH="/path/to/certs/privkey.pem"
* VITE_CERT_PATH="/path/to/certs/cert.pem"
*/
import { defineConfig, loadEnv } from 'vite';
import laravel from 'laravel-vite-plugin';
import fs from 'fs';
export default defineConfig(({ command, mode }) => {
const env = loadEnv(mode, process.cwd(), '')
return {
server: {
host: true,
port: process.env.VITE_ASSET_PORT,
strictPort: true,
hmr: {
host: env.VITE_ASSET_HOST,
port: env.VITE_ASSET_PORT,
},
https: {
key: fs.readFileSync(env.VITE_PRIVKEY_PATH),
cert: fs.readFileSync(env.VITE_CERT_PATH),
},
},
plugins: [
laravel({
input: ['resources/css/base.scss', 'resources/js/app.js'],
refresh: true,
}),
],
}
});
@legecha Thanks a lot, your solution works perfect, you are a saviour!
@legecha a bit of a non-sequitur question - do you think a similar approach could work on wordpress as well? I've came across this thread numerous times while trying to find a way to run vite on a remote server. I know about the "run build -- -watch" solution but that takes over 5 seconds for each save. Local development just doesn't do it for our team.
@dllhx Hey, sorry for the slow reply, just noticed this while updating my own accepted answer.
Honestly, although I've done stuff in Wordpress before, I have never used it with Vite. In theory I don't see why it wouldn't work, though I am not sure about entry points in Wordpress because the sheer massive number of file.
Presuming you have Vite working already(?) or there is an accepted way to use Vite with Wordpress, then I don't see why the changes I suggest couldn't work. I say give it a go (if you haven't already) and report back here to let others know, in case they also end up here via Google. But sorry, I have zero interest experimenting myself because I really hate working on Wordpress :grimace:
Please or to participate in this conversation.