framesurge / perseus

A state-driven web development framework for Rust with full support for server-side rendering and static generation.
https://framesurge.sh/perseus/en-US
MIT License
2.15k stars 89 forks source link

Installation of `wasm-opt` fails #329

Closed shivshankardayal closed 1 month ago

shivshankardayal commented 1 month ago

This issue is reporting a bug in the code of Perseus. Details of the scope will be available in issue labels. The author described their issue as follows:

perseus serve -w fails with wasm-opt installtion.

The steps to reproduce this issue are as follows:


📥 Installing external tools...❌
Error: couldn't extract 'wasm-opt' (do you have the necessary permissions?)

Caused by: failed to iterate over archive Caused by: unexpected end of file



is the output when I try to run `perseus serve -w`

A minimum reproducible example is available at <Use the quickstart example.>.
- Hydration-related: false
- The author is willing to attempt a fix: false 

<details>
<summary>Tribble internal data</summary>

dHJpYmJsZS1yZXBvcnRlZCxDLWJ1ZyxBLWNsaQ==

</details>
arctic-hen7 commented 1 month ago

Hmm, this looks like something that might arise if your internet connection suddenly dropped out? Has this happened more than once?

shivshankardayal commented 1 month ago

Yes, it is repeating. I would have tried like 20 times but it never works.

arctic-hen7 commented 1 month ago

Looks like the latest version of wasm-opt has been incorrectly packaged and the GitHub API doesn't know its version. Working on a fix now. In the meantime, use perseus --wasm-opt-version version_118 <rest-of-command>. You should only need to do this once, after that it should be cached, though if the problem comes up again try that.

arctic-hen7 commented 1 month ago

Fixed this in the latest commit, will wait for tests to pass and then cut a new release ASAP, thanks for opening an issue on this! (Very easy to miss these: Actions caching means tool installations only get tested sometimes I think, and otherwise they stay cached, so only new users spot these!)

For reference: fix was to use tag_name in GitHub's releases API rather than name (which apparently doesn't get set sometimes).