Log to a file #748
Comments
|
Another way to solve it would be to inject a logger into each plugin. This is what karma does, but that would mean for us to add a dependency injection framework (or alter each interface). I'm not convinced we need that yet. |
ghost
assigned
|
I've created the first draft of the logging api. @simondel @Archcry could you maybe have a look? |
|
For the file logging: I'm thinking of keeping it simple. Add a config option for the file log level: /**
* The log level for logging to a file. If defined, stryker will output a log file called "stryker.log".
* Default: undefined
*/
fileLogLevel?: LogLevel;
/**
* The log level for logging to the console. Default: "info".
*/
logLevel?: LogLevel;@stryker-mutator/contributors any feedback is welcome. |
|
@nicojs why two different levels? I would expect (as you pictured in the original idea) that all logging is sent to a file, so that when something goes wrong, that file contains all information that has been collected thus far. The Also, just like SLF4J does, it might be useful to signal when logging is probably not set up correctly. In the case of SLF4J this can happen when there are multiple implementations on the classpath; in our case, it might be when the |
Yeah, I've thought about it. The problem is that I cannot guarantee it doesn't impact performance in a negative way. We still don't have performance tests. I've tested a first implementation on Stryker itself and the log file was 23MB. Do you think that this is a problem?
Great idea, I'll add it to the original issue |
Allocating 23 MB of disk space with the risk of throwing it away? Personally, it doesn't seem like a big deal to me, if it gave the benefit of very detailed log messages for troubleshooting. |
|
Hmm ok, you've convinced me. It serves the use case of reporting issues. Whenever we have more use cases, we can change it again. |
|
Let's go for an opt-in setting and place the log file in the current working directory. |
This feature adds the ability to log to a "stryker.log" file using a separate log level.
You can configure it like this:
```js
// stryker.conf.js
module.exports = function(config) {
config.set({
fileLogLevel: 'trace' // defaults to 'off'
});
}
```
**Note:** The console logger can still be configured as expected using `logLevel: 'info'`.
This also adds logging to the stryker api. Plugin creators can now opt into stryker logging using the new logging api:
```ts
import { getLogger, Logger } from 'stryker-api/logging';
const logger: Logger = getLogger('myLoggerCategory');
```
They no longer have to 'role their own config'. Stryker will take care of the logging appearing in the expected places (console and file).
Fixes #748
For ease of debugging issues, it would be useful to log all messages (log level trace) to a file. Comparable to what npm does: when an npm command fails, the user is informed that a log file can be found in the temp directory.
In order to do this, all stryker packages need to share log4js configuration. In order to do this, we need to move log4js to a shared peer dependency. The only one we have is the stryker-api, so I suggest to add the
getLoggermethod there. We best use our own api and not rely in log4js for this. That way we can choose a different implementation rather easily. The stryker-api should not have a dependency on log4js, rather it would provide a way to set the log implementation. By default, it has anoopimplementation and should log a warning (comparable to SLF4J for JVM).This would also remove the necessity to call
setGlobalLogLevelin every plugin to configure the log level on his instance of log4js.The text was updated successfully, but these errors were encountered: