Karma Plugins

Automatic Plugin Discovery

By default, Karma automatically loads every installed npm package whose name starts with karma- and lives in your project's dependencies. This is why installing karma-jasmine and listing 'jasmine' in frameworks just works, without ever mentioning karma-jasmine explicitly anywhere in your config.

This convention-based discovery is convenient for typical projects, but large monorepos or projects with many unrelated karma-* packages installed sometimes want tighter, explicit control — that's what the plugins option provides.

// No explicit "plugins" option needed for typical setups —
// installing karma-jasmine and karma-chrome-launcher is enough:
config.set({
  frameworks: ['jasmine'],
  browsers: ['ChromeHeadless']
});

Karma scans installed packages named karma-* automatically; this example needs no plugins array at all.

Explicit Plugin Loading

config.set({
  plugins: [
    'karma-jasmine',
    'karma-chrome-launcher',
    'karma-coverage'
  ]
});

• Listing plugins explicitly disables Karma's automatic karma-* discovery entirely.
• Every plugin your config relies on (frameworks, launchers, reporters, preprocessors) must be listed once explicit mode is on.
• Explicit mode is common in monorepos where many unrelated karma-* packages exist at the root node_modules.
• Custom, locally-defined plugins (not published to npm) can be included directly as plugin objects in this array.

Plugin System Cheat Sheet

Key facts about Karma's plugin discovery and loading.

Why Some Projects List Plugins Explicitly

In a monorepo with dozens of packages, automatic discovery can accidentally load unrelated karma-* plugins from a sibling package's dependencies, occasionally causing subtle conflicts. Listing plugins explicitly makes the configuration self-documenting and immune to unrelated dependency changes elsewhere in the repo.

• Improves clarity — every plugin dependency is visible directly in karma.conf.js.
• Prevents accidental loading of unrelated karma-* packages from elsewhere in a monorepo.
• Makes it obvious, during code review, exactly what a config change requires installing.
• Requires discipline: every new framework/launcher/reporter addition must also be added here.

The Shape of a Custom Plugin

A Karma plugin is ultimately just an object whose keys follow a type:name convention, mapping to factory functions. You'll see this exact shape again when writing custom launchers, reporters, or preprocessors later in this course.

// A minimal custom reporter plugin object
const MyReporterPlugin = {
  'reporter:my-reporter': ['type', function(baseReporterDecorator) {
    baseReporterDecorator(this);
    this.onRunComplete = function(browsers, results) {
      console.log('Custom reporter saw:', results);
    };
  }]
};

module.exports = MyReporterPlugin;

Published karma-* npm packages export exactly this shape; local plugins can too.

Common Mistakes

• Adding an explicit plugins array but forgetting to include a plugin your config still relies on.
• Assuming a plugin is 'installed and working' just because npm install succeeded, without confirming Karma actually loaded it.
• Not recognizing 'Unknown launcher' or 'Unknown framework' errors as plugin-loading problems.
• Publishing or sharing a custom plugin without following the karma- naming convention, breaking auto-discovery for consumers.

Key Takeaways

• Karma automatically discovers and loads any installed karma-* npm package by default.
• An explicit plugins array disables auto-discovery and requires listing every needed plugin.
• All Karma plugin types (frameworks, launchers, reporters, preprocessors) share the same underlying plugin object shape.
• 'Unknown launcher/framework/reporter' errors almost always trace back to a missing or unlisted plugin.