Power up your Oracle JET — Utilizing the full potential of Grunt tasks
The Oracle JET framework has a pretty well-engineered set of tools in store. The build toolchain uses Grunt as its task runner, which builds and deploys your application for you. If you already did a Hello World in JET, you probably know the grunt serve command. It spins up a web server which displays and reloads your app every time you make a change in your source code. But Grunt can do more for you! I will show you how to extend JETs pre-configured Grunt to run a linter.
Why?
A linter can help you to write less error-prone and more readable code. The folks at eslint.org explain the need for linters pretty well:
JavaScript, being a dynamic and loosely-typed language, is especially prone to developer error. Without the benefit of a compilation process, JavaScript code is typically executed in order to find syntax or other errors. Linting tools like ESLint allow developers to discover problems with their JavaScript code without executing it.
Most folks nowadays use ESLint for this. The lesser-known XO and the somewhat older JSHint are fine, too.
How?
First of all, you need an .eslintrc file. This is the configuration file that tells ESLint what rules to apply when checking your code. Install ESLint via npm install -save-dev eslint and then run eslint — init (← that’s two dashes before the “init”). When asked how to configure ESLint, select “Use a popular style guide”. Pick one that sounds good to you . I’d say the Airbnb style guide is kind of hardcore, so prepare yourself for a lot of errors if you choose this ruleset. When asked for the format, choose JavaScript. This will result in an .eslintrc.js file in your app’s root directory.
There is a file called Gruntfile.js in your application’s root folder, which tells Grunt what it should do. In JET v2.1, it initially looks like this:
For now, the Gruntfile only loads the grunt-oraclejet plugin and defines aliases for it’s tasks. Now you know what happens when you run grunt serve — Grunt redirects the command to oraclejet-serve. Line 7 already gives you a hint on where you have to put your custom task definitions: It loads them from the scripts/grunt/config directory! Currently, there is only a bowercopy.js file inside this folder.
You want to use ESLint for checking our code’s style. So head over to npm, find the grunt-eslint plugin and npm-install it. The plugin’s documentation also tells you what you would theoretically have to do to lint our code:
However, this Grunt setup is different because you want each task definition to have it’s own file in scripts/grunt/config. So go ahead and create a file called eslint.js in this folder. Double-check if you really typed this exact filename — otherwise Grunt will not be able to find your task config. If you did not change the default source folder of your JET application, you can use the task configuration exactly as shown:
Now, launch grunt eslint and see the magic happen! If you are doing this in an existing project, you probably see loads of errors, so feel free to ignore them for now ;)
With Grunt, you can also define aliases for your tasks. This is especially useful if you have some unit tests that you want to run alongside the linter. It can be useful to run the linter on grunt test and before your — hypothetical — mocha task. For configuring this, you would add this line near the end of your Gruntfile:
grunt.registerTask(‘test’, [‘eslint’, ‘mocha’])
TL;DR:
- Install eslint and the grunt-eslint plugin: npm install eslint grunt-eslint
- Create a .eslintrc.js file via eslint — init
- Create the eslint.js file and tell Grunt where it can find the eslint configuration and the files to check
- Run it via grunt eslint!
Want to learn more about this and more topics about building Oracle JET applications? Make sure to sign up for the workshop that Andreas Koop and I will run at this year’s DOAG conference in Nürnberg (it’s in german though)!
