vaadin/flow 25.2.8

Vaadin Flow 25.2.8

on GitHub

Changes since 25.2.7

All changes

Breaking changes

• Do not override the minimum frontend package age configured for the package manager (#25173) (CP: 25.2)
  Commit · Pull request

  The minimumFrontendPackageAgeDays parameter defaulted to 1 and was always passed as a command line argument to the package manager. A command line argument takes precedence over every configuration source of npm, pnpm and bun, so a project that had configured min-release-age in its .npmrc (or minimumReleaseAge in pnpm-workspace.yaml) silently got the Vaadin default instead — mvn vaadin:build-frontend and a manually run npm install disagreed on which package versions were allowed to be installed. The parameter is now unset by default (Integer/null rather than int/1): - A value configured on the Vaadin side is used as is, 0 still disables the check. - When nothing is configured, the package manager is asked what it resolves for its own minimum release age setting. If it already has one, no argument is passed and the package manager applies its own configuration; this is logged at info level along with the parameter to set in order to override it. - Only when neither is configured does the one-day default (TaskRunNpmInstall.DEFAULT_MINIMUM_FRONTEND_PACKAGE_AGE_DAYS) apply.

Fixes

• Stabilize Gradle dependency JAR fingerprint (#25388) (CP: 25.2)
  Commit · Pull request

  This is a follow-up to the Gradle build-cache work originally contributed in #24314 and landed in #25001. The standalone scalar provider in VaadinBuildFrontendTask could be evaluated before a project dependency's JAR output existed. A cold build therefore stored vaadinBuildFrontend with a different dependency fingerprint and cache key than subsequent unchanged builds. This derives the same lightweight JAR name-and-size fingerprint from dependencyJarFiles.elements. The provider now retains the file collection's build dependencies while avoiding full content hashing of large external classpaths. The new MiscMultiModuleTest regression proves both sequences with build cache and configuration cache enabled: | Build | Before | After | | --- | --- | --- | | Cold checkout | SUCCESS (key A) | SUCCESS | | Immediate unchanged build | SUCCESS (key B) | UP-TO-DATE | | Fresh relocated checkout | FROM-CACHE (key A) | FROM-CACHE | | Immediate unchanged relocated build | FROM-CACHE (key B) | UP-TO-DATE | Please target this for 25.2 after merging to main.

• Let the Gradle classpath filter be saved in the configuration cache (#25398) (CP: 25.2)
  Commit · Pull request · Issue

  The filter was built by chaining Predicate.and(), or() and negate(). Those return lambdas that live inside the JDK, and Gradle cannot write them into a configuration cache entry. A project with a file dependency such as implementation files('libs/some.jar') keeps the filter in the saved task graph, so the build failed with module java.base does not "opens java.util.function". Replace the chain with a small class that holds only the configured include and exclude patterns, and pass the component filter to Gradle as a named class instead of a lambda.

• Stop passing --scripts-prepend-node-path to npm (#25333) (CP: 25.2)
  Commit · Pull request

  npm 12 removed the long-deprecated --scripts-prepend-node-path config and now rejects unknown CLI flags. As a result every npm install executed by build-frontend fails with: Unknown cli flag whenever a global npm 12 is used. The flag dates back to when Flow ran npm 6, where it made lifecycle scripts run with the same node binary that executes npm-cli.js. Since npm 7, script execution moved to @npmcli/run-script, which builds PATH from the node_modules/.bin folders, the node-gyp bin folder and the inherited PATH — it never looks at this config. Flow requires npm 11.3 or newer, so no supported npm version honours the flag. Dropping it changes nothing except that npm 12 no longer fails.
  Removes the --scripts-prepend-node-path=true flag that FrontendTools#getNpmExecutable appended to every generated npm command line, and updates FrontendToolsTest accordingly (the default npm command is now 4 elements instead of 5).

• Avoid format strings in FrontendUtils.console (#25048) (CP: 25.2)
  Commit · Pull request · Issue

  FrontendUtils.console() passed a caller-controlled format parameter straight into String.format(), which static analysis tools flag as CWE-134 (uncontrolled format string), since the method's contract does not guarantee the argument is a compile-time constant. Additionally, review feedback pointed out that even after removing String.format(), console(String, String) still let the color and message arguments be swapped by mistake, since both were plain Strings.

• Consider about:blank a safe URL (#25317) (CP: 25.2)
  Commit · Pull request · Issue

  The safe URL check is based on the URL scheme, and about is not in the default set of safe schemes. As a side effect, this also blocked legitimate uses of about:blank, such as setting it as the initial source of an IFrame. about:blank is now accepted regardless of the configured safe schemes, since it renders an empty document and cannot run scripts. The comparison is case-insensitive, so About:Blank is treated the same way. Other about: URLs (e.g. about:config, or lookalikes such as about:blank:evil) are unchanged: they are still rejected unless the about scheme is explicitly configured as safe via the safeUrlSchemes init parameter. ### Changes - UrlUtil.isSafeUrl(...) short-circuits to true for a trimmed, case-insensitive match on about:blank, before the scheme-based check. - Javadoc updated on UrlUtil.isSafeUrl, Constants.DEFAULT_URL_SAFE_SCHEMES and InitParameters.URL_SAFE_SCHEMES to document the exception. - New tests in UrlUtilTest covering about:blank (default schemes, mixed case, and a scheme set that excludes about) and the other about: URLs that must stay unsafe.

• Guard filter and sorting callbacks against EmptyDataProvider (#20828) (#25229) (CP: 25.2)
  Commit · Pull request · Issue

  Guards filterOrSortingChanged in AbstractListDataView against instances where the underlying data provider is DataCommunicator.EmptyDataProvider. This prevents NullPointerException when configuring in-memory filters or sort comparators on components before items or an explicit data provider have been initialized.

• Handling of null in HierarchicalDataProvider refreshItem(null, true) (#25248) (CP: 25.2)
  Commit · Pull request · Issue

  Improves support for refreshing the "virtual root" (i.e., the parent of root-level items, represented by null) in hierarchical data providers. Updates the documentation and implementation to clarify that passing null as the item and setting refreshChildren to true is equivalent to a full hierarchy refresh, while passing null with refreshChildren set to false throws exception. The changes also add comprehensive tests to verify this behavior.