[v2, dev] Use custom schemes for in-app dev mode

[stffabi]

This fixes some long-standing inconsistencies between dev mode builds and production builds but is a breaking change. Dev mode uses custom scheme for Vite versions >= 3.0.0 and for older it still behaves in the old way.

Relates to

• Cookies cannot be set on macos #2590
• [linux] Weird behaviour with HTTPS with wails build command #2523
• [linux] Can play audio in wails dev but not in wails build #2090
• error Embed twitch #2026
• [v2, linux] custom AssetsHandler ignores HTML video's src on production #1568

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	182bf09
Status:	✅  Deploy successful!
Preview URL:	https://2f489165.wails.pages.dev
Branch Preview URL:	https://feature-dev-mode-custom-sche.wails.pages.dev

View logs

[leaanthony]

This is great! Perhaps we should link the tickets we believe will be fixed by this?

[leaanthony]

Do you think using the old URL for Vite < 3 would be reasonable? It'd mean it wouldn't break compatibility but we could spam the terminal with all the benefits of upgrading to v3?

[stffabi]

This is great! Perhaps we should link the tickets we believe will be fixed by this?

Yeah that's a good idea.

[stffabi]

Do you think using the old URL for Vite < 3 would be reasonable? It'd mean it wouldn't break compatibility but we could spam the terminal with all the benefits of upgrading to v3?

This would need some more if-cases so theoretically it's feasible. I'm not sure if that would give a better experience for the developer. In the current version of the PR it's clear that when upgrading to the next release there's a breaking change and the user needs to update vite. Otherwise it would still work as in older releases and would then introduce the breaking change just by the means of updating vite to a newer version.
As an end user of Wails I would personally prefer to have specific version that introduces the breaking change, and not by just updating Vite.
Another solution would to add a config value, but I don't know if that's really better. Especially we are only fixing an inconsistency in between dev/prod mode and all people that didn't encounter such an inconsistency by using a feature in dev that doesn't exist in prod should not be affected by this breaking change.

[stffabi]

I've update the initial comment to list issues that I've found relating to such inconsistencies.

[stffabi]

@leaanthony I've marked the PR ready for review, let me know how you would like to proceed with it.

[leaanthony]

I think if it's not a huge problem, we should use the default behaviour if vite < 3 but issue a large warning about it. I think this will be a small minority because v3 has been standard in v2 for a while, however if their projects just fail to work then that would be a bad experience. There may be some weird reason they can't upgrade or perhaps they are using a remote template. I'm happy to do that work if you're done with it 😅

[stffabi]

Ok, will do that. Unfortunately we still had some old vite v2 in our templates. 😞

[stffabi]

@leaanthony PR has been updated

[leaanthony]

I remember from the first commit (can't get to it after force push) that ViteServerURLChan was used. According to my IDE, it looks like it's only sent a value but the value isn't read. Am I reading this wrong?

[stffabi]

I remember from the first commit (can't get to it after force push) that ViteServerURLChan was used. According to my IDE, it looks like it's only sent a value but the value isn't read. Am I reading this wrong?

Didn't change anything there, it's still being read here v2/cmd/wails/internal/dev/dev.go line 235

[leaanthony]

That is so weird! I wonder if it was a gui issue with a small window as I can see it just fine on desktop... 🤯

[leaanthony]

Thanks so much for adding in the legacy support 🙏 This feature should help a lot.

[stffabi]

You're welcome. I hope this will get us rid of all those "working in development, not working in production" tickets.