Karma with TypeScript

Two Standard Approaches

The dedicated karma-typescript package bundles a TypeScript compiler, module bundler, and (optionally) coverage instrumentation into a single preprocessor, requiring less manual wiring for straightforward projects. The alternative — karma-webpack combined with ts-loader or babel-loader with the TypeScript preset — gives more control and matches whatever webpack setup a project may already use for its production build.

npm install --save-dev karma-typescript typescript

// karma.conf.js
config.set({
  frameworks: ['jasmine', 'karma-typescript'],
  files: ['src/**/*.ts'],
  preprocessors: {
    'src/**/*.ts': ['karma-typescript']
  },
  reporters: ['progress', 'karma-typescript'],
  karmaTypescriptConfig: {
    tsconfig: './tsconfig.json'
  }
});

karma-typescript handles compiling, bundling, and even source maps for .ts files in one integrated preprocessor.

Alternative: karma-webpack + ts-loader

npm install --save-dev karma-webpack webpack ts-loader typescript

// webpack.test.config.js
module.exports = {
  devtool: 'inline-source-map',
  module: {
    rules: [{ test: /\.ts$/, use: 'ts-loader' }]
  },
  resolve: { extensions: ['.ts', '.js'] }
};

• This approach reuses the same karma-webpack setup covered in the previous lesson, just adding ts-loader.
• It's the natural choice if your project already has a mature webpack configuration to extend.
• karma-typescript is often simpler for projects with no existing webpack setup at all.
• Angular CLI projects historically use their own internal build pipeline rather than either approach directly.

TypeScript + Karma Cheat Sheet

Comparing the two standard approaches at a glance.

Respecting an Existing tsconfig.json

Both approaches should point at the project's real tsconfig.json rather than duplicating compiler options in the Karma config, to avoid subtle drift between how the app builds for production and how tests compile.

// karma-typescript approach
karmaTypescriptConfig: {
  tsconfig: './tsconfig.json'
}

// ts-loader approach
{ test: /\.ts$/, use: { loader: 'ts-loader', options: { configFile: 'tsconfig.json' } } }

A Note on Angular Projects Specifically

Angular applications generated by the CLI historically didn't use karma-typescript or a hand-written karma-webpack config directly — the @angular-devkit/build-angular Karma builder manages TypeScript compilation and bundling internally, using the project's existing Angular CLI build pipeline. The patterns in this lesson matter most for non-CLI-managed or custom Karma+TypeScript setups.

Common Mistakes

• Duplicating TypeScript compiler options in Karma config instead of referencing the project's real tsconfig.json.
• Choosing karma-typescript for a project that already has a complex, working webpack build, duplicating effort unnecessarily.
• Assuming Angular CLI projects need one of these two approaches manually — the CLI's builder already handles this internally.
• Forgetting resolve: { extensions: ['.ts', '.js'] } in a webpack-based setup, breaking extensionless imports.

Key Takeaways

• karma-typescript bundles compiling, bundling, and coverage into one preprocessor for simpler projects.
• karma-webpack + ts-loader reuses an existing webpack setup and offers more granular control.
• Both approaches should reference the project's real tsconfig.json rather than duplicating options.
• Angular CLI-managed projects handle TypeScript compilation internally, without needing either approach directly.