CerebroToolboxLogger

Logger

Last updated:

Toolbox: Logger

The logger provides methods for outputting messages at different log levels.

Basic Usage

cli.addCommand({
    name: "example",
    execute: ({ logger }) => {
        logger.info("Information message");
        logger.error("Error message");
        logger.warn("Warning message");
        logger.debug("Debug message");
    },
});

Log Levels

Info

General information messages:

logger.info("Building project...");
logger.info("Files processed:", fileCount);

Error

Error messages:

logger.error("Failed to build");
logger.error("Error details:", error);

Warn

Warning messages:

logger.warn("Deprecated option used");
logger.warn("This feature will be removed in v2.0");

Debug

Debug messages (only shown with --debug flag):

logger.debug("Processing file:", fileName);
logger.debug("Options:", options);

Logging Objects

Logger methods accept multiple arguments:

logger.info("User:", user.name, "Age:", user.age);
logger.error("Error:", error.message, error.stack);

Verbosity Control

Log levels are controlled by verbosity flags:

cli command              # Shows info, warn, error
cli command --verbose    # Shows debug too
cli command --debug      # Shows all debug messages
cli command --quiet      # Minimal output

Custom Logger

Provide a custom logger when creating the CLI:

const customLogger = {
    info: (...args) => console.log("[INFO]", ...args),
    error: (...args) => console.error("[ERROR]", ...args),
    warn: (...args) => console.warn("[WARN]", ...args),
    debug: (...args) => {
        if (process.env.DEBUG) {
            console.debug("[DEBUG]", ...args);
        }
    },
};

const cli = new Cerebro("my-app", {
    logger: customLogger,
});

Conditional Logging

Use log levels appropriately:

execute: ({ logger, options }) => {
    if (options.verbose) {
        logger.debug("Detailed processing information");
    }

    logger.info("Starting operation...");

    try {
        // Operation
    } catch (error) {
        logger.error("Operation failed:", error);
    }
};

Best Practices

  1. Use appropriate levels - info for normal output, error for errors
  2. Don't overuse debug - Reserve for troubleshooting
  3. Include context - Log relevant information
  4. Format consistently - Use consistent message formats
  5. Respect verbosity - Don't force output in quiet mode
Support

Contribute to our work and keep us going

Community is the heart of open source. The success of our packages wouldn't be possible without the incredible contributions of users, testers, and developers who collaborate with us every day.Want to get involved? Here are some tips on how you can make a meaningful impact on our open source projects.

Ready to help us out?

Be sure to check out the package's contribution guidelines first. They'll walk you through the process on how to properly submit an issue or pull request to our repositories.

Submit a pull request

Found something to improve? Fork the repo, make your changes, and open a PR. We review every contribution and provide feedback to help you get merged.

Good first issues

Simple issues suited for people new to open source development, and often a good place to start working on a package.
View good first issues