Installation

# Preserve existing imports with an npm alias
npm install karma@npm:@stackline/karma@1.0.0
# Or use the scoped package name in your imports
npm install @stackline/karma@1.0.0

Node.js: >= 10. Read the compatibility and maintenance notes before migrating.

Usage and API

The reference below may retain upstream package names. Use the alias installation above to run those imports with this Stackline release.

@stackline/karma

Independent maintenance fork of karma@6.4.4, preserving its API and published type declarations.

npm install @stackline/karma
# Keep existing imports:
npm install karma@npm:@stackline/karma@1.0.0

Stackline · Issues · Community

See UPSTREAM.md for source identity and issue review, and CHANGELOG.md for maintenance changes. Functional tests also run against the final npm tarball; releases are published from GitHub Actions with provenance.

Upstream documentation

Karma

A simple tool that allows you to execute JavaScript code in multiple real browsers.

The main purpose of Karma is to make your test-driven development easy, fast, and fun.

Karma is deprecated and is not accepting new features or general bug fixes.

The web testing space has evolved significantly in the 10+ years since Karma's creation. The web landscape looks very different today and new patterns and tools have emerged in the ecosystem. New test runners offer more performant alternatives, and Karma no longer provides clear unique value.

Based on the current state of the web testing ecosystem, we have made the hard decision to deprecate Karma.

We know Karma is used particularly commonly in the Angular ecosystem, so Angular is adding Jest and Web Test Runner support to provide a migration path off of Karma. See the Angular blog for more details.

Critical security issues in Karma will still be triaged and fixed as necessary. This will continue until 12 months after Angular CLI's Web Test Runner support is marked stable.

For those outside Angular looking to migrate off Karma, both Web Test Runner and jasmine-browser-runner provide browser-based unit testing solutions which can be used as a direct alternative. Jest and Vitest also provide Node-based alternatives.

It has been incredible to see Karma's impact on the web testing ecosystem and we greatly appreciate the support of everyone who contributed to an awesome community. Keep testing. ✅

Help and Support

For questions and support please use the mailing list or Gitter. The issue tracker is for bug reports and feature discussions only.

• Obligatory documentation
• Quick questions:
• Longer questions: Mailing List
• Bug reports Issue Tracker
• Everything less than 140 characters: @JsKarma on Twitter

When should I use Karma?

• You want to test code in real browsers.
• You want to test code in multiple browsers (desktop, mobile, tablets, etc.).
• You want to execute your tests locally during development.
• You want to execute your tests on a continuous integration server.
• You want to execute your tests on every save.
• You love your terminal.
• You don't want your (testing) life to suck.
• You want to use Istanbul to automagically generate coverage reports.
• You want to use RequireJS for your source files.

But I still want to use _insert testing library_

Karma is not a testing framework, nor an assertion library. Karma just launches an HTTP server, and generates the test runner HTML file you probably already know from your favourite testing framework. So for testing purposes you can use pretty much anything you like. There are already plugins for most of the common testing frameworks:

• Jasmine
• Mocha
• QUnit
• and many others

If you can't find an adapter for your favourite framework, don't worry and write your own. It's not that hard and we are here to help.

Which Browsers can I use?

All the major browsers are supported, if you want to know more see the browsers page.

Troubleshooting

See FAQ.

I want to use it. Where do I sign?

You don't need to sign anything but here are some resources to help you to get started...

Obligatory Screencast.

Every serious project has a screencast, so here is ours. Just click here and let the show begin.

Installation.

See installation.

Using it.

See configuration.

This is so great. I want to help.

Please, see contributing.

Why did you create this?

Throughout the development of AngularJS, we've been using JSTD for testing. I really think that JSTD is a great idea. Unfortunately, we had many problems with JSTD, so we decided to write our own test runner based on the same idea. We wanted a simple tool just for executing JavaScript tests that is both stable and fast. That's why we use the awesome Socket.io library and Node.js.

My boss wants a license. So where is it?

MIT License

Upstream issues and maintenance review

Upstream review

Independent maintenance of karma6.4.4. Original history: https://github.com/karma-runner/karma/tree/84f85e7016efc2266fa6b3465f494a3fa151c85c

The original runtime API, CLI name, Node engine range and source notices are retained. Browser assets are rebuilt from the original client/context/common sources with esbuild; no unnecessary cryptographic browser shims are installed in the development environment. Byte hashes of the original npm package and reviewed differences are recorded in .stackline/upstream.json.

Evidence collected: 2026-09-29T00:21:57.433511+00:00. Latest100 open and30 closed issue/PR entries were queried and PRs removed. The table records the59 returned open issues without claiming they were all reproduced or fixed.

Functional validation

The retained suites cover589 server/unit cases,45 client cases in real Chromium, and63 end-to-end scenarios/341 steps including Chromium and Firefox. The modern harness uses native HTTP/2, explicitly trusted2048-bit test certificates, maintained Cucumber/Mocha/Sinon, and the original minimal timer-faking behavior. A user-agent snapshot reflects the compatible updated UA parser no longer treating CPU architecture as the operating-system version.

The final package is extracted and tested with its packaged runtime and browser assets. Full source and runtime audits must report zero findings. The release requires CI/CodeQL, exact tarball identity and npm provenance, valid direct/alias consumers and matching immutable release assets.

The transitive deprecation limitation above is explicit. Only the original portfolio’s direct dependency forks are in scope; this release is not an unrestricted pass of the recursive Production Dependency Closure Policy.

CodeQL follow-up

Completion now matches literal prefixes, and browser return navigation accepts only HTTP(S) URLs that also match an operator-supplied allowlist. Executable/local URLs are rejected even with a permissive pattern. The return navigation feature intentionally permits external HTTP(S) destinations selected by that allowlist. Runtime and test files remain scanned. Test HTTP helpers send explicit plain-text/JSON content types.

The default return-URL pattern permits any HTTP(S) destination. This preserves Karma's optional external return-navigation feature and leaves an open-redirect risk when a crafted return_url query is followed. Operators should restrict allowedReturnUrlPatterns to their intended origins with anchored, escaped hostnames and an authority boundary (including rejection of userinfo or hostname suffixes). Do not use this feature as an authentication callback or a trust decision. CodeQL's redirect alert is retained as a documented compatibility risk, not described as a fixed vulnerability; the script-execution alert is a false positive only after the mandatory HTTP(S) guard. No runtime path or query was excluded from scanning.

Release changes

Changelog

1.0.0

• Start Stackline maintenance of the documented upstream API.

• Preserve and verify published runtime files and TypeScript declarations.

• Run upstream functional suites against both source and the final package.

• Publish the reviewed CI artifact through GitHub Actions with provenance and immutable release evidence.

• Modernize the complete server, browser and end-to-end harness; retain the original functional scenarios.

• Rebuild browser assets with esbuild, removing an unnecessary vulnerable cryptographic browser shim from development dependencies.

• Resolve patched compatible runtime dependencies and explicitly document inherited transitive deprecation warnings outside the requested direct-package scope.

• Exclude the upstream incidental local build log from the published files.

• Treat shell-completion input as a literal prefix and reject non-HTTP(S) return URLs even when a configured pattern is permissive. Keep the operator-controlled return URL allowlist for HTTP(S) navigation.

Release files and references

• README.md
• UPSTREAM.md
• CHANGELOG.md
• LICENSE
• NOTICE
• Package and publication metadata
• Full text documentation

Package bytes, npm provenance and the immutable GitHub release were verified for this version. Security checks describe the reviewed release; documented compatibility risks and upstream reports are not blanket claims of resolution.