karma: Undocumented breaking change

Expected behaviour

#2228 extended browserConsoleLogOptions.level to filter messages on the terminal. This changes the behavior of karma so that under certain circumstances messages created with console no longer show up in the terminal without configuration changes. This should be documented.

Actual behaviour

There is no documentation. In my case I spent over 3 hours investigating source code, git issues, versions, etc before I identified the problem was this change.

Environment Details

  • Karma version (output of karma --version): 1.5.0

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 18
  • Comments: 25 (11 by maintainers)

Commits related to this issue

Most upvoted comments

Here are exact configuration changes that should work (works great for me after these changes):

  • Edit your karma.conf.js file to add some configuration directives under the “config.set({” line.
  • There should be a “client:” section, and inside that you need to add “captureConsole: true” like this:
client: {
    captureConsole: true
  }

… Make sure you put a comma after the word “true” if there are additional directives after the captureConsole line.

  • Add “browserConsoleLogOptions:” section, if there isn’t already one in the file, preferably just after the “client:” section. Make it look like this:
    browserConsoleLogOptions: {
      level: 'log',
      format: '%b %T: %m',
      terminal: true
    },

… The comma on the ending line is there because we will add one more section after that.

  • Add a “logLevel:” section if there isn’t already one in the file, preferably just after the “browserConsoleLogOptions:” section we just added. Make it look like this: logLevel: config.LOG_LOG Make sure you put a comma on the end of that line if there are additional config directives after this line.
  • Rebuild.
  • Restart Karma.

Then, whenever your test does:

console.log('TEST OUTPUT.');

… you should see the output. Other console log levels should also work.

My issue has been resolved. Native console.log was replaced with a custom implementation.

@robsimmons @dignifiedquire I first encountered this issue b/c I was working w/ the expectation that log != debug. console.log is used as the default “write output the screen” in most tutorials I’ve seen. It’s even used in the official jasmine docs. According to the spec, most of these cases should be using console.info but I have never seen it used that way.

The new behavior doesn’t seem like it could be consistent with the debug info log warn error ordering of console verbosity that the previous ticket claimed. If I include this in a spec:

console.debug("AAA");
console.info("BBB");
console.log("CCC");
console.warn("DDD");
console.error("EEE");

then as of 1.5.0, on the command line I get

DEBUG: 'AAA'
INFO: 'BBB'
WARN: 'DDD'
ERROR: 'EEE'

The string browserConsoleLogOptions only appears under ./node_modules/karma.

I still see no logs from the browser.

@dignifiedquire I believe that’s mostly right. The sadness is there has to be a choice between backwards compatibility and complying with the spec that Console.log === Console.debug.

There’s a separate and not-cleanly-answerable question of whether “general expectations” match the spec. I suspect the ordering disable / error / warn / log / info / debug may be both “incorrect” and “generally expected.”

Yes, it seems that in practice the order of decreasing verbosity/increasing severity is now log, debug, info, warn, error. Since the default value of browserConsoleLogOptions.level is "debug", this means that anybody not using this option will no longer see console.log entries at all.

A workaround is to set browserConsoleLogOptions.level to "log".

Log levels keep on giving. I am sorry about that. @wesleycho could you do a small write up about the old vs the new behaviour, that we can put into the changelog?