docs: add caching to cross-platform example workflow

[webbertakken]

Add caching to the default workflow.

This is a pretty standard step I'd say that many people (and machines) would benefit from.

Before:

After (from second run after implementing it)

See it in action: webbertakken/map-editor-2d#17

Changes are reflected here: https://deploy-preview-954--tauri.netlify.app/v1/guides/building/cross-platform#example-workflow

[github-actions]

🚀 Deployed on https://dev954--tauri.netlify.app

[FabianLars]

This was discussed multiple times already, and i feel like it was always me who blocked it 😂
The problem i have with this is that it only offers value if it runs at least once a week, which i think should be rather rare. If it's less than once a week this will actually increase CI times.
So while i think this is nice for workflows that run tests, or for nightly releases, i don't think there is much value for the actual release workflow.

So imo this would be better suited for the testing example in the tauri-action repo or a new testing-in-CI guide (the latter probably doesn't offer much value idk)

What do you think?

[webbertakken]

Personally I prefer to help newer developers in a way that they can just delete the steps they don't want, instead of puzzle (during a learning curve) to get the best setup.

In my opinion complete examples are useful. The official docs for a tool usually show close to "the best" approach, and is fine-tuned by the community if any mistakes are made. For that reason alone I think it's worth adding it.

Besides that I think it's globally encouraged to iterate quickly and "release often". Many people might release a few times one week, and not at all for a few weeks after that. (often the case for my projects, 1 minor release and quickly after one or two patch releases when people notice bugs).

I mean adding it would mean:

Upsides:

• The rest of the week your releases are 80% faster
• Which makes it easier to test changes to your workflow as well
• Much easier to understand a complete production grade workflow for beginners

Downsides:

• Slightly harder to understand the example at first sight
• 10 seconds (?) slower on cache miss
• Maintenance of the added docs

That said. It's completely up to you. I'm just trying to be helpful towards newer devs who struggle with this kind of thing 😆

[FabianLars]

Sooo, i still don't agree (basing this on what i've seen in the community btw), but honestly i'm getting a bit tired of people asking for a cache (and then not using it in the end), so let's get it in anyway :D (interpret this as listening to the community :P )

I added 2 suggestions i'd like to hear your thoughts on.
Last thing that's not really related to this PR but i think we should add a comment or something to the yarn && yarn build step (or change the default), because the default template has yarn build configured as the beforeBuildCommand too so we're effectively building the frontend twice which depending on the frontend can add quite some time.

[webbertakken]

Haha, perhaps it'll be good, or perhaps you'll have people asking to remove it next.
I suppose merging it is a great way to find out. 🙂

Thanks for your consideration.

[webbertakken]

@FabianLars are you merging this?

[FabianLars]

That's the plan yes. I did some more testing a few days (or weeks?) ago, trying to make it easier to configure and not yarn specific, but weren't able to finish it up yet (had to focus on other stuff etc).

At this point i am not sure if we should even include a default (frontend) caching solution in the snippet but instead of a section explain possible solutions, reasons;

First of all, we have to have the target audience in mind, most never worked with CI before, some of them not even with frontend stuff - this is btw the reason why i proposed the setup-node cache. Most people just use this action because there is no cross-compilation!

As i said above, i tried to make it easier or more general, for example by using npm, yarn and pnpm lockfiles for the cache key and potentially using setup-node for the global cache (so that we don't have to get&cache the path ourselves).
This worked alright except for pnpm which fails on Windows with this approach (invalid symlinks or something i guess).

Speaking of pnpm, not caching node_modules (but the global cache) is usually faster, or just as fast, because it installs the dependencies faster than the cache action can download, decompress and copy the node_modules folder.

Then we also have the issue of npm ci (which people should probably use?) where caching node_modules/ is harmful because it gets deleted before installation automatically.

Please let me know if you have any ideas. If not i'd tend to go for the setup-node cache for now and figure out a good approach later after cleaning up the docs some more.

[webbertakken]

I see. Good effort!

As for my input, I love creating a quick PR to open source projects and try and contribute a small iteration, but I do not have the capacity to stay deeply in context for each PR. Mostly I was just asking to see whether I should keep my fork around or not.

I have no strong preference towards one either solution. Please do feel free to apply your suggestion.

[FabianLars]

Okay let's make it quick and easy then, i'll use setup-node and re-iterate as soon as i can.

Thank you for your contribution and sorry for the super long delay!

[webbertakken]

You're welcome! And thank you so much for your effort as well as maintaining this package in general.