Logger Interface

Logging output is an additional way to display messages to the end users.

Webpack logger is available to loaders and plugins. Emitting as part of the Stats and configured by the user in webpack configuration.

Benefits of custom logging API in webpack:

• Common place to configure the logging display level
• Logging output exportable as part of the stats.json
• Stats presets affect logging output
• Plugins can affect logging capturing and display level
• When using multiple plugins and loaders they use a common logging solution
• CLI, UI tools for webpack may choose different ways to display logging
• webpack core can emit logging output, e.g. timing data

By introducing webpack logging API we hope to unify the way webpack plugins and loaders emit logs and allow better ways to inspect build problems. Integrated logging solution supports plugins and loaders developers by improving their development experience. Paves the way for non-CLI webpack solutions like dashboards or other UIs.

Examples of how to get and use webpack logger in loaders and plugins

my-webpack-plugin.js

const PLUGIN_NAME = 'my-webpack-plugin';
export class MyWebpackPlugin {
  apply(compiler) {
    // you can access Logger from compiler
    const logger = compiler.getInfrastructureLogger(PLUGIN_NAME);
    logger.log('log from compiler');

    compiler.hooks.compilation.tap(PLUGIN_NAME, (compilation) => {
      // you can also access Logger from compilation
      const logger = compilation.getLogger(PLUGIN_NAME);
      logger.info('log from compilation');
    });
  }
}

my-webpack-loader.js

module.exports = function (source) {
  // you can get Logger with `this.getLogger` in your webpack loaders
  const logger = this.getLogger('my-webpack-loader');
  logger.info('hello Logger');
  return source;
};

As you can see from the above my-webpack-plugin.js example, there're two types of logging methods,

1. compilation.getLogger
2. compiler.getInfrastructureLogger

It's advised to use compilation.getLogger when plugin/logging is related to the compilation, and they will be stored within the stats. For logging that happens outside the compilation cycle, use compiler.getInfrastructureLogger instead.

Logger methods

• logger.error(...): for error messages
• logger.warn(...): for warnings
• logger.info(...): for important information messages. These messages are displayed by default. Only use this for messages that the user really needs to see
• logger.log(...): for unimportant information messages. These messages are displayed only when user had opted-in to see them
• logger.debug(...): for debugging information. These messages are displayed only when user had opted-in to see debug logging for specific modules
• logger.trace(): to display a stack trace. Displayed like logger.debug
• logger.group(...): to group messages. Displayed collapsed like logger.log
• logger.groupEnd(): to end a logging group
• logger.groupCollapsed(...): to group messages together. Displayed collapsed like logger.log. Displayed expanded when logging level is set to 'verbose' or 'debug'.
• logger.status: writes a temporary message, setting a new status, overrides the previous one
• logger.clear(): to print a horizontal line. Displayed like logger.log
• logger.profile(...), logger.profileEnd(...): to capture a profile. Delegated to console.profile when supported

Runtime Logger API

Runtime logger API is only intended to be used as a development tool, it is not intended to be included in production mode.

• const logging = require('webpack/lib/logging/runtime'): to use the logger in runtime, require it directly from webpack
• logging.getLogger('name'): to get individual logger by name
• logging.configureDefaultLogger(...): to override the default logger.

const logging = require('webpack/lib/logging/runtime');
logging.configureDefaultLogger({
  level: 'log',
  debug: /something/,
});

• logging.hooks.log: to apply Plugins to the runtime logger