Skip to content
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.

fix: switch to user-provided logger rather than console.log #3466

Merged
merged 4 commits into from
Aug 5, 2022

Conversation

MicaiahReid
Copy link
Contributor

The Ganache options allow you to set a custom logger to handle any logging that Ganache does*. When using Ganache programatically, this can be done as follows:

const logger = {
  log: (message?: any, ...optionalParams: any[]) => {
    // whatever custom log stuff you want
  }
};

const provider = Ganache.provider({
  logging: { logger }
});

However, there were still a few hold-out console.logs in our code, which logged directly to the console rather than the user-provided log function. This change fixes this issue.

*Pro Tip: You can actually update that logger function while Ganache is running to temporarily change how you handle logs, if you're into that sort of thing.

@@ -618,7 +618,9 @@ export default class Blockchain extends Emittery<BlockchainTypedEvents> {

resume(_threads: number = 1) {
if (!this.#isPaused()) {
console.log("Warning: startMining called when miner was already started");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other places we console.warn().

should we consider extending the logger type to add some sort of log level awareness?

export type Logger = {
  log(message?: any, ...optionalParams: any[]): void;
  info(message?: any, ...optionalParams: any[]): void;
  warn(message?: any, ...optionalParams: any[]): void;
  error(message?: any, ...optionalParams: any[]): void;
};

When normalizing we could default info/warn/error back to log to avoid this being a breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be great to have a more robust logging system to do this, and I believe it's on the docket (though I couldn't find an issue for it). This PR was meant to just be a quick fix though, so I'd rather get this through. Especially because I hardly consider this a "warning" - there are no consequences to calling miner_start when the miner isn't paused, so what are we warning them against?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although... it does start with the word "Warning:" 🦖

@@ -98,7 +98,7 @@ export class WsHandler extends BaseHandler implements Handler {
}
}

private connect(connection: WebSocket) {
private connect(connection: WebSocket, options: EthereumInternalOptions) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we require just the LoggingConfig here rather than the entire config object?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm glad you have an opinion because I kept going back and forth on this. Fixed.

Though the types here are a bit confusing - I think I got it right with EthereumInternalOptions["logging"] rather than LoggingConfig.

@MicaiahReid MicaiahReid merged commit df29a09 into develop Aug 5, 2022
@MicaiahReid MicaiahReid deleted the bye-console-log branch August 5, 2022 19:48
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants