UI5 Web Components v2.27.0-rc.2: Build Fix & Theme Caching Worth Testing

Giulia Ferrari breaks down what you need to know

If your UI5 Web Components build has suddenly been failing with a cryptic TypeScript error, or if your application’s theme lookups feel heavier than they should, this release candidate deserves your attention. v2.27.0-rc.2 addresses two very concrete pain points that have been lurking in the ecosystem. But it’s still a release candidate—so proceed with a healthy dose of caution.

The Real Story

Behind the version number are two changes that matter more than the typical maintenance release. First, the team fixed a stale @ts-expect-error directive in the HTMLSanitizer code. For anyone who has upgraded their TypeScript version or dependency chain recently, you may have encountered the infamous Unused '@ts-expect-error' directive error. It happens when the underlying type issue that the directive was suppressing gets fixed upstream, but the directive itself remains. The compiler then treats it as an error, breaking your build. v2.27.0-rc.2 removes that stale directive, unblocking builds that have been stuck in CI.

Second, the framework now caches base theme values to reduce repeated getComputedStyle() calls. For applications that frequently query theme variables—think dynamic styling, theme switching, or custom components that read CSS custom properties on every render—this is a meaningful performance optimization. Every getComputedStyle() call forces the browser to synchronously recalculate style and layout, which is not cheap. Caching the base theme values avoids that overhead and can reduce main-thread jank.

What This Means for You

If you are a developer and your build has been failing due to the @ts-expect-error issue, this RC is immediately testable. You can try it in a sandbox branch by pinning your UI5 Web Components dependency to v2.27.0-rc.2. There’s no code change required on your side; the fix is internal. However, remember it’s a release candidate, not a stable version.

If you are an architect, the base theme caching change is interesting but warrants scrutiny. The performance gain depends heavily on how often your app queries theme values. In my experience, large enterprise dashboards and highly dynamic UIs can see a noticeable drop in style recalculations, especially on lower-end devices. But caching introduces a new failure mode: stale values if the theme changes at runtime. If your application supports runtime theme switching via JavaScript (not just a full page reload), you need to verify that the cache invalidates correctly. The release notes don’t spell out every edge case, so visual regression testing is non-negotiable.

For QA teams, the caching change means you must run a focused regression pass on themed components. Custom themes, especially those overriding SAP’s CSS variables, are the most likely to break. A subtle issue—like a button that doesn’t update its color after a theme toggle—is exactly the kind of bug that slips through if you only test the default theme.

Action Items

• Test the RC if you’re build-blocked. If your CI is red because of the @ts-expect-error error, create a sandbox branch and update your UI5 Web Components to v2.27.0-rc.2. Run your full build and unit tests. If it passes, you’ve confirmed the fix.

• Profile style recalculations before and after. Use Chrome DevTools’ Performance

References

• SAP/ui5-webcomponents: v2.27.0-rc.2- SAP AI Core Documentation
• SAP Community Hub

References

• SAP AI Core Documentation
• SAP Community Hub
• SAP/ui5-webcomponents: v2.27.0-rc.2