This blog will help you understand how to execute ESLint tool for linting JavaScript code. This blog will cover the configuration required for the ESLint tool as well as for Oracle Developer Cloud Service to execute the configured rules on the code pushed to the Git repository on Developer Cloud Service.

 

What is code linting?

Linting is the process of checking the source code for programmatic as well as stylistic errors.

 

Why use ESLint:

Below are the reasons why ESLint is a good option for JavaScript static code analysis:

  1. Highly flexible rule set
  2. Good ES6 support
  3. Functionally can be extensible with wide variety of plugins.
  4. JSX support
  5. Clear warnings and error messages

Please refer this link for more details on ESLint.

 

Project Structure: A typical Nodejs REST web service application:

Nodejs project which contains:

  1. main.js – The Nodejs source code for the service
  2. test.js - The test script for the service in main.js
  3. Gruntfile.js – The grunt configuration JavaScript file.
  4. package.json – Contains the dependency module defined
  5. manifest.json – For project execution (not necessary for the ESLint to work).

The code analysis will only run on the Javascript files, that is main.js, test.js and Gruntfile.js

 

Configurations file for ESLint:

.eslintrc.json – It is a json file which contains the rules for code analysis referred by ESLint.

 

There are specific configurations that need to be included for the ESLint tool to execute. Below are the file(s) and configurations highlighted:

 

.eslintrc.json

Below are some of the rules that I have set for the purpose of demonstration in the blog. As seen in the below, the rule is set as a json object.

The comprehensive list of rules that can be set in .eslintsrc.json can be found in the below link:

https://gist.github.com/cletusw/e01a85e399ab563b1236#file-eslintrc-L54

https://gist.github.com/cletusw/e01a85e399ab563b1236#file-eslintrc-L54

{
    "rules": {
        "semi": ["error", "always"],
        "quotes": ["warn", "double"],
        
        
        "no-cond-assign": 2,          // disallow assignment in conditional expressions
        "no-console": 1,              // disallow use of console (off by default in the node environment)
        
        
        //////////Node.js //////////
        
        "handle-callback-err": 2,   // enforces error handling in callbacks
        "no-mixed-requires": 2,     // disallow mixing regular variable and require declarations
        "no-new-require": 2,        // disallow use of new operator with the require function
        "no-path-concat": 2,        // disallow string concatenation with __dirname and __filename
        "no-process-exit": 2,       // disallow process.exit()
        "no-restricted-modules": 2, // restrict usage of specified node modules
        "no-sync": 2              // disallow use of synchronous methods
    }
}

 

 

package.json

The ESLint framework module should be included as the dev dependency which will be used by the npm test to execute the ‘eslint *.js’ command in the ‘scripts’ for execution. *.js is used to ensure all the JavaScript file in the folder in which the command is execute, are analyzed by the tool.

 

{
  "name": "LintingTest",
  "version": "0.0.1",
  "scripts": {
    "start": "node main.js",
    "test": "eslint *.js"
  },
  "dependencies": {
    "body-parser": "^1.13.2",
    "express": "^4.13.1",
    "grunt": "^0.4.5",
    "grunt-contrib-compress": "^1.3.0",
    "grunt-hook": "^0.3.1",
    "load-grunt-tasks": "^3.5.2",
    "request": ""
  },
  "devDependencies": {
    "mocha": "^3.3.0",
    "eslint": "^2.13.1"
  }
}

 

Project Structure pushed to the Developer Cloud Git repository:

2017-05-29 20_21_30-Code _ BlogProject.png

 

Build Job configuration for executing the ESLint tool to analyze all the JavaScript files in the project Folder:

 

Give a name of your choice to the build job. For this blog I have named it as ‘EslintJob’. As this is for Nodejs application, you can leave the JDK to default.

2017-05-29 20_22_12-Build_ BlogProject - Oracle Developer Cloud Service.png

 

Select the repository in which the Nodejs application code has been uploaded.

2017-05-29 20_22_12-Build_ BlogProject - Oracle Developer Cloud Service.png

 

 

Here we set the SCM polling as the trigger. This ensures that, every time we upload code to the Git repository, it will trigger the EslintJob.

2017-05-29 20_22_44-Build_ BlogProject - Oracle Developer Cloud Service.png

We would be using the execute shell build step here as well. We change the folder to ‘LintingTest’. We would be installing the ESLint module as dev dependency and use npm test to trigger the ‘eslint *.js’ command execution in package.json, mentioned as part of the scripts. This would execute the eslint tool to do code analysis of all the JavaScript files in the LintingTest folder.

2017-05-29 20_23_00-Build_ BlogProject - Oracle Developer Cloud Service.png

 

Below is the code analysis tool report generated on the EslintJob console.

2017-05-29 20_23_30-Build_ BlogProject - Oracle Developer Cloud Service.png

This is how we can easily do rule based static code analysis as part of the build process in Oracle Developer Cloud Service.

Happy Coding!

**The views expressed in this post are my own and do not necessarily reflect the views of Oracle.