UI5ers Buzz #42: UI5 Evolution – The Build and Development Tooling

[pmuessig]

This blog post will give you some more insights to another key pillar of the UI5 Evolution project: the UI5 Build and Development Tooling.

Back in 2009 a Maven-based tooling was created to support and scale the development of UI5 libraries and applications. The tooling focused on Eclipse Web Tools Platform and the Maven integration as development environment. This allowed us to easily integrate the build lifecycle into the environment of the developers. The key at this point in time was to create a best of breed development experience with fast turnaround cycles. While this was extremely nice in the beginning of the UI5 development, it became more and more old-school with the emerging Node.js environment and the up-coming task runners Grunt and Gulp. In the new world, developers could stay in their JavaScript domain for creating build tasks. This created a higher acceptance rate because it brought about the freedom of choice for the IDE, be it Web Storm, Atom or Visual Studio Code.

In 2014, we started to build a Grunt based build and development tooling for OpenUI5. Now we have to maintain two toolings: one for Maven and one for Grunt. In order to avoid rewriting the tooling for every environment we decided to create a successor for the existing toolings: the UI5 Build and Development Tooling – an open-source Node.js based build and development environment to support both application and framework developers inside and outside of SAP.

Since March 2018, the new tooling has been open-sourced and is available for everyone in an alpha release. With the tooling, we basically address the following topics: Agnostic Build Modules, Command Line Interface, Self-contained Packaging and Migration Tooling.

 

Agnostic Build Modules

This topic is about the independence of the build modules from a dedicated task runner. Therefore, we agreed on leveraging CommonJS modules having a simplistic API which abstracts the access to the resources of the project and its dependencies. Each environment implements an adapter which provides the resources via the simplistic API to the build modules. By default, we provide such tooling for plain Node.js without a coupling to Grunt or Gulp. The main benefit is that we do not couple the tooling to a dedicated task runner anymore and we can recycle the build modules for arbitrary JavaScript based toolings by implementing an adapter to run the build modules.

Technically, the build modules consist of a task and a processor. The task is collecting the resources and the configuration from the project and its dependencies. With the set of resources, the task calls the processor and let him do his job. The processor is doing the real build job to create or modify resources, e.g. uglifying them.  Afterwards the task writes the resources back into the workspace.



An example of a task and a processor for uglifying can be found in the documentation:
https://github.com/SAP/ui5-tooling/blob/master/docs/TasksAndProcessors.md

** Keep in mind that the build modules are still work in progress and the API might change!

 

Command Line Interface

Today’s front-end developers are familiar with Node.js. Since the Node package manager (NPM) has been evolved to act as a dependency manager also for front-end packages, it has become the de-facto standard for managing the dependencies when building front-end applications. There is no need to use other tools like Bower anymore. Everything can be consumed as NPM package.

In addition, most JavaScript frameworks are providing a Command Line Interface (CLI) today. The CLI assists the developers in their development and build lifecycle by providing a set of standard build modules. The advantage of a CLI is that it can be easily integrated in different environments, such as the developer’s workplace inside the shell or an editor or even a build system like Jenkins or Travis.

The UI5 CLI consist of a development server and the build tools to make UI5 applications ready for the deployment. The development server provides a runtime perspective for the project resources and the resources of its dependencies. The project resources of UI5 applications are directly available in the root of the development server. The project dependencies are available in the resources or test-resources path of the development server whereas the resources are coming from the dependencies src folder and the test-resources are coming from the test folder. Additionally, the development server comes with some more features like version replacement. Moreover, Less to CSS compilation is done on-the-fly when requesting the CSS files for the UI5 libraries which are not available in the file system at development time. The following picture illustrates how this concept works:

Besides the development server, the main job of the UI5 Build and Development Tooling is to make the UI5 application production ready or to build a UI5 library to share it on NPM. For UI5 applications, the new tooling provides the option to run a preload build. The preload build typically runs the following build modules: copyright and version replacement, generation of the Level-0 changes bundle (merging changes files created with SAP Web IDE into a changes bundle), preload generation, debug file creation, minification of the non-debug files and the creation of the version information file. In the following you can see an execution of the ui5 build command:



The UI5 application is now production ready and can be deployed on your web server for standalone execution or into the Fiori launchpad (when all the metadata in the manifest.json is maintained properly).

OpenUI5 front-end packages for NPM:
https://blogs.sap.com/2018/10/24/openui5-npm-release/

Getting started with the UI5 CLI:
https://github.com/SAP/ui5-tooling#installing-the-ui5-cli

Learn how-to use the UI5 Build and Development Tooling on our sample project:
https://github.com/SAP/openui5-sample-app/#openui5-sample-app

 

Self-contained Packages

In the UI5 Evolution project we are aiming to reduce the footprint of applications. The preload build is very coarse granular when it comes to consuming the UI5 libraries as preloads. It would be ideal to load just the amount of JavaScript needed for the UI5 application. Therefore, we came up with the option to create self-contained packages for standalone UI5 applications. This is especially interesting for mobile applications or Progressive Web Apps (PWAs) to benefit from smaller packages. In order to run the self-contained build, you just need to add the option to the UI5 build command. It utilizes the changes in the Modular Core to depend on fine granular modules to create minimalistic bundles and to benefit from an increased startup performance:



This will now use the standalone app bundler instead of the component preload bundler in step 4 and create a self-contained package which includes the JavaScript resources of the UI5 application and the dependencies:



For example, the size of loaded JavaScript will decrease for the openui5-sample-app from around 1.2 MB to 500 kB. You can try this out yourself by following the documentation in our “Learn how-to use the UI5 Build and Development Tooling on our sample project” in the CLI section above.

UI5ers Buzz #19: Let’s be progressive – Convert an OpenUI5 Application into a Progressive Web App:
https://blogs.sap.com/2017/11/30/ui5ers-buzz-19-lets-be-progressive-convert-an-openui5-application-i...

UI5ers Buzz #13: Build a Progressive Web App with OpenUI5:
https://blogs.sap.com/2017/08/30/ui5ers-buzz-13-build-a-progressive-web-app-with-openui5/

Read more about Progressive Web Apps:
https://developers.google.com/web/progressive-web-apps/

 

Migration Tools

The last topic about Migration Tools is another important one which we are currently working on to be able to rollout tooling support here as well. The goal is to be able to use the UI5 Migration Tools to convert legacy jQuery.sap.declare/require based modules into new AMD-like modules. This is to enable the use of the dependencies from the Modular Core rather than the functionality from jQuery plugins from the Global namespace.

The Migration Tools will become part of the UI5 CLI and will be also integrated into the SAP Web IDE. By establishing easy consumption of the tools, we expect that developers will run the tools on regular basis to benefit from improvements and to keep their code up-to-date as much as possible. It should become a standard step when switching to a new UI5 version to run the tools and adopt the code in this process.

Migrate your UI5Lab library to the new UI5 tooling:
https://blogs.sap.com/2018/11/02/migrate-your-ui5lab-library-to-the-new-ui5-tooling/

 

Conclusion

The UI5 Build and Development Tooling is another key pillar of the UI5 Evolution project and it ensures to provide a common development environment for developers inside and outside of SAP. In addition, it helps to make your UI5 application production ready via the preload or the new self-contained build. It will also soon come with Migration Tools to support developers to keep their code-base up-to-date. The tooling is open-source and we ask you to use the tooling, provide feedback and also contribute features to it to be able to provide a great development experience for UI5 development.

 

UI5 Build and Development Tooling: https://github.com/SAP/ui5-tooling 

 

Previous Post: UI5ers Buzz #41

 

Peter is one of the initiators who started the Phoenix project (a.k.a. OpenUI5/SAPUI5). Today he is working as Lead Architect for OpenUI5/SAPUI5. His focus topics are the UI5 Evolution project and the UI5 Web Components.