Log the parser we're using at run time #65
Conversation
Similar to the approach we took for Radon, this is helpful output to guide users who might need babel toward the info they would need.
| @@ -16,6 +16,8 @@ var cli = new CLIEngine(options); | |||
| var debug = false; | |||
| var checks = require("../lib/checks"); | |||
|
|
|||
| console.error("ESLint is running with the " + cli.getConfigForFile(null).parser + " parser."); | |||
There was a problem hiding this comment.
Since we already set console.log to console.error to achieve the right semantics re output streams automatically, I'd probably use console.log for our own logging too, to be consistent. WDYT?
There was a problem hiding this comment.
We already use console.error elsewhere in the script for our own logging, so I actually think sticking with .error is more consistent. The console.log change was made mainly (IMHO) to prevent code deep in the innards of ESLint or plugins from ruining our day. For our own code, we've mostly used .error so far, and personally I think we should continue to because it's more explicit. If we were going to switch to .log, though, I'd say that should be a separate refactor PR, so I'd still argue to keep this commit as-is.
There was a problem hiding this comment.
Got it. Makes sense given the current state of the code not visible in the diff.
|
LGTM |
Log the parser we're using at run time
Similar to the approach we took for Radon, this is helpful output to
guide users who might need babel toward the info they would need.
cc @codeclimate/review