Skip to content

Conversation

@Lonwyr
Copy link
Contributor

@Lonwyr Lonwyr commented Aug 22, 2025

Add 'flexBundle'-flag in the manifest via generateFlexChangeBundle task.

Currently, the runtime checks the existence of the flexibility-bundle.json depending on the preloading of the bundle itself. This preload of all component sources may not be in time for annotation changes, which are part of the preprocessing and require a more explicit hint, if the bundle is present and should be requested. This commit adds this hint with a flag in the "sap.ui5" subsection in the manifest.

JIRA: CPOUI5FOUNDATION-1125

…FlexChangesBundle task

Currently, the runtime checks the existence of the flexibility-bundle.json depending on the preloading of the bundle itself.
This preload of all component sources may not be in time for annotation changes, which are part of the preprocessing and require a more explicit hint, if the bundle is present and should be requested.
This commit adds this hint with a flag in the "sap.ui5" subsection in the manifest.
@Lonwyr Lonwyr marked this pull request as draft August 22, 2025 11:06
@Lonwyr
Copy link
Contributor Author

Lonwyr commented Aug 22, 2025

The name of the flag is currently on review within the manifest-schema and as soon as the final go is given, the draft flag will be removed. All other code is "ready for review".

@matz3
Copy link
Member

matz3 commented Aug 22, 2025

If I understand this correctly, this requires a new property in the manifest schema. Doesn't this also mean, that the property can only be added when the existing manifest.json uses an _version that supports this new property? Otherwise the manifest can't be validated against the schema.

@MatthiasSchmalz
Copy link
Member

If I understand this correctly, this requires a new property in the manifest schema. Doesn't this also mean, that the property can only be added when the existing manifest.json uses an _version that supports this new property? Otherwise the manifest can't be validated against the schema.

This flag will be set by the builder. It must not be set by the developer directly, so it is not relevant for linting

@Lonwyr
Copy link
Contributor Author

Lonwyr commented Aug 27, 2025

If I understand this correctly, this requires a new property in the manifest schema. Doesn't this also mean, that the property can only be added when the existing manifest.json uses an _version that supports this new property? Otherwise the manifest can't be validated against the schema.

This flag will be set by the builder. It must not be set by the developer directly, so it is not relevant for linting

It will be set by the builder directly and not set by the developer. It is not a decision by the developer, but a fact if the developer created entities part of the flexibility-bundle.json which is then build and present in the app and its -preload.

@Lonwyr
Copy link
Contributor Author

Lonwyr commented Sep 10, 2025

The manifest schema change is approved and merged.

@matz: as @MatthiasSchmalz mentions, it is related to the manfiest-version, but having the flag does not hurt and potentially even helps, if present. Thus, I prefer keeping it independent of the version.

@Lonwyr Lonwyr marked this pull request as ready for review September 11, 2025 08:20
@flovogt flovogt requested a review from a team September 22, 2025 18:13
@flovogt flovogt self-assigned this Sep 22, 2025
@flovogt
Copy link
Member

flovogt commented Sep 22, 2025

Thanks a lot for your contribution. We will have another round of review in the team and will merge the PR afterwards.

@d3xter666
Copy link
Contributor

Hi @Lonwyr ,

I have cherry-picked your commits and did some adjustments here: #1164

Cheers

@flovogt
Copy link
Member

flovogt commented Oct 15, 2025

Closing this PR. Superseded by #1164.

@flovogt flovogt closed this Oct 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants