Always use the project's structured logger instead of direct console methods (`console.log`, `console.error`, etc.). This ensures consistent log formatting, proper level-based filtering, and integration with monitoring systems.
Always use the project’s structured logger instead of direct console methods (console.log
, console.error
, etc.). This ensures consistent log formatting, proper level-based filtering, and integration with monitoring systems.
Problems with direct console logging:
Good logging practice:
// AVOID: Direct console logging
console.log('Database pool created'); // Hard to filter out in production
console.error('Error handling streaming chunk:', error); // Bypasses error tracking
// BETTER: Use the structured logger with appropriate levels
this.logger.debug('Database pool created'); // Can be silenced in production
this.logger.info(`Generated workflow for prompt: ${flags.prompt}`); // Informational messages
this.logger.warn('The output file already exists. It will be overwritten.'); // Warnings
this.logger.error(`Error processing prompt "${flags.prompt}": ${errorMessage}`); // Actual errors
For debug-only logging, conditionally log based on environment or debug flags rather than leaving console statements that will always execute:
// BETTER: Conditional debug logging
if (isDebugMode) {
this.logger.debug(`Connection parameters for ${nodeType}:`, warnings);
}
Ensure log levels match the message severity - use error only for actual failures, and info/debug for status messages to prevent false alarms in monitoring systems.
Enter the URL of a public GitHub repository