Fail vite build on rolldown warnings via NODE_ENV=test

[silverwind]

Fail the vite build on any rolldown warnings when NODE_ENV=test is set. This gate is set on the CI make frontend steps (compliance and e2e workflows) and on the local make test-e2e target, so warnings fail the build both in CI and when running e2e tests locally. Regular make frontend / production builds are unaffected.

Example output:

[plugin test-warning-injector] first synthetic warning
[plugin test-warning-injector] second synthetic warning
transforming...✗ Build failed in 14ms
error during build:
Build failed with 1 error:

[plugin fail-on-warnings]
Error: 2 warnings present
    at PluginContextImpl.buildEnd (vite.config.ts:50:13)
    ...

---

This PR was written with the help of Claude Opus 4.7

[silverwind]

@wolfbeast fyi, this will be for v1.27. Outdated, ignore. We wanted to bump to es2022, but found a way to avoid it.

[wxiaoguang]

Actually, I am not sure whether it really needs es2022

This await import("../../../css/swagger.css"); is only for loading CSS files, and the JS is executed in type=module. So I don't know whether the "await" is really a problem, or just a wrong warning from Vite

---

OK, it seems that it becomes standard in es2022, while some browsers supported it ahead.

Maybe it's better to find a way to avoid such top-level await and make the CSS importing work (if possible)

Details

[wxiaoguang]

The top-level await import is also caused by incorrect Vite manifest parser, it makes the CSS importing very messy.

[wxiaoguang]

No need to use es2022

-> Fix top-level await #37272

[silverwind]

The warn-as-error here is still useful.

[silverwind]

PR is now only warn-as-err.

[silverwind]

This await import("../../../css/swagger.css"); is only for loading CSS files, and the JS is executed in type=module. So I don't know whether the "await" is really a problem, or just a wrong warning from Vite

Depends on what vite internally does when it sees TLA with CSS. I think it's likely that some form of TLA persists in the output code, and if that is the case, rolldown is right to warn about it.

[wxiaoguang]

        // FIXME: if it throws error here, the real Vite compilation error will be hidden, and makes the debug very difficult
        // Need to find a correct way to handle errors.
        console.error(`Failed to update manifest for ${sourceFileName}`);

Can this also have a proper fix?

Throwing errors in closeBundle will hide the real compilation errors: you can try to introduce some compilation error (e.g.: syntax error in index.ts), make frontend, then manifest.json won't be generated, then readFileSync throws an error, and you are not able to see the real syntax error.

[silverwind]

While that case should probably be improved, it's not related to the change here, which is self-contained.

[silverwind]

The approach here has one issue, it will only log the first warning and exit. I think a real warn-as-err can only be implemented in vite itself.

[wxiaoguang]

While that case should probably be improved, it's not related to the change here, which is self-contained.

Yes, it's not related to the "rolldown warning", but it is still related to the CI build.

For example: if the manifest.json generation goes wrong, the try-cache in closeBundle will cause more serious problems: it just ignores the exception and reports it succeeds.

I think they have the same point: vite build should report warnings/errors to stop the CI build.

[silverwind]

I opened vitejs/vite#22263, I think a proper implementation of this can only come from vite.

[wolfbeast]

@wolfbeast fyi, this will be for v1.27. Outdated, ignore. We wanted to bump to es2022, but found a way to avoid it.

Since I was pinged/subscribed here anyway, we've made more progress on ES standards compliance and some of the DOM issues we ran into before, so for the record, UXP now supports:

• top-level await in modules
• everything from ES2016 through ES2023 with the singular exception that finalizationRegistry (part of the strongly discouraged ES2021 WeakRef proposal) isn't supported.
• ES2024 object.groupBy()
• Form SubmitEvent API. You should be able to remove the workaround that was put in place for us in Gitea.
• url.CanParse()

Maybe a casual read-through of our release notes can be useful for the dev team here, to know what's changed on our end.

[silverwind]

we've made more progress on ES standards compliance

Thanks for the detailed info. With that confirmation, we could move to es2023 but as long as no new feature needs it, we ought to keep it at es2020. I will make a PR to remove the SubmitEvent polyfill for v1.27.

Maybe a casual read-through of our release notes can be useful for the dev team here, to know what's changed on our end.

Yes, that changelog is my primary resource for UXP compat issues. I still hope mdn/browser-compat-data#17690 will eventually be fixed.

[Copilot]

Pull request overview

Adds a CI-only Rolldown plugin to make Vite builds fail when Rolldown warnings are emitted, preventing warnings from being silently ignored in CI.

Changes:

• Introduces a failOnWarningsPlugin() Rolldown plugin that counts warning-level logs and fails the build at buildEnd.
• Wires the plugin into commonRolldownOptions only when env.CI is set.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[silverwind]

One more idea came to mind: fail it when in dev or test instead of only on CI. Not sure if it's possible, but likely.

[silverwind]

Now using NODE_ENV=test to gate the plugin, will fail locally during e2e tests and on ci during the frontend build. vite also has a --mode test, but that is already occupied by vitest so I think this is the next-best solution to notice warnings locally during e2e tests.

Reverted, too complicated, and not backporting.