Adding Custom Libraries to Oracle JET apps

Just a quick note on adding custom libraries to your Oracle JET (3.0 or greater) application. The steps are well documented on the Oracle Docs page, but it’s not clear why you are doing each step. So let me try and explain it to you.

Step 1: Get the library

First step run npm install <library> --save in your root directory to get the code into your project (ie: npm install knockout-date-bindings --save).

Step 2: Get it into your project

Now you need to make sure the code is added to generated code. Each time you run grunt serve or grunt build your code is packaged up into the ‘staging’ directory. This will differ depending on if you are creating a hybrid app or a web app. It’s either at hybrid/www or /www. You need to tell Oracle JET to include the code you downloaded in step 1 into this staging directory.

To do so, edit scripts/grunt/config/oraclejet-build.js and add an entry to the copyCustomLibsToStaging array (you may need to uncomment it if this is your first third party library). Eg:

copyCustomLibsToStaging: {
   fileList: [{
     cwd: 'node_modules/knockout-date-bindings',
     src: ['*'],
     dest: 'hybrid/www/js/libs/knockout-date-bindings'


  • cwd: This is the working directory inside node_modules we will copy
  • src: Is what you want to copy. I generally just copy everything, but to minimise space, you could just copy *.js files
  • dest: Is where this code will be copied to (your staging directory).

If you run grunt build at this stage you should see your code being copied into your staging directory

Step 3: Tell require about it

You’ve downloaded the code and told JET about it, but now your actual code needs to know about it. Since it’s copied into your staging directory, just modify main.js to point to the location. In my case – add the following to main.js:

'knockout-date-bindings': 'libs/knockout-date-bindings/knockout-date-bindings'

You will also need to update the main-*-paths.json files. These are used when you are building for development, production etc. You will generally refer to the full files in development and the min files in production.

And there you go, the custom library should now be in your JET code.


Oracle JET Lessons Learnt 1: Don’t enforce your coding standard

I’ve been playing with Oracle JET (and Oracle Mobile Cloud Service) to build a demo application for a customer (I’ll post on that later). I’ve learnt a few things along the way and I’ll post these under Lessons Learnt for all to share.

One of the issues I ran into whilst building my JET app is that I hate the coding standard the JET team seems to use. They like curly braces on a new line and I prefer them on the same line. Now this is normally just one of those vi vs emacs style debates, but after fixing the auto-generated main.js file to suit my style I ran into a problem. When I went to build my code for release (using grunt build:release --platform=ios) I got an error in the uglifyjs task (Unexpected token: punc ({).

Turns out the `//injector:mainReleasePaths` and `//endinjector` comments in the main.js file actually do something! The JET build process will insert the paths from your main-release-paths.json file between these two comments. If you fiddle with the location of the curly braces then the generated code will be invalid.

So lesson learnt: you can enforce your standard on JET, but watch out for injector comments in main.js!