search

vitejs / vite

Next generation frontend tooling. It's fast!
http://vite.dev
MIT License
68.58k stars 6.19k forks source link

vite build --watch HMR #3873

Closed oscartbeaumont closed 1 year ago

oscartbeaumont commented 3 years ago

Clear and concise description of the problem

My current setup involves using the vite build --watch command so that I am able to serve my Vite frontend from a custom webserver. It would be great if hot module reloading could be used in this configuration.

This feature is supported by Snowpack via the command snowpack build --watch. --hmr.

Suggested solution

The HMR server could still be served on a port controlled by Vite and the HMR code could still be included in the outputted files. This way the HMR would work even though the frontend files were served with another webserver.

I am new to Vite's codebase but with some pointers about where to start would be happy to attempt a PR.

surjithctly commented 3 years ago

This would be a great feature.

KieranP commented 2 years ago

For me, this is the main reason I can't switch from Snowpack to Vite. I use snowpack to build the frontend and watch for file changes, compiling the output into the public directory of a rails app. I then boot up the rails app and it serves public/index.html (this gets around CORS issues when the frontend hits the api). Snowpack supports spinning up a HMR server on a watched build, while vite does not. As such, HMR does not work for Vite. Until this feature is supported, I can't switch.

nilooy commented 2 years ago

That would be amazing to have.

j commented 2 years ago

Yes, this. I'm using Vite library mode and a monorepo with a server in front to serve library assets. I'd like that server to handle hot reloading of custom HTML pages.

pearone commented 2 years ago

+1

nilsdjupvik commented 2 years ago

+1

emosheeep commented 2 years ago

Sounds wonderful! I often work with pnpm's workspace protocol, start dev server at one project and run vite build --watch at the other. I must wait for seconds(10s in common) after I made some changes, because the package is too large. It will save me from the endless waiting if hmr can be built in!

joglr commented 1 year ago

Sounds wonderful! I often work with pnpm's workspace protocol, start dev server at one project and run vite build --watch at the other. I must wait for seconds(10s in common) after I made some changes, because the package is too large. It will save me from the endless waiting if hmr can be built in!

I am facing this issue too, having to wait 0.5 to 2.5 minutes for changes to take effect with cold reload, which is brutal for the developer feedback loop.

mikois commented 1 year ago

Upvoting. For me it's a showstopper, dev/staging remote servers are commonplace and this essentially makes vite a hassle in these scenarios. Also a problem, related in some cases: outdir won't accept absolute paths.

jarkt commented 1 year ago

Oh damn, that's why it doesn't work. 😫 Any plans for it?

bluwy commented 1 year ago

We have discussed this yesterday with the following conclusions:

  1. Vite's HMR architecture is built around dev and not build. Supporting this would change how Vite works fundamentally.
  2. While we understand dev HMR is not feasible in some environments, which needs vite build --watch instead, this isn't a common path that's worth the maintenance. We'd like to focus our efforts on improving dev HMR.
  3. There is a rollup-plugin-hot that somewhat implements this. Unsure if it still works today, but if it's possible it could be a community Vite plugin first.

We are however open to a similar proposal (https://github.com/vitejs/vite/issues/5196) to implement vite preview --watch to slightly improve the vite build --watch experience. Closing in favour of that.

jarkt commented 1 year ago

I'm currently building a JavaScript hosting platform with a custom v8 environment. So I wrote a client that runs builds of a Vue SSR app and syncs the results to the server. The builder stays in watch mode. With this decision, Vite is no longer suitable as it's not possible to realize HMR.

Using the vite dev server is not an option as the code doesn't run on the NodeJS platform and it should also not in development. So the only option is to switch to another builder like webpack.

But there is another problem: it's not recommended to use Vue3 with TypeScript and webpack. (https://vuejs.org/guide/typescript/overview.html#note-on-vue-cli-and-ts-loader) Better is to use vite...

The definitive decision not to support HMR in build watch mode is bad because it means there is no perfect and clean solution for me.

Just my 2 cents...

mikois commented 1 year ago

Jark, it may sound trite, bordering on sassy, but vanilla is a nice, clean solution. It's a sentiment i am leaning more and more towards, and so do many of other senior devs. With the advent of native modularity and a myriad of lazy data loading options it makes plenty of sense.

śr., 19 lip 2023, 21:58 użytkownik Jark Tonnätt @.***> napisał:

I'm currently building a JavaScript hosting platform with a custom v8 environment. So I wrote a client that runs builds of a Vue SSR app and syncs the results to the server. The builder stays in watch mode. With this decision, Vite is no longer suitable as it's not possible to realize HMR.

Using the vite dev server is not an option as the code doesn't run on the NodeJS platform and it should also not in development. So the only option is to switch to another builder like webpack.

But there is another problem: it's not recommended to use Vue3 with TypeScript and webpack. ( https://vuejs.org/guide/typescript/overview.html#note-on-vue-cli-and-ts-loader ) Better is to use vite...

The definitive decision not to support HMR in build watch mode is bad because it means there is no perfect and clean solution for me.

Just my 2 cents...

— Reply to this email directly, view it on GitHub https://github.com/vitejs/vite/issues/3873#issuecomment-1642675151, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFIGFXQ574U6QYKXIZWMMM3XRA36TANCNFSM467P3VYQ . You are receiving this because you commented.Message ID: @.***>