Motivation

For a good structuring in a development project it is a smart idea to encapsulate different components and make them available for reuse.
In the area of UI5 there is the option of a library or a reuse component.

A good overview of the options is a 2018 article by Nabi that still discusses current issues:

These components can then be used by many apps without having to develop them over and over again.
The big disadvantage is that changes to these components can have a significant impact on many apps.

The problem is that the component is supposed to improve and speed up the work.
Instead, this causes that the components are no longer touched because the risk of breaking something is too great or the test effort is too extensive.

The major problem is that only the version that is available on the system must be used. It is not possible to use different versions of a reuse component on the same system.
It works differently e.g. in the NPM JavaScript Ecosystem, where changes create a new version number which can then be used explicitly by an application.
Wouldn’t it be great if we could use this system for libraries and reuse components?

Concept

A component is organized in a unique namespace, the namespace of the component equals the component name.
We could use this to include the version of a component in the namespace, since a specific component is always called with the namespace in the manifest.
For versioning for the widely used semantic versioning can be used

So instead of looking like this “ui.component.orderhandling” , the namespace of a component could look like this “ui.component.orderhandling.v1_2_4”.

This namespace variant is just a suggestion I use and since there is no universal solution for it yet, the versioning can be customized as it suits you better.
The version can also be separated with dots and look like this:
“ui.component.orderhandling.v1.2.4”.
However, since this suggests a partitioning, it is recommended to use underscores.

Also the versioning with major minor and patch can be adapted for the own use case and e.g. patch can be omitted completely.
Without patch e.g. a version “ui.component.orderhandling.v1_2” can be overwritten with a fix without having to adapt the app manifest.
But this must be decided differently for each use case.

Proof of concept

My current UI5 open source project is the reuse component UI5 Excel Upload.
Here I wanted to implement the idea of a multi version namespace from the beginning.
Peter Muessig and Frank Weigel gave me the idea and helped me with the implementation of this proof of concept.

Development

The code of the latest version consumed by an application is always available on npmjs.com:
The source code is available here: https://github.com/marianfoo/ui5-cc-excelUpload

You can see the namespace with the version in the code and of course also in the ui5.yaml:

specVersion: '2.6'
type: module
metadata:
  name: ui5-cc-excelupload
resources:
  configuration:
    paths:
      /thirdparty/customControl/excelUpload/v0_10_0/: ./dist/

Of course, it would be a pain to always change this namespace manually. So here we use a combination of node script and the “ui5-tooling-stringreplace” module.

As a basis for the version we always take the versions attribute from the package.json.
The node script takes this version and replaces the version in the yaml files for the component, for the build and for the ABAP system deployment.

Since the current version is now in the yaml files, we can use them and trigger the build with the ui5 tooling.
We use ui5-tooling-stringreplace and replace placeholders in the code with the current namespace.

So the original code becomes the final variant with the versioning namespace:

const Component = UIComponent.extend("cc.excelUpload.XXXnamespaceXXX.Component", {

const Component = UIComponent.extend("cc.excelUpload.v0_10_0.Component", {

Consumption

The reuse component can be consumed in an application in two ways.
On the one hand, it can be integrated directly into the app and deployed together, or the component can be deployed centrally on an SAP server.
I have described the two options in the documentation for the Excel upload.

The important part for the component is defined in manifest.json where the namespace is also specified.

"componentUsages": {
  "excelUpload": {
    "name": "cc.excelUpload.v0_10_0"
  }
},

This is where the big advantage becomes clear. Each app can define its own version to be used.
Thus, newer and newer versions can be created with changes without affecting all apps.
Everything else works normally as with any other reuse component.

Deployment

The use case for deployment to an ABAP system is probably the most common.
As already mentioned above, I have also developed and documented a concept here.
The problem with the versioning of a component is that the name in the system must be changed again and again when a new version is created.
If this is not changed, the newest version would always overwrite the old one.

As an example, I have created a separate yaml file for deployment to the SAP ABAP Platform 1909, Developer Edition (fortunately this is still running on my system) to make this clearer.
The essential lines in this file would be:

app:
  name: Z_XUP_v0_10_0

Unfortunately, the number of characters is limited, so the prefix in front of them was kept minimal to make sure we can keep the name schema.
Since the version is updated here with a node script, the own naming scheme can be used of course. It must only be considered that the name is limited to 15 characters.
As explained above, in case of a version change the app name would change automatically, e.g. to Z_XUP_v0_10_1.

This makes it possible for different apps to consume different versions of the same component.
As a simple illustration, here is a diagram that shows the deployment on an ABAP system and the consumption from a Fiori launchpad.

Conclusion

The basic procedure to use a multi version namespace on a component or library has some overhead to set up.
The big advantage is that the component can then be developed agilely and with minimal testing effort.
Therefore, the obsolescence and death of large much-used components can be avoided.

A disadvantage of this approach is that if a change should really affect all apps immediately, the version must also be changed in all apps.
Therefore, the described approach is not the optimal one for all components and libraries.

Is this approach practical and useful for you and have you also encountered the same problems described?
Since I have not yet seen a comparable approach, do you have any suggestions for improving this?
I am open for suggestions and discussion.

Links