CEXT-6338: spec for Admin UI v2 web-src scaffold

[iivvaannxx]

Description

Adds the spec for CEXT-6338: automatic scaffolding of web-src/ for commerce/backend-ui/2 view extensions.

Related Issue

CEXT-6338

Motivation and Context

The generate all command already emits a view operation into ext.config.yaml when the app config requires iframe-based UI (mass actions, menu, view buttons), but without a corresponding web-src/ directory that operation is completely non-functional. Developers currently copy files manually from the Commerce samples repository.

How Has This Been Tested?

Spec only — no code changes.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have read the DEVELOPMENT document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4a9a110

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[obarcelonap]

I believe this approach effectively constrains the SPA to be implemented exclusively with React. While I’m comfortable with this direction, it would be good to explicitly document it as a drawback.

[iivvaannxx]

I believe this approach effectively constrains the SPA to be implemented exclusively with React. While I’m comfortable with this direction, it would be good to explicitly document it as a drawback.

@obarcelonap Not necessarily, codegen can always be extended to support other languages, and @adobe/aio-commerce-lib-admin-ui/web can be turned into @adobe/aio-commerce-lib-admin-ui/web/react with room for future frameworks, such as @adobe/aio-commerce-lib-admin-ui/web/vue (although I don't see that happening in the near future, TBH, as much as I would like to implement the flexibility).

As a side note, does aio app build even support any other library besides React?

[obarcelonap]

I believe this approach effectively constrains the SPA to be implemented exclusively with React. While I’m comfortable with this direction, it would be good to explicitly document it as a drawback.

@obarcelonap Not necessarily, codegen can always be extended to support other languages, and @adobe/aio-commerce-lib-admin-ui/web can be turned into @adobe/aio-commerce-lib-admin-ui/web/react with room for future frameworks, such as @adobe/aio-commerce-lib-admin-ui/web/vue (although I don't see that happening in the near future, TBH, as much as I would like to implement the flexibility).

As a side note, does aio app build even support any other library besides React?

I meant you can not opt out of the code generation and even if removed will be regenerated which means you're stuck with React. I am not saying this is bad, for me is just enough. We can always add in the future a way to opt out of the scaffolding if there's a real need.
Just wanted to note that this is a drawback of the current scaffolding design.

[asalloum5]

I have a doubt here, do we handle non-react apps? I didn't see anything related to this.