Feature flag changes are ignored on client side when default bundle is used

[vursen]

Description of the bug

I downloaded a project from Vaadin Start and enabled the accessibleDisabledButtons feature flag via Copilot. When the server starts, the logs show that the feature flag is activated, but it remains false on the client-side. On the contrary, the dashboardComponent flag appears as true on the client-side even though it's not present in vaadin-featureflags.properties.

Setting vaadin.frontend.hotdeploy=true resolves the issue, which suggests that it's related to the default bundle, which Vaadin start projects use by default.

Expected behavior

It should be possible to activate / deactivate feature flags in Vaadin start projects without setting any additional parameters.

Minimal reproducible example

button-test.zip

Versions

• Vaadin / Flow version: 24.7.0.alpha8
• Java version: 23
• OS version: Mac OS

[mshabarov]

Looks like a bug indeed.
At least Flow should re-build the bundle in that case, as the default bundle has empty feature flags file.
Better to keep the default bundle and handle feature flags as a separate static resource, so that you don't need to rebuild a bundle. On the other hand, if a feature behind a flag needs some extra JS/TS, then Flow should rebuild the bundle.

We can agreed to always rebuild in this case, if the feature flags config is changed comparing to what is in the default/custom bundle.

UPD: to optimise this, we would need an extra flag in each feature flag that tells if a feature has only Java or JS/TS codes. Flow will re-build bundle only if it spots a new feature flag (or removing a feature flag) that corresponds to a feature that has JS/TS.

[mcollovati]

dashboardComponent is active because the dev and prod bundles are built with the feature flag activated, so the value is hard-coded in the generated indexhtml-xxxxx.js

[mcollovati]

To summarize the issues:

• Default bundles need to activate feature flags to make sure Java components are included in class scanning for frontend related annotations
• If feature flags are enabled, the bundles will produce a vaadin-featureflags.js with active flags, resulting in end-user project having features enabled on client side even if the feature is not activated in vaadin-featureflags.properties
• If the end-user project activates a feature that reads the flag value on the client side, but that was not activated during the default bundle build (e.g. accessibleDisabledButtons), a custom bundle is not generated and the client side flag is false.
• Activating a component feature backed by a Java class (e.g. cardComponent) should already trigger a custom build, if the component class adds npm packages and loads JS modules that are not in the default bundle.

Based on internal discussions, at the moment there should be no need for a custom build if a flag is activated: the default bundles should already contain everything is needed. The only requirement is that the client side flag values are updated based on the project settings.

Potential solutions:

• the default bundles should never set activate flags in vaadin-featureflags.js, even if it is built with enabled flags
• modify vaadin-featureflags.js to call a function to updates the flags at runtime, instead of hard-coding them at build time. The function would be injected by IndexHtmlRequestHandler, only if there are any enabled flags. This should allow to use the default bundle with frontend features that read the flag at runtime, like the dashboard component.

The only potential issue would be if a frontend only feature (no Java component class) is not in the default bundle. If such a case is possible, we can potentially add an additional field requiresFrontendBuild to the Feature class and store such features ids in stats.json; a custom build will be triggered is the stats values does not match the current active frontend only features.