Add ability to also log to disk

[sindresorhus]

We can use app.getPath('logs') to get the path to the logs directory.

The person that implements this should do some research on how other log solutions do it. Regarding max size, log rotation, etc.

[acheronfail]

Other logging implementations

Just some references to some logging implementations I found from other languages.

• Python:
  • https://docs.python.org/3.6/library/logging.handlers.html#rotatingfilehandler
  • https://tutorialedge.net/python/python-logging-best-practices/
• Golang:
  • https://github.com/natefinch/lumberjack -> The standard log package doesn't have log rotation
• Swift:
  • https://docs.swiftybeaver.com/article/10-log-to-file
• C++:
  • (Boost lib): boost-log.sourceforge.net
  • (spdlog): https://github.com/gabime/spdlog

I didn't find anything wildly consistent between them all - just about the only thing that had really solid standards was system logging for Linux systems, but that's not cross-platform and can be quite intensive.

[acheronfail]

Here's some more resources I've found (from https://github.com/emaloney/CleanroomLogger):

• https://rawgit.com/emaloney/CleanroomLogger/master/Documentation/API/Classes/RotatingLogFileConfiguration.html
• https://rawgit.com/emaloney/CleanroomLogger/master/Documentation/API/Classes/FileLogRecorder.html

EDIT: And another (this one is written in Node):

• https://github.com/trentm/node-bunyan

[edwardchanjw]

Electron-log's log rotate issue, direct alternative in Electron ecosystem, it already have at least to able rotate once log file size reaches the maximum defined (max-size).

minilog seem quite low activity.
I like the Approach is to pipe to File (and all other WritableStreams)

require('minilog').pipe(fs.createWriteStream('./temp.log'));

[cgalvarez]

I would take a look at winston, which is a very capable, tested and stable logger for Node.js. Some points to consider from this package:

• Defining transports, each one managing its own logging features. This way, we could refactor all the native console in its own transport (being the default one selected if none explicitly configured), and the all the file-related in another different one. Also, each transport could implement different methods for main/renderer processes, contributing to #16
• Allowing custom log levels: I want to define verbose and debug. Currently only error/warn/info are considered, and there is no way to add new custom levels.

Also, from my own needs, I've check that instantiating a custom logger only create it for main process. I use electron-timber in a custom package of mine, and I would like to instantiate that logger only once (maybe keeping a static reference to it and returning it if that name already exists in the static map) and prefix the messages like custom logger [main] > / custom logger [renderer]. This way, we could get the complete trace not only from the app, but all the other NPM packages used, and they could be disabled with the ignore option.

I think this approach provides greater flexibility, customization and maintenace while keeping the project small enough.

Let me know what you think about this. I'm currently working on #18 (refactor PR) of this package, and I'm going to start working on these features soon.