Recently on an engagement I was given the stipulations that the client could use Sightly, but not in Java Use class bundles. If any helper classes are used, they need to be in Javascript and live at the same location as the component. With these stipulations on development I took off converting their codebase to Sightly, with Sightly Javascript Use classes for any heavy lifting that couldn't be accomplished in Sightly/HTL alone.

During development on their codebase I continuously relied on console.log(someVar); as a way of logging what was going on in my Javascript Use class (sure I could have setup a big boy logger using the log global variable, but due to time constraints, I just relied on console.log). One of the issues with using this kind of logging in a Javascript Use class is that your log messages get dumped into the error.log by default, not some pretty log file that contains log messages only belonging to your code. After a work day of scrolling through useless log messages regarding replication agents and other internal AEM logging that was not of use to me trying to find my own code's log messages, I decided there has to be an easier way. Noticing that the log messages from any console.log() activity in the JS Use Classes are written to the log file with the Use Class name prefixing the log message, it was easy to see that by combining tail and grep, we could parse only log messages written by our Javascript Use class. Fast forward a few days, and I'm already getting tired of writing the two commands every few hours in the terminal to check on log messages from my JS Use class. So what's a enterprising developer to do? Automate it of course! I present the sightly-log-filter helper tool: sightly-log-filter

The readme and use of the helper bash script should be sufficient to get you up and running in no time. The installation is very straightforward, just drop the script into the log directory of your AEM instance, chmod to allow execution, and then start viewing your JS Use class logs! An alternative approach is to alias it, then use it as a standalone command.