Blanket.js is a code coverage tool when testing to figure out how much of your code is being tested. After posting about how to fix Blanket so that the console log works better on Chrome, I figured why not mention this on their development site. Maybe something could be done about this.

On opening issue #533 to ask on the possibility of including a fix for how the logging looks in Chrome, I was advised that if a PR was submitted it could be included in to the project.

A PR is a pull request, where after forking the code to your own repository, you make your fixes and do your testing. After your updates have been committed to your forked version, you can then submit a pull request back to the originating code. My pull request #534 ended up providing not just Chrome support, but Firefox support too and even for Internet Explorer.

Chrome console fix

Since Chrome is using a CSS styling technique that comes from Firebug on Firefox, one of my commits was to provide support for both Chrome and Firefox. They were done in such a way that the code for detecting if you’re using chrome’s console can be easily updated if need be:

function isChromeConsole() {
 if (!window) {
   return;
 }
 return !!window.chrome;
}

Checking if there’s a window is vital, as currently the code is mostly used not from a web browser but from a command console instead.

The other significant part is what to replace their existing logging code with. By using a separate function for it, we can reassign their logging code to the new function with no loss of effectiveness.

function cssLog(str, color) {
  if (color === undefined) {
    console.log(str);
  } else {
    console.log('%c' + str, 'color: ' + color); 
  }
};
if (isChromeConsole()) {
 proto.log = cssLog;
}

Fixing other consoles

Due to the code not being deeply nested, it’s easy to include other checks for the Firefox console too. And while doing the updates for Chrome and Firefox, I figured why not complete the trifecta with Internet Explorer support too using console.error() and console.info(), details of which can be see in the IE console color support patch.

As feature-detection is not feasible for these updates, I’ve had to resort to a less-pleasing solution of browser detection instead, but it’s helped to get things off the ground.

While doing the IE support I also realised that passing “red” and “green” may not be a good solution overall for the console reporter, and that instead passing status info such as “pass” or “fail” would be a better solution instead. As that type of update would result in all of the consoleReporter code being rewritten, that’s something that’s best left for another time.

In conclusion

My updates ended up increasing their consoleReporter by about half its size, but it’s resulted in everything looking good across several of the most widely used browsers. Later on when we know of better ways to detect browser logging capabilities, this code will be able to be easily updated to reflect that too.

It’s also resulted in the recent ANSI-color workaround post no longer being relevant, but that’s the price of progress. The same goes with code too. Virtually all code ends up being replaced. We can only hope that those replacements are for the better.

Advertisements