Add `trunk` template alongside current template for web

[coderedart]

Closes https://github.com/emilk/eframe_template/issues/44

So, these are the changes roughly.

1. index.html at crate root. for trunk.
2. main.rs for wasm32 target instead of using manual start function in library.
3. .github/pages.yml enables users to see their latest egui app live on gh-pages branch. can change trigger to tags to only deploy for releases.
4. Trunk.toml to make sure that build artefacts (js/wasm) always have the same name for sw.js caching.
5. .gitignore. well, don't want devs to accidentally commit the dist folder which is used for builds by trunk.

[coderedart]

https://github.com/emilk/eframe_template/issues/44

don't know how to link issues with PRs, so just commenting to link the issue.

[coderedart]

it seems eframe_template already has the issue of service worker thingy. when you open https://emilk.github.io/eframe_template/

the whole action to deploy to gh-pages from commit to building the website takes less than a minute. god bless rust-cache action :)

was able to fix this by using relative path instead. https://coderedart.github.io/eframe_template/ -> has zero errors in the log now.

[coderedart]

should be good now. added small tips to README

[coderedart]

@emilk is there anything else that needs to be done?

[emilk]

This is a completely different way of building and deploying the app, and as such, I wonder if it wouldn't make more sense to have this at its own repository (e.g. at https://github.com/coderedart/eframe_trunk_template) to keep each repository less confusing.

[coderedart]

I assumed that after a while the old way of building would be removed and just stick to trunk. Otherwise, as you said, it doesn't make sense to have two ways of doing the same thing.

can always have a new separate template repository if you want to keep this repo clean.

[emilk]

I assumed that after a while the old way of building would be removed and just stick to trunk. Otherwise, as you said, it doesn't make sense to have two ways of doing the same thing.

can always have a new separate template repository if you want to keep this repo clean.

How about this: we remove all the old way of building/deploying web in this PR too. It will then be more clear to me what are the benefits and drawback of trunk vs my bare scripts (and we remove the duplicated index.html and the double instructions, etc). I think it is very likely that I will prefer trunk and merge the PR. However, in the case I prefer the manual (and explicit) scripts, we can take this PR as the basis for a separate template directory!

---

I'd like to publish new builds manually. I have currently only published new WASM binaries when I've updated the eframe/egui version, and I'd like to keep it that way to keep the size of the git repository down (since any large binary file commited to a git repo will forever be part of its history). Though I appreciate having the instructions for how to do automatic deploys in the new .github/pages.yml.

---

PS: I very much appreciate you working on this, as do I appreciate your patience with my slow reviews and inconsistent position 😆

[coderedart]

I'd like to publish new builds manually. I have currently only published new WASM binaries when I've updated the eframe/egui version, and I'd like to keep it that way to

pages.yml's triggers can be changed from on: [push] to the user preferred trigger events. I will use release trigger event for now. only run the workflow when you publish a new release (so, the deployment would always be the latest stable release).

on:
  release:
    types: [published]

keep the size of the git repository down (since any large binary file commited to a git repo will forever be part of its history).

There's a difference though. until now, we committed the wasm binaries to the master branch, while the pages.yml workflow commits to the gh-pages branch. the main issue is committing to master branch, which we can never edit. You can delete gh-pages branch at any moment to clean up all the wasm binaries from the history until this point. also possible to manually push to gh-pages branch if you want to override the latest workflow.

https://stackoverflow.com/questions/2613903/does-deleting-a-branch-in-git-remove-it-from-the-history

If the branch is deleted without being merged into another branch then the commits in that branch (up until the point where the forked from a commit that is still reachable) will cease to be visible. The commits will still be retained in the repository and it is possible to recover them immediately after the delete, but eventually they will be garbage collected.

one more cool thing i just discovered. from the docs of the deploy action

single-commit => This option can be toggled to true if you'd prefer to have a single commit on the deployment branch instead of maintaining the full history. Using this option will also cause any existing history to be wiped from the deployment branch.

if we don't want to bother explicitly cleaning the gh-pages branch, we can use this option to automatically remove previous history before committing the latest deployment with just a single option.

[emilk]

Ah very cool @coderedart, especially with the single-commit option! Then I don't see a problem turning it on for each PR.

[coderedart]

@emilk cleaned it up. one nice thing would be to update the docs/README.md with explanations of what the files inside docs/ directory are useful for.

this is the live build. no errors https://coderedart.github.io/eframe_template/

README could be polished a little bit too i guess.

[coderedart]

I tried my best to rebase, but the pull request still says that there's conflicts :(

[bjorn]

I tried my best to rebase, but the pull request still says that there's conflicts :(

You seem to have rebased their master onto something else, maybe an outdated local master branch in your repository. So now this pull request includes a bunch of duplicated commits.

I tried what a proper rebase would do (like, suppose you have emilk repository added as a remote called upstream, you would checking your master and then type git rebase upstream/master), but there are conflicts that I'm not sure how to resolve in many of the commits. If you can resolve them, it would be one possible way forward.

For the future, I think in this case it would have been much better to perform a merge instead of a rebase. It makes it possible to see what happened in parallel and which conflicts have been resolved. When merging the pull request, it can always still be squashed if there are too many small commits.

[coderedart]

making a new pull request. i will learn git, but not today xD

[emilk]

@coderedart there is a problem. Since https://github.com/emilk/egui/pull/2107 eframe::start_web is async, and I'm not sure how we can get that to work with trunk.

I opened this trunk issue: https://github.com/thedodd/trunk/issues/466

[nuzzles]

^ Trunk should be considered a binary, not a library. You will not call trunk. It runs independently of your code, and hence, should not pose any restrictions on how your code or application is structured.

[emilk]

There's a work-around in https://github.com/emilk/eframe_template/pull/83