Skip to Content
Author's profile photo Sathish Babu Krishna Vihar

Building your SAP UI5 Application using Grunt

It was in early 2013 that I got exposed to and started using grunt heavily for performing the build activities on one of the HTML based UI projects and recently I had the opportunity to also try it out with an UI5 application. Grunt provides a wide range of tasks and this makes activities like static checks, minifaction, etc a simple operation. When I started with the UI5 build process, the initial few hours were spent on defining an appropriate build process (depicted and explained below).



Before we look into the build details, let me list down the grunt plugins that were used for the build purpose.

 "devDependencies": {
 "grunt": "~0.4.5",
 "grunt-contrib-clean" : "~0.5.0",
 "grunt-contrib-concat" : "~0.4.0",   
 "grunt-contrib-copy" : "~0.5.0",
 "grunt-contrib-uglify" : "~0.5.0",   
 "grunt-contrib-less" : "~0.11.0",         
 "grunt-contrib-jshint" : "~0.10.0",   
 "grunt-contrib-compress" : "~0.9.0",
 "grunt-contrib-csslint" : "~0.2.0"   

The following are the reference paths that are used in the build. These were maintained in a separate GruntRef.json file that resides in the application root.

      "source"    : "src/",              //contains the source files
      "staging"   : "build/staging/",     //used for staging phase
      "process"   : "build/process/",     //used for process phase
      "finalize"  : "build/finalize/",    //used for finalization phase
      "output"    : "build/output         //contains the final output

The “source” folder could also be your “WebContent” folder if a separate project is used for development.

Prepare Phase

The preparation phase starts with a cleanup of the existing folders, if any. The build process was defined in such a way that the entire build happens in a separate local folder which is overwritten with each build. As a result, the previous build output has to be wiped clean before starting with the new build.

clean: {
prepare: {
              //Release the folder build/process
              src: ["<%= ref.process%>", "<%= ref.staging%>", "<%= ref.output%>", "<%= ref.finalize%>"]

Once the cleanup is done, the source files are copied from the source into the staging area. Only those files that are essential for final deployment are copied and the rest are skipped (for e.g. the unit tests, local index, etc)

copy: {
              prepare: {
                     //copy all the files from WebContent before we start the processing
                     //The files are copied into the staging area
                     files: [
                            Copy all files to prepare for further processing
                            expand : true,
                            cwd    : "<%= ref.source%>",
                            src : ['**/*', '!data/**', '!util/MockServer.js', '!META-INF/**', '!WEB-INF/**', '!test/**', '!test_local.html', '!index_local.html'],
                             dest : "<%= ref.staging%>"

Process Phase

During the process phase the following actions are performed by the build.

Static Checks

The static checks are performed on the original code in the staging area and the report is downloaded as a CSV file. The JSHint module was used for performing the static checks

       jshint: {
              process: {
                     options : {
                            eqeqeq : true,
                            es3    : true,
                            unused : true,
                            eqnull : true,
                            camelcase : true,
                            laxbreak  : true,
                            force  : true,
                            reporter : "jshint-reporter",
                            reporterOutput : "<%= ref.output%>JSLint.csv"
                     src: "<%= ref.staging%>**/*.js"

The below reporter function enables in generating a custom CSV file for the error generated by the static check. The reporter was placed in a separate file in the application root (along with the gruntfile.js)

 reporter: function (res) {
    var len = res.length;
    var str = "";
    // Header
    str += "Filepath , Type, Code, Line , Column , Reason , Evidence \n"
 res.forEach(function (r) {
      var file = r.file;
      var err = r.error;
      str += file + ", "
              + + ", "
              + err.code + ", "
              + err.line + ", "
              + err.character + ", "
 + err.reason + ", "
 + err.evidence + "\n";
    if (str) {

The build process does not terminate if there are errors in the static check. This can however be changed by turning the jshint option “force” to “false”. The decision on when to stop the build due to errors in static checks can vary from project to project. The CSV file is directly written to the “output” folder as this would be one of the final outputs of the build process.


Once the static checks are done on the original source in the staging area, it is time to perform any code generation / transformation. In this build, I have taken the case of Less to CSS transformation. The “less” grunt plugin performs this transformation

less: {
  process: {
  options: {
  compress : true,
  cleancss : true,
  sourceMap : true
  files: {
  "<%= ref.process%>style/root.css" : "<%= ref.staging%>style/root.less"


Minification is performed using the highly popular plugin “uglify”. The source for the minified are picked from the staging area and placed in the process folders.  Other file types can also be minified in this step using the relevant plugins. At the end of this process step all files are minified and available in the process folder.

       uglify: {
              options : {
                     mangle : true,
                     compress : {
                            drop_console : true,
                            dead_code : false,
                            unused        : false
              files : {
                     expand : true,
                     cwd    : "<%= ref.staging%>",
                     src : ["**/*.js", '!test/**', '!test_local.html'],
                     dest   : "<%= ref.process%>"

Debug File Generation

Though the minified files that have been placed in the process folder should be good enough for running the application, we need to also generate the debug files that would help in debugging the application in UI5 debug mode. To achieve this I have used the “copy” plugin that also copies all the other files (Note: I have minified only the JS files and not the other file types). During the copy process, the JS files are renamed to include the “-dbg” suffix. However this is not completely straightforward. For the controllers, the “-dbg” should be suffixed to the view name (i.e., before the “.controller” substring)

process: {
  files: [
  Copy JS files to create the dbg version
          expand : true,
          cwd : "<%= ref.staging%>",
          src : ['**/*.js', '**/*.html', '**/*.xml', '**/*.jpg', '**/*.png', '**/*.gif', '**/*version.json', '**/*.properties'],
          dest : "<%= ref.process%>",
          rename : function(dest, src){
               var aSrc = src.split('.');
               var ext = aSrc.pop();
               if(ext === 'js') {
                    if(aSrc.length > 1){
                         if(aSrc[aSrc.length - 1] === "controller"){
                              ext = aSrc.pop() +"." + ext;
                    return dest + aSrc.join('.') + '-dbg.' + ext;
               }     else {
                    return dest + src;

Note: Before the debug files are created, the Component-preload.js is created by concatenating all utils, controls and other relevant files. I have deliberately kept the view controllers out of the preload as in my case I did not want to load all the views in one request but load them only on demand.

At the end of these steps, the files have been processed and are ready to be deployed.

Finalization Phase

The finalization phase involves the following steps.

File Headers

It may be required to add file headers to the final output. This can be added using the concat plugin. The files are then copied to the finalize folder.

Generate Archive

The compress plugin helps in creating an archive from the source code. In this case I am creating a simple ZIP file of the processed files which would then be deployed in the target WebContent folder.

compress: {
       finalize: {
              options: {
                     archive: "<%= ref.output%>build<%='yyyymmddhhmmss')%>.zip"
              files: [{
                     expand : true,
                     cwd    : "<%= ref.finalize%>",
                     src    : "**/*",
                     dest : ""


The final step is to clean-up all the folders, except the output folder.

copy :  {
finalize: {
              //Release the folder build/_process
              src: ["<%= ref.staging%>", "<%= ref.process%>", "<%= ref.finalize%>"]

The above process is just one of the many ways in which grunt can be used for building the SAPUI5 application. The build can be further simplified depending on the specific requirement of the project. To end, the tasks that were used in the final build is given below.

     grunt.registerTask('default', ['clean:prepare', 'copy:prepare',
          'jshint:process', 'less:process', 'uglify', 'concat:process',
          'clean:process', 'copy:process', 'concat:finalizeJS',
          'concat:finalizeML', 'concat:finalizeProp', 'copy:finalize',
          'updateVersion',  'compress:finalize', 'clean:finalize']);

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Michael Vogel
      Michael Vogel


      is it also possible to concatenate several notepad controls and maybe some views with their controller into a preload file with the grunt uglify task?



      Author's profile photo Frank Luzat
      Frank Luzat


      great post!

      Would you post your complete gruntfile.js ?

      Author's profile photo Former Member
      Former Member

      Seems to be helpful. Unfortunately I can't seem to see the full picture as in where what code did you put and the structure of your project. Depending on that, implementing what you blogged about might be rather difficult for others. Especially those with little experience with grunt and nodejs for that matter.

      Overall seems like very great way to build project. If only I could apply to mine:D