UI5 / UI5/cli

build excludes from application project are not applied to dependencies

Open
#1,446 3 comments 0 reactions 1 assignee View on GitHub

@flovogt is already working on this.

Since Sep 2, 2026.

Dominant language
JavaScript
Stars
511
Forks
83
Avg merge
1d 5h
Merged PRs (30d)
55

Description

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/**"
  1. Run:
ui5 build --workspace=local --all --config ui5-deploy.yaml --clean-dest
  1. 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/.../**

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.