error-stack-parser

error-stack-parser is a small, dependency-light JavaScript library that turns the opaque stack string on native Error objects into an array of structured StackFrame instances, each carrying function name, file name, line number, and column number. It normalizes the wildly different stack trace formats produced by V8/Chrome, Internet Explorer, Firefox, Safari, and legacy Opera engines behind a single ErrorStackParser.parse(error) call, so downstream tooling never has to special-case a browser engine directly.

Part of the stacktrace.js family of libraries, it’s built on top of the sibling stackframe package and ships as a UMD bundle usable from AMD, CommonJS/Node, or a plain <script> tag. It’s commonly embedded inside error-reporting and monitoring tools that need consistent stack data before sending it to a backend or rendering it in a dashboard.

What You Get

• A single ErrorStackParser.parse(error) entry point that returns an array of StackFrame objects regardless of browser engine
• Dedicated parsers for V8/Chrome/IE, Firefox/Safari, and three generations of Opera stack formats
• An extractLocation() helper that splits a file:line:column token into its parts, including bare native-code locations
• TypeScript type definitions (error-stack-parser.d.ts) shipped alongside the UMD build
• A prebuilt, minified dist/error-stack-parser.min.js bundle with source map for direct <script> use

Common Use Cases

• Normalizing error stacks before sending them to an error-monitoring/reporting backend
• Building custom in-app crash reporters that need per-frame function/file/line data
• Powering source-mapped stack trace tools like stacktrace-gps
• Debugging tooling that needs consistent stack frames across browser engines in cross-browser test suites

Under The Hood

Architecture The library is a single-file UMD module exposing one flat object literal with a strategy-dispatch design: parse() inspects the shape of the incoming Error (presence of stacktrace/opera#sourceloc, or which regex the stack string matches) to route to the correct engine-specific parser — parseV8OrIE, parseFFOrSafari, or one of parseOpera9/parseOpera10/parseOpera11 — each of which normalizes raw stack lines into StackFrame instances from the sibling stackframe package. There’s no internal state or class hierarchy, just pure functions operating on strings, so the entire design surface is this one factory wrapped in UMD boilerplate for AMD/CommonJS/global usage. Because every downstream consumer (stacktrace-gps, error-monitoring SDKs) depends on the shape of the returned StackFrame array, changing the core dispatch logic or frame fields would ripple into all of them.

Tech Stack Plain ES5 JavaScript with no transpilation step, wrapped in a UMD factory, with a single runtime dependency on stackframe. Testing runs on Karma + Jasmine across a real cross-browser matrix (Chrome, Firefox, IE, Safari, Opera, PhantomJS launchers, plus Sauce Labs in CI). ESLint handles linting, and uglify-es produces the minified dist/ bundle with source maps via a simple cp + uglifyjs npm script rather than a bundler like Webpack or Rollup. Distribution spans npm, Bower, and a raw CDN URL — a packaging style typical of older, widely-embedded JS utility libraries.

Code Quality A real Jasmine test suite exercises V8, Firefox, Safari, IE9-11, and Opera 9/10/11 stack formats, run through Karma across an extensive cross-browser matrix including Sauce Labs in CI. ESLint is configured and enforced in CI ahead of tests, and coverage is uploaded to Coveralls on every push. There’s no TypeScript source — types are hand-maintained in a separate .d.ts file — so there’s no compile-time type safety, only runtime and declaration-level checks. Overall this is a well-tested library for its size, with comprehensive browser-format coverage but limited recent maintenance activity.

API Design The public surface is about as minimal as possible: one entry point, ErrorStackParser.parse(error), with zero configuration and no setup beyond importing the module. It works identically whether consumed via AMD, CommonJS, or a global script tag, and returns structured StackFrame instances with named accessors (functionName, fileName, lineNumber, columnNumber) instead of raw regex captures, which keeps consumer code simple. Hand-shipped TypeScript typings and a short README usage snippet make onboarding fast, though the trade-off for that simplicity is no extensibility hooks — there’s no way to register a custom parser for an unusual stack format without forking the library.