build(web-ui): fix rollup failing by rbqvq · Pull Request #4687 · LizardByte/Sunshine

rbqvq · 2026-02-08T15:39:40Z

Description

Use actions/setup-node instead of MSYS2.

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

Type of Change

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!

Use actions/setup-node instead of MSYS2. Revert commit `fix(build): using @rollup/wasm-node` partial changes in #3905 Signed-off-by: Coia Prant <coiaprant@gmail.com>

sonarqubecloud · 2026-02-08T18:11:06Z

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 · 2026-02-08T18:14:22Z

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 · 2026-02-08T18:43:41Z

Bundle Report

Bundle size has no change ✅

codecov · 2026-02-08T20:30:06Z

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 · 2026-02-18T03:22:55Z

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 · 2026-02-18T04:32:07Z

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 · 2026-02-18T10:35:44Z

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 · 2026-02-18T10:42:59Z

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

rbqvq · 2026-02-08T15:39:40Z

Description

Use actions/setup-node instead of MSYS2.

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

Type of Change

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!

Use actions/setup-node instead of MSYS2. Revert commit `fix(build): using @rollup/wasm-node` partial changes in #3905 Signed-off-by: Coia Prant <coiaprant@gmail.com>

sonarqubecloud · 2026-02-08T18:11:06Z

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 · 2026-02-08T18:14:22Z

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 · 2026-02-08T18:43:41Z

Bundle Report

Bundle size has no change ✅

codecov · 2026-02-08T20:30:06Z

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 · 2026-02-18T03:22:55Z

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 · 2026-02-18T04:32:07Z

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 · 2026-02-18T10:35:44Z

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 · 2026-02-18T10:42:59Z

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

rbqvq · 2026-02-08T15:39:40Z

Description

Use actions/setup-node instead of MSYS2.

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

Type of Change

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!

Use actions/setup-node instead of MSYS2. Revert commit `fix(build): using @rollup/wasm-node` partial changes in #3905 Signed-off-by: Coia Prant <coiaprant@gmail.com>

sonarqubecloud · 2026-02-08T18:11:06Z

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 · 2026-02-08T18:14:22Z

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 · 2026-02-08T18:43:41Z

Bundle Report

Bundle size has no change ✅

codecov · 2026-02-08T20:30:06Z

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 · 2026-02-18T03:22:55Z

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 · 2026-02-18T04:32:07Z

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 · 2026-02-18T10:35:44Z

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 · 2026-02-18T10:42:59Z

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

rbqvq · 2026-02-08T15:39:40Z

Description

Use actions/setup-node instead of MSYS2.

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

Type of Change

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!

Use actions/setup-node instead of MSYS2. Revert commit `fix(build): using @rollup/wasm-node` partial changes in #3905 Signed-off-by: Coia Prant <coiaprant@gmail.com>

sonarqubecloud · 2026-02-08T18:11:06Z

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 · 2026-02-08T18:14:22Z

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 · 2026-02-08T18:43:41Z

Bundle Report

Bundle size has no change ✅

codecov · 2026-02-08T20:30:06Z

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 · 2026-02-18T03:22:55Z

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 · 2026-02-18T04:32:07Z

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 · 2026-02-18T10:35:44Z

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 · 2026-02-18T10:42:59Z

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

rbqvq · 2026-02-08T15:39:40Z

Description

Use actions/setup-node instead of MSYS2.

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

Type of Change

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!

Use actions/setup-node instead of MSYS2. Revert commit `fix(build): using @rollup/wasm-node` partial changes in #3905 Signed-off-by: Coia Prant <coiaprant@gmail.com>

sonarqubecloud · 2026-02-08T18:11:06Z

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 · 2026-02-08T18:14:22Z

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 · 2026-02-08T18:43:41Z

Bundle Report

Bundle size has no change ✅

codecov · 2026-02-08T20:30:06Z

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 · 2026-02-18T03:22:55Z

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 · 2026-02-18T04:32:07Z

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 · 2026-02-18T10:35:44Z

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 · 2026-02-18T10:42:59Z

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

rbqvq · 2026-02-08T15:39:40Z

Description

Use actions/setup-node instead of MSYS2.

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

Type of Change

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!

Use actions/setup-node instead of MSYS2. Revert commit `fix(build): using @rollup/wasm-node` partial changes in #3905 Signed-off-by: Coia Prant <coiaprant@gmail.com>

sonarqubecloud · 2026-02-08T18:11:06Z

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 · 2026-02-08T18:14:22Z

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 · 2026-02-08T18:43:41Z

Bundle Report

Bundle size has no change ✅

codecov · 2026-02-08T20:30:06Z

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 · 2026-02-18T03:22:55Z

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 · 2026-02-18T04:32:07Z

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 · 2026-02-18T10:35:44Z

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 · 2026-02-18T10:42:59Z

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

rbqvq · 2026-02-08T15:39:40Z

Description

Use actions/setup-node instead of MSYS2.

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

Type of Change

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!

Use actions/setup-node instead of MSYS2. Revert commit `fix(build): using @rollup/wasm-node` partial changes in #3905 Signed-off-by: Coia Prant <coiaprant@gmail.com>

sonarqubecloud · 2026-02-08T18:11:06Z

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 · 2026-02-08T18:14:22Z

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 · 2026-02-08T18:43:41Z

Bundle Report

Bundle size has no change ✅

codecov · 2026-02-08T20:30:06Z

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 · 2026-02-18T03:22:55Z

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 · 2026-02-18T04:32:07Z

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 · 2026-02-18T10:35:44Z

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 · 2026-02-18T10:42:59Z

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

rbqvq · 2026-02-08T15:39:40Z

Description

Use actions/setup-node instead of MSYS2.

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

Type of Change

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!

Use actions/setup-node instead of MSYS2. Revert commit `fix(build): using @rollup/wasm-node` partial changes in #3905 Signed-off-by: Coia Prant <coiaprant@gmail.com>

sonarqubecloud · 2026-02-08T18:11:06Z

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 · 2026-02-08T18:14:22Z

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 · 2026-02-08T18:43:41Z

Bundle Report

Bundle size has no change ✅

codecov · 2026-02-08T20:30:06Z

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 · 2026-02-18T03:22:55Z

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 · 2026-02-18T04:32:07Z

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 · 2026-02-18T10:35:44Z

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 · 2026-02-18T10:42:59Z

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

rbqvq mentioned this pull request Feb 8, 2026
build(windows): add arm64 support #3905
Merged
10 tasks

ReenigneArcher reviewed Feb 8, 2026
View reviewed changes

Comment thread.github/workflows/ci-windows.yml Outdated
Comment thread.github/workflows/ci-windows.yml
Comment thread.github/workflows/ci-windows.yml Outdated

ReenigneArcher mentioned this pull request Feb 8, 2026
[request] output paths actions/setup-node#1122
Open

fix(build): fix rollup failing
4c638fe
Use actions/setup-node instead of MSYS2. Revert commit `fix(build): using @rollup/wasm-node` partial changes in #3905 Signed-off-by: Coia Prant <coiaprant@gmail.com>

rbqvq requested a review from ReenigneArcher February 8, 2026 18:31

ReenigneArcher changed the title ~~fix(build): fix rollup failing~~build(web-ui): fix rollup failingFeb 8, 2026

ReenigneArcher added this to the windows-arm milestone Feb 8, 2026

ReenigneArcher approved these changes Feb 8, 2026
View reviewed changes

ReenigneArcher merged commit 8aed1a8 into LizardByte:masterFeb 8, 2026
77 of 83 checks passed