build excludes from application project are not applied to dependencies

[BenReim]

When building a UI5 workspace where the root project is of type application and includes local (workspace) dependencies of type library and component, builder.resources.excludes from the root project's config are applied to the root project, but not to dependency outputs included in the build graph.

As a result, the final build output still contains dependency test resources such as:

• /resources/<component-dependency>/test/**
• /test-resources/<library-dependency>/**

Versions

• @ui5/cli: 5.0.0-alpha.5

Scenario

The root project is a UI5 project of type application.

That root application includes local workspace dependencies of different project types, specifically:

• library dependencies
• component dependencies

The root project's deploy config ui5-deploy.yaml contains:

builder:
  resources:
    excludes:
      - "/resources/**/test/**"
      - "/resources/**/localService/**"
      - "/test-resources/**"

The build is executed with:

ui5 build --workspace=local --all --clean-dest --dest <dist> --config ui5-deploy.yaml

Background: the dependency projects intentionally do not define builder.resources.excludes in their own ui5.yaml, because their unit and integration test resources must remain available when running the dev server.

Actual behavior

The final dist output still contains test resources from workspace dependencies.

Examples:

• component dependencies still contribute files under:
  • /resources/<namespace>/test/**
• library dependencies still contribute files under:
  • /test-resources/<namespace>/**

Typical examples in the generated output include:

• /resources/.../test/testsuite.qunit.html
• /resources/.../test/Test.qunit.html
• /resources/.../test/unit/unitTests.qunit.js
• /test-resources/.../testsuite.qunit.js

So the root application's excludes do not prevent dependency test assets from being written to the final build result.

Expected behavior

Currently, builder.resources.excludes being evaluated per project, not globally across the composed build.
It should be considered if a root-project builder.resources.excludes should also be honored for dependency outputs written into the final build result, including both library and component dependencies.

Why this is problematic

For deploy packaging, the root application project is often the place where the final artifact is assembled.

In that setup, it is natural to expect deploy-specific excludes from the root application config to remove test assets from the final bundle, including assets contributed by:

• local component dependencies
• local library dependencies

Without that, users have to either:

• duplicate deploy-only excludes in every dependency project,
• maintain separate deploy configs for every dependency, or
• post-process the dist folder to remove test artifacts

Minimal reproduction

1. Create a UI5 workspace with:
   • one root project of type application
   • one local dependency of type component containing test files
   • one local dependency of type library containing test files
2. Add the dependencies to the root project
3. Configure the root ui5-deploy.yaml with:

builder:
  resources:
    excludes:
      - "/resources/**/test/**"
      - "/test-resources/**"

4. Run:

ui5 build --workspace=local --all --config ui5-deploy.yaml --clean-dest

5. Inspect the output and observe that:
   • component dependency test resources are still present under /resources/.../test/**
   • library dependency test resources are still present under /test-resources/.../**

[BenReim]

As stated in #379 (comment) this might be the expected behaviour. However, in the context of the new component type it might be make sense to reconsider if a builder exclude should be applied globally.

Alternatively, the proposed --runtime flag would help with the given scenario as well.

[flovogt]

Just a comment from my side: Offering #1369 would solve this, right?

[BenReim]

@flovogt Yes, I think #1369 would surely be useful, but from my perspective, a global builder exclude or --runtime flag would be even better for the mentioned use case, as it would allow for a solution that does not require maintaining separate (deploy) configs for every dependency.