-
-
Notifications
You must be signed in to change notification settings - Fork 3
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
Support dev server mode w/ HMR #17
Comments
Hi Jonas, indeed, that would be great. It's extremely complicated tho, in my opinion. It would be easy, if we would build the Kirby Panel ourselves. As a matter of fact, you can do so yourself and build your own custom Panel bundle with your components baked in. Then you'll benefit from all of Vite's glory. But since the Kirby Panel has already been built, we execute a bundled and almost "locked" Vue instance. The only entrypoint is Kirby's plugin system. Kirby handles the JS injection. In order to provide HMR, we would have to create a dev server and build a static Honestly, I don't know how to pull that off. Not even considering how to handle the state inside those components and save them between hot updates. Feel free to give it a shot! If you create a POC, I'd be happy to help integrating. For now, the use case and feature request exceeds my time and use case. Thanks for the input. |
Yeah, totally get that! :) I explored this a little and you're right, without some changes to Kirby it doesn't really work. If a plugin is served by Vite it is served as native JS modules. Kirby needs the plugin to be executed before the panel's main With that in place, we can use a plugin entry file that "relays" the request to a Vite development server started by // plugins/kirby-example-plugin/index.mjs
import 'http://localhost:5173/src/index.js' Now we got working HMR! Almost. For CSS changes it works, which is quite nice on its own, and it also works for The easiest way to prevent such errors is to enable HMR only for CSS changes and reload the page if the JS/template was changed. This is how my current HMR implementation for It should also be possible to discern JS updates that cause the HMR runtime to refresh (good) from updates that cause a component reload (bad), and only trigger a page reload for the latter. However whether to refresh or to reload is only decided at runtime, so the only way I can currently think of is patching the HMR runtime code, something like: // page reload instead of hot component reload
__VUE_HMR_RUNTIME__.reload = () => import.meta.hot.invalidate() Then we'd have HMR for the If Kirby where to change its plugin loading behavior so it doesn't manipulate component definitions, we could have full HMR. Not sure about |
I'm blown away by your approach, Jonas. A serious Vite pro is in the house! Amazing contribution. 👏 Will look into it next week. Looks stunning so far. Great improvements! We'll put that into the core definitely. |
Heh, thank you! 😊 Just committed the change so template refreshes work with HMR and only instance reloads cause a full page reload: jonaskuske@fcf6fde
Documenting outstanding questions and todos here so they can be discussed later: Kirby Core
I've submitted getkirby/kirby#4541 in the Kirby repo to discuss Kirby-related changes there. :) Kirbyup
|
The required changes to Kirby are merged and slated for release in 3.7.4 🚀🚀 I'll be on holiday soon and not sure if I'll manage to write the tests that will complete the PR before that, but either way this feature should be live fairly soon! :) |
Nice! I think the PR is pretty solid and extensively tested by you. Even tho we don't have automated tests yet, I intend to release a beta of the new kirbyup version (2.0) for user's to test and catch up with tests later. Would you be OK with that approach? I'm gonna be on vacation soon as well. Perfect timing. |
Reopening since automatically closed by GitHub. Automated tests are still missing. |
Heh, and the fix for the Vue SFC compiler has landed as well: vuejs/vue#12732 (comment)! 🎉 And yep, definitely okay with that approach! I don't think it's a breaking change though, As far as actual breaking changes go, I was thinking about re-evaluating the need for the thin abstraction over Vite vs. using Vite's own config resolving mechanism (and CLI commands?) directly. Config with custom option could look like: // vite.config.js
export default defineConfig({
resolve: { alias: { insteadOf: 'kirbyup.config.js#alias' }},
plugins: [kirbyup({ customOption: true })]
}) Could simplify the code base and lead to less code to maintain. As for CLI commands, we could either
{
"dev": "kirbyup <src>", // alias dev, serve?
"build": "kirbyup build <src>"
}
But those are just some ideas that came to my mind while working on this PR, also inspired by the changes Svelte Kit went through – might be unnecessary, and even if worth considering, definitely material for a separate issue/PR. |
Currently
kirbyup
only allows building the plugin, either for production or using the--watch
option, with full rebuilds on change.Not sure if it's feasible, but a dev server mode with HMR would be great, especially for Vue components!
The text was updated successfully, but these errors were encountered: