fix: install the Aura theme in every mode

[totally-not-ai]

Summary

The @vaadin/aura entry in versions.json was marked for the Lit mode, so it was skipped in React applications. Aura is a theme, not a Lit web component, so this change removes the mode and makes it install and pin in every mode.

Details

The mode property tells Flow which packages a React application does not install on its own. Every package marked lit is a dependency of @vaadin/react-components, so React applications still get it and only its version is pinned through the npm overrides.

The Aura entry was added later and copied the mode: "lit" of the entries around it. But @vaadin/react-components does not depend on @vaadin/aura, so nothing pulled the theme into a React application. Dropping the mode from that one entry fixes it.

The branch also contains a commit that removed the Lit mode from four other packages, plus a revert of it. Those four entries are marked correctly: they are dependencies of @vaadin/react-components, so pinning them without installing them separately is exactly what the mode means. The net change is the single line for Aura.

[github-actions]

Dependencies Report

• 🚫 Vulnerabilities:

  • Vulnerabilities in: pkg:maven/io.opentelemetry/opentelemetry-api@1.65.0 [CVE-2026-54285] (owasp)
    · cpe:2.3:a:opentelemetry:opentelemetry::::::node.js::*
  • Vulnerabilities in: pkg:maven/org.springframework.security/spring-security-oauth2-core@7.0.6 [CVE-2026-59270, CVE-2026-47841, CVE-2026-47842, CVE-2026-47877, CVE-2026-59276] (owasp)
    · cpe:2.3:a:vmware:spring_security::::::::
  • Vulnerabilities in: pkg:maven/org.springframework.security/spring-security-web@7.0.6 [CVE-2026-59270, CVE-2026-47841, CVE-2026-47842, CVE-2026-47877, CVE-2026-59276] (owasp)
    · cpe:2.3:a:vmware:spring_security::::::::

• 🟠 Known Vulnerabilities:

  • Vulnerabilities in: pkg:maven/me.friwi/jcef-api@jcef-ca49ada%2Bcef-135.0.20%2Bge7de5c3%2Bchromium-135.0.7049.85 [CVE-2024-21639, CVE-2024-21640, CVE-2024-9410] (owasp)
    👌 Wait for the update from the jcefmaven community. Meanwhile the swing-kit is supposed to be used with fixed websites and not to browse the internet, we have a check for that, so the only possible attacker would be the same person that created the swing application, aka our customer devs. so this vulnerability is not classified by us as critical issue
    · cpe:2.3:a:chromiumembedded:chromium_embedded_framework::::::::
    · cpe:2.3:a:ada:ada::::::::
  • Vulnerabilities in: pkg:maven/org.jetbrains.kotlin/kotlin-reflect@2.4.0 [CVE-2026-53914] (owasp)
    👌 FP: the report only affects org.jetbrains.kotlin:kotlin-gradle-plugin, the CPE for the kotlin product matches any kotlin artifact. We ship kotlin-reflect as a transitive dependency of the hilla typescript generator, not the gradle plugin.
    · cpe:2.3:a:jetbrains:kotlin::::::::
  • Vulnerabilities in: pkg:maven/com.vaadin/vaadin-swing-kit-flow@3.0.1 [CVE-2021-33604] (owasp)
    👌 false report: this CVE is targeting Vaadin version prior 20, swing-kit-flow is using vaadin 24+ version, the related issue has been fixed.
    · cpe:2.3:a:vaadin:flow-server::::::::
    · cpe:2.3:a:vaadin:vaadin::::::::

• 📔 No Core License Issues

• 📔 No License Issues

• 🟠 Changes in 25.4-SNAPSHOT since V25.3.0-beta2

  • 131 packages modified (10 external, 121 vaadin)
  • 517 packages same (396 external, 121 vaadin)

[Click for more Details]

[Artur-]

Shouldn't "mode": "lit" be removed from all the packages not listed in exclusions for react-components, as they are always installed anyway right now?

[totally-not-ai]

@Artur- Yes, and done in b00f243. The mode is now gone from @vaadin/a11y-base, @vaadin/field-base, @vaadin/vaadin-lumo-styles and @vaadin/vaadin-themable-mixin as well.

Those were exactly the entries marked for the Lit mode that the React components do not exclude, so a React application installs them today anyway and the mode said the opposite of what happens. @vaadin/aura was the same case, with the difference that the React components do not even bring it in their dependency tree.

After both commits every remaining mode: lit entry — 67 of them — is excluded by @vaadin/react-components or @vaadin/react-components-pro, which is the invariant the mode was added under: a package marked for the Lit mode is one the React components bring instead.

scripts/validateVersions.js passes. The SBOM check on this pull request is unrelated: it reports new CVEs in spring-security-oauth2-core, spring-security-web and opentelemetry-api, and it is failing the same way on every branch today, including the version bump branches.

[totally-not-ai]

@Artur- I was wrong to agree with this, and de9fe87 reverts it. Only the @vaadin/aura entry changes in this pull request again.

The Lit mode does not mean the package is left out of a React application altogether. Flow writes the npm overrides from every entry of the versions files, whichever mode it declares (PinnedNpmVersions.getAllDependencies(), used by TaskUpdatePackages.collectPinnedNpmVersions()), and the exclusions only apply to the dependencies of package.json. So the mode says "do not install this separately, the React components already depend on it, but keep the version locked".

That is exactly right for @vaadin/a11y-base, @vaadin/field-base, @vaadin/vaadin-lumo-styles and @vaadin/vaadin-themable-mixin: @vaadin/react-components depends on all four, so a React application gets them through it at the locked version.

They are not in the exclusions array of the React components, which is why they look installed separately today, but that is a gap in the array rather than a decision — and vaadin/flow#25623 closes it by taking the exclusion from the mode instead of the array.

@vaadin/aura stays the one real fix: the React components do not depend on it, so nothing installs it in a React application, and the mode has to go.

[Artur-]

Let's get back to this if needed