build(web-ui): fix rollup failing

[rbqvq]

Description

Use actions/setup-node instead of MSYS2.

Revert commit fix(build): using @rollup/wasm-node partial changes in #3905

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[ReenigneArcher]

Thank you for the fast resolution on this!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rbqvq]

It looks like fine.

I've manually mounted the NodeJS PATH.

I think we don't need a PATH for npm prefix.

---

CI PASSED at https://github.com/rbqvq/Sunshine/actions/runs/21802858672/job/62901261780

---

I'm going to sleep now.
I think everything's fine.
Please feel free to make any further changes.

[codecov]

Bundle Report

Bundle size has no change ✅

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 15.17%. Comparing base (5bd3a2b) to head (4c638fe).
⚠️ Report is 205 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4687      +/-   ##
==========================================
+ Coverage   15.14%   15.17%   +0.03%     
==========================================
  Files          95       95              
  Lines       19883    19883              
  Branches     9196     9196              
==========================================
+ Hits         3011     3018       +7     
- Misses      15684    15727      +43     
+ Partials     1188     1138      -50     

Flag	Coverage Δ
Archlinux	11.19% <ø> (ø)
FreeBSD-14.3-aarch64	?
FreeBSD-14.3-amd64	13.23% <ø> (ø)
Homebrew-ubuntu-22.04	13.54% <ø> (+0.11%)	⬆️
Linux-AppImage	11.60% <ø> (ø)
Windows-AMD64	13.48% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 16 files with indirect coverage changes

[Yundi339]

Hello, we have encountered the same problem as you, but we are also very lucky that this problem has not been triggered until today.
I don't understand the reason for this rollover, it seems to be introduced because of the version update?
I created PR to slove this problem by COPILOT AI.

AlkaidLab/foundation-sunshine#503

The following is the translation.

When Rollup's module pipeline processes an entry file, it invokes the load hooks sequentially according to the plugin order. The first plugin to return a non-null value dictates the result.

Older versions of Rollup (worked previously):

• The load hook of Vite's internal vite:build-html plugin was ordered before your plugin.
• It intercepted the HTML entry first, extracting the <script> tags and converting them into JS module code.
• Your plugin's load hook was never even called (preempted by Vite's internal plugin).

Newer versions of Rollup (currently throwing errors):

• The execution order or scheduling logic for plugin load hooks has changed.
• Your plugin's load hook is now invoked before Vite's internal HTML plugin.
• It returned raw HTML → Rollup tried to parse it as JS → parseAsync threw an error.

So it's not that "the new version started using it," but rather that the new version changed the invocation order of the load hooks, causing previously bypassed code to suddenly execute. It should never have returned HTML to Rollup in the first place; it was just pure luck that it wasn't being called before.

---

Theoretically, you could add enforce: 'post' to your load hook to order it after Vite's internal plugins. This way, vite:build-html would grab the HTML first, and your load wouldn't be invoked.

But this is not a good fix:

• Relying on plugin execution order is fragile; it might break again in the next Rollup/Vite update.
• Rollup will always parse whatever the load hook returns as a JS module, so returning HTML is fundamentally wrong.
• transformIndexHtml is the official API in Vite for processing HTML, and it fully covers this functionality.

Deleting the load hook is the correct solution—it doesn't rely on order, carries no risk of being accidentally invoked, and has zero negative impact on functionality.

[ReenigneArcher]

This PR only addressed an issue when compiling for debian on arm64. Due to adding "@rollup/wasm-node": "4.57.1" in #3905

It wasn't detected before merge, because we don't compile arm64 docker builds in CI/CD for PRs.

[Yundi339]

Alright Ok.
That's very strange. My question is a low probability trigger. And I just need to click to rebuild, and it works smoothly.

As described by the last comment:

So it's not that "the new version started using it," but rather that the new version changed the invocation order of the load hooks, causing previously bypassed code to suddenly execute. It should never have returned HTML to Rollup in the first place; it was just pure luck that it wasn't being called before.

If you encounter similar problems in future upgrades, you could consider to deal with it like what I did. I hope you will don't encounter it, it's too metaphysical.

[rbqvq]

Thank you for sharing, the problem here is stable trigger, last year's version did not have this problem, the problem has been solved.