Hi,
until karma 1.4.1 I had console.log / error / debug output but since 1.5.0 nothing is printed to the terminal. I have seen the following changelog:
filter browser logging by level of LOG (89a7a1c), closes #2228
Do I have anything to adapt?
Following config is used:
config.set({
basePath: "",
frameworks: [
"mocha",
"browserify",
"chai-dom",
"chai-sinon",
"fixture"
],
files: [
// ...
],
exclude: [],
preprocessors: {
[`${testJsAssetsDir}js/**/*Spec.js`]: ["browserify"],
"./fixture/**/*.html": ["html2js"]
},
browserify: {
debug: true,
transform: [
[
"browserify-istanbul",
{
instrumenter: isparta
}
]
]
},
reporters: [
"mocha",
"coverage"
],
coverageReporter: {
type: "lcov",
dir: "../../../../build/reports/coverage/client"
},
port: 9877,
colors: true,
logLevel: config.LOG_INFO,
autoWatch: false,
browsers: ["Chrome"],
singleRun: false,
concurrency: os.cpus().length
});
Thank you!
Based on the commit 89a7a1c LOG level messages are of the lowest priority. I don't think this should be the case looking at the comments from #2228:
This should be changed to what was described in the original report. Moving log down between warn and info.
@IgorAufricht I don't see link to original report. Log function is the basic and lowest priority function of console, so it was obvious to put it there.
@moehlone for browser console to work you need to add browserConsoleLogOptions option in config
@blackswanny Thank you for the hint. I added this to my config and now I can see my logs again on the terminal.
browserConsoleLogOptions: {
level: 'log',
terminal: true
},
The docs about this config can be found here.
I swear I added this too, but with level 'info'.. It works now - sorry and thank you!
The documentation says:
Here the
levelis the desired log-level, where levellogalways is logged.
This is currently not the case. Log level is not always logged, it's only logged when you set the level to log:
browserConsoleLogOptions: {
level: 'log',
terminal: true
},
For every other level setting (including the default), the log level messages are not logged.
I believe the LOG_LOG should be added at the beginning of LOG_PRIORITIES instead of at the end (how it was done in the last commit: 89a7a1c).
agree. However, the main idea is to prevent consoling of some level and up.
Putting LOG above all is just shuffling of these functions in not a natural way.
The priority should be log() , info() , debug() , warn() , and error() .
I vote for the change of documentation rather than meaning of these functions, which is confusing.
@blackswanny While I agree with your idea in general, the fact is console.log() calls are common in any js environment and I think it's quite confusing if they are not printed by default.
@IgorAufricht I think this was the main idea of the whole feature. When a person writes unit tests, he wants to focus on exact failing or under investigation unit tests and functionality. The one doesn't want to go through many log pages of some other irrelevant stuff trying to find needed information. Especially, if these console.logs are left by third party frameworks or other parties
@blackswanny Fair enough, thanks for the explanation.
I would expect the priority to be debug(), info(), log(), warn(), and error() (ie in increasing level of severity).
This matches the filters in Chrome's console, which puts debug() under Verbose, info() and log() under Info, warn() under Warnings, and error() under Errors.
Most helpful comment
I would expect the priority to be debug(), info(), log(), warn(), and error() (ie in increasing level of severity).
This matches the filters in Chrome's console, which puts debug() under Verbose, info() and log() under Info, warn() under Warnings, and error() under Errors.