Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 

We are very happy to announce the release of UI5 Tooling 3.0. This is the largest release to date, and we are looking forward to getting your feedback on it!

Since 2018, the UI5 Tooling open-source project aims to provide a comprehensive and extensible toolkit for UI5 developers. Being developed right in the core of the UI5 framework, this is the first version that is also used in production to build and release the framework itself.

In this blog post, we would like to give you an overview of the new features UI5 Tooling 3.0 has in store for you and which changes you should be aware of when using it in your UI5 projects.

We are happy to say, this release is fully compatible with existing projects, custom tasks and custom middleware defining Specification Version 2 and later.

Build Improvements

Let’s start with some highlights on the build side:

UI5 Workspaces

UI5 Workspaces is a new feature in UI5 Tooling 3.0.

They allow you to create flexible local development environments across multiple projects. For example, if you are working on a UI5 application that is making use of a dedicated UI5 library, a UI5 Workspace configuration can bring those together, allowing you to work on the library and see the effect in the application immediately. Without the need for npm links.

UI5 Workspaces are represented by YAML files. They are easy to share, so that your whole team can use the same development environment.

A workspace configuration may look like this:
specVersion: workspace/1.0
name: default
- path: ../light.library

You can use this workspace configuration in any UI5 project that depends on “light.library”. The library will be resolved from the specified path, relative to the workspace configuration file.

This file is typically named ui5-workspace.yaml. Good to know: If you place such a file next to your project’s ui5.yaml, and if it contains a configuration named "default” (as in the example above), that workspace will be used automatically by the UI5 CLI.

Otherwise, the "workspace" CLI parameter allows you to choose a workspace, since a configuration file can contain multiple workspace configurations.

The UI5 Workspace concept has also been discussed in an RFC.

Always Building Required Dependencies

In the past, UI5 Tooling only built those dependencies requested by the user. For instance, "ui5 build" would only build the current project, whereas "ui5 build -a" would also build all its dependencies.

This could lead to inconsistent build results. If your current project creates bundles containing sources of dependencies for example, those bundles will look different depending on whether the dependencies have been built or not.

UI5 Tooling v3 fixes this by automatically building all dependencies that might influence the build result of a project, before building the project itself.

Specification Version 3.0

UI5 Tooling 3.0 introduces a new Specification Version 3.0. Besides small changes for projects, it's mainly used to express their incompatibility with previous versions of UI5 Tooling.

For example, if a project uses the latest ECMAScript features in its code, we recommend changing the Specification Version to 3.0, since the project likely can’t be built correctly by UI5 Tooling 2.x.

Enhanced Extension API

The API for UI5 Tooling extensions, such as custom tasks and custom middleware has been enhanced based on community feedback. To access the new API, extensions need to define Specification Version 3.0.

Extensions can now access project metadata and dependency information. Moreover, custom tasks can define which dependencies they require access to.

Our goal was to inject all required UI5 Tooling APIs directly into the extensions at runtime.

This should allow extensions to remove any @ui5/* dependencies from their package.json, making them more lightweight and future-proof.

For example, currently various custom tasks rely on the @ui5/fs module to create resources. With Specification Version 3.0, they can access the required resource factory method “createResource” directly on the TaskUtil instance supplied to them. Future UI5 Tooling versions aim to keep this API compatible to the specification version defined by the extension.

For details, refer to the respective extension documentation for Custom Tasks and Custom Middleware.

These extensibility improvements have also been discussed in an RFC.

Other Changes

Internally, UI5 Tooling now features a graph representation for your project’s dependencies. This allowed for many optimizations. Most prominently, the "ui5.dependencies" section in the package.json is now obsolete and ignored. Once you've switched to UI5 Tooling v3, you can safely remove it.

UI5 Tooling 3.0 also includes many bug fixes and optimizations, especially for bundle generation and other build tasks. Find a full list of all improvements and changes in the change log.

Upgrade Today

It’s as simple as executing the following command in your project:
npm install @ui5/cli@latest

Please ensure that your development environment uses the latest version of Node.js (at least v16.18.0 or v18.12.0). SAP Business Application Studio may be used once it fulfills the new requirements.

Typically, there's no need to upgrade any specification versions in your projects.

If you run into any trouble, head over to our Migration Guide. If you don't find your answer there, we invite you to raise an issue on GitHub.