SAP Web IDE Full-Stack now leverages npm v5 for building your SAP Fiori/SAPUI5 projects with Grunt. In this blog, you can learn about implications of this change for your projects.

Background

In SAP Web IDE Full-Stack, you can build your project using Grunt. Grunt is a JavaScript task runner that allows you to automate any task that you, as a front-end developer, need to perform on a regular basis. Among other things, you can:

• Validate code according to best practices using linters for CSS, JavaScript, and so on.
• Translate LESS to CSS
• Compress your CSS files and images.
• Minifiy and bundle your JavaScript and CSS files for optimized performance.

To use Grunt capabilities in SAP Web IDE Full-Stack, you do not need to set up your environment by installing the Node.js runtime environment, npm, or Grunt. Instead, you just need to add two mandatory files to your project, package.json and Gruntfile.js, which contain configurations for running npm and Grunt. You can define a Grunt script of your own or use the best practice configurations for SAPUI5 applications provided by SAP.  After that, you activate the Grunt build from your project’s context menu.  For more details on enabling Grunt, see Building Applications.

If you have defined the Gruntfile.js and package.json files in your project, the Grunt build is activated when you deploy your application to either SAP Cloud Platform or the SAPUI5 ABAP repository.

Grunt and Grunt plugins are installed and managed via npm, the Node.js package manager.

What has changed?

SAP Web IDE Full-Stack is now using npm v5.

The npm v5 major release delivers several improvements over previous versions of npm that make the build of your SAP Fiori/SAPUI5 projects run faster. And you will enjoy these enhancements without any adjustments to your existing Grunt scripts.

However, the following change requires your attention and actions:

During the build, npm automatically generates a lock file called package-lock.json that is added to your project.

Why do you need this file?

As you probably know, your project’s package.json file describes the top-level dependencies on other packages using semver:

“dependencies”: {

“some_package”: “^1.2.3”

}

The package versions may include different notations – wildcards, for example:

“^1.2.3” means that the minimum version 1.2.3 should be used, but any version later than that can also be applied  if it has the same major version 1.

Now let’s assume that currently 1.2.3 is the latest version available for “some_package”. If you build your project today, this version is applied.  However, if you build your project after  later version 1.2.4 is released, there may be different behavior in your application.

And considering the fact that each package in your package.json file might, in turn, depends on other packages and so on reaching thousands of dependencies, it is quite hard to predict the result.

The goal of the new package-lock.json file is to resolve this situation.

The package-lock.json file is a snapshot of the entire dependency tree and includes all packages and their resolved versions.

npm uses the package-lock.json file instead of package.json and applies the same dependencies for each subsequent build producing the same results every time.  Moreover, with the package-lock.json file, the build process runs faster, since npm uses the specified version instead of searching the entire version range.

What should you do?

The new package-lock.json file will be added automatically to existing projects when they are rebuilt.

If your project is connected to Git commit and push it to your Git repository to ensure a consistent and reproducible build by any contributor to the project across any build environment.

If you need maintain your project dependencies, do not change the package-lock.json file manually; instead,  change the package.json file.

More Reading

• npm@5 announcement in the official NPM Blog:

http://blog.npmjs.org/post/161081169345/v500

• Official documentation for the package-lock.json file:

https://docs.npmjs.com/files/package-lock.json

• npm blog on semver:

http://blog.npmjs.org/post/162134793605/why-use-semver