Vaadin Flow 25.3.0-alpha5

Changes since 25.3.0-alpha4

All changes

Fixes

• Expose production frontend bundle on the runtime classpath
  Commit · Pull request · Issue

  The production frontend bundle produced by vaadinBuildFrontend was written to a task-owned directory (build/vaadin-build-frontend) that is not on the runtime classpath. It was copied into application archives with an explicit Jar.from(...), but never exposed on the classpath, so an application served in place from the source set output - gretty during a production build, or an IDE/bootRun launch - no longer found the bundle or the production flow-build-info.json and started in development mode, failing with "There is no dev-bundle ... found". Register the bundle directory as an extra output of the main source set (output.dir(builtBy: vaadinBuildFrontend)), restoring the behavior that shipped through 25.1.x: the bundle is on the runtime classpath for in-place runs and is packaged into every application archive through standard source-set-output handling (WEB-INF/classes for WAR, the archive root for plain and Spring Boot executable jars). The task-owned output directory introduced in #25001 is kept, so the build-cache fix (#24012) is preserved. Because output.dir makes the classes lifecycle task depend on vaadinBuildFrontend, this task no longer depends on classes (which would form a cycle). Ordering after compilation is established by its @Classpath classesDirs input, and ordering after resource processing by an explicit dependency on the processResources task. The per-archive Jar.from(...) copying, the Spring Boot BOOT-INF/classes special-casing, and the includeArchiveTasks/excludeArchiveTasks options (all introduced in 25.3.0-alpha4, never in a stable release) are no longer needed and are removed. The Spring Boot bundle location returns to the archive root, matching 25.1.x.

• Write pnpm overrides to pnpm-workspace.yaml
  Commit · Pull request

  Recent pnpm versions no longer read the "pnpm" field from package.json, so the dependency overrides Flow generated there were silently ignored and pnpm logged a warning about it. As a result Flow could no longer lock transitive dependencies to the platform versions when using pnpm. Flow now writes these overrides to pnpm-workspace.yaml, the location pnpm actually reads, and moves any overrides left in package.json over to it. Existing user content in pnpm-workspace.yaml is preserved, and a Flow-generated file is cleaned up like other generated frontend files.