He is like Batman, but for Node.js stack traces

Overview

Stackman

Give Stackman an error and he will give an array of stack frames with extremely detailed information for each frame in the stack trace.

With Stackman you get access to the actual source code and surrounding lines for where the error occurred, you get to know if it happened inside a 3rd party module, in Node.js or in your own code. For a full list of information, check out the API below.

npm Build status js-standard-style sponsor

Install

npm install stackman

Basic usage

var stackman = require('stackman')()

var err = new Error('Oops!')

stackman.callsites(err, function (err, callsites) {
  if (err) throw err

  callsites.forEach(function (callsite) {
    console.log('Error occured in at %s line %d',
      callsite.getFileName(),
      callsite.getLineNumber())
  })
})

Gotchas

error.stack

This module works because V8 (the JavaScript engine behind Node.js) allows us to hook into the stack trace generator function before that stack trace is generated. It's triggered by accessing the .stack property on the Error object, so please don't do that before parsing the error to stackman, else this will not work!

If you want to output the regular stack trace, just do so after parsing the callsites:

// first call stackman.callsites with the error
stackman.callsites(err, function () {...})

// then you can print out the stack trace
console.log(err.stack)

Stackman API

var stackman = Stackman([options])

This module exposes a single function which you must call to get a stackman object.

The function takes an optional options object as its only argument. These are the available options:

  • fileCacheMax - When source files are read from disk, they are kept in memory in an LRU cache to speed up processing of future errors. You can change the max number of files kept in the LRU cache using this property (default: 500)
  • sourceMapCacheMax - When source maps are read from disk, the processed source maps are kept in memory in an LRU cache to speed up processing of future errors. You can change the max number of source maps kept in the LRU cache using this property (default: 100)

stackman.callsites(err[, options], callback)

Given an error object, this function will call the callback with an optional error as the first argument and an array of CallSite objects as the 2nd (a call site is a frame in the stack trace).

Note that any error related to loading or parsing source maps will be suppressed. If a source map related error occurs, Stackman behaves as if the sourcemap option is false.

Options:

  • sourcemap - A boolean specifying if Stackman should look for and process source maps (default: true)

var properties = stackman.properties(err)

Given an error object, this function will return an object containing all the custom properties from the original error object (beside date objects, properties of type object and function are not included in this object).

stackman.sourceContexts(callsites[, options], callback)

Convenience function to get the source context for all call sites in the callsites argument in one go (instead of iterating over the call sites and calling callsite.sourceContext() for each of them).

Calls the callback with an optional error object as the first argument and an array of source context objects as the 2nd. Each element in the context array matches a call site in the callsites array.

Options:

  • lines - Total number of lines of soruce context to be loaded with the call site line in the center (default: 5)
  • inAppLines - Total number of lines of soruce context to be loaded with the call site line in the center if callsite.isApp() is true. Overwrites lines (default: 5)
  • libraryLines - Number of lines of soruce context to be loaded with the call site line in the center if callsite.isApp() is false. Overwrites lines (default: 5)

All node core call sites and call sites where no lines were collected due to the above options being 0, will have the context value null.

CallSite API

A CallSite object is an object provided by the V8 stack trace API representing a frame in the stack trace. Stackman will decorate each CallSite object with custom functions and behavior.

callsite.sourcemap

If source map support is enabled and a source map have been found for the CallSite, this property will be a reference to a SourceMapConsumer object representing the given CallSite.

If set, all functions on the CallSite object will be source map aware. I.e. their return values will be related to the original source code and not the transpiled source code.

var val = callsite.getThis()

Inherited from V8

Returns the value of this.

To maintain restrictions imposed on strict mode functions, frames that have a strict mode function and all frames below (its caller etc.) are not allow to access their receiver and function objects. For those frames, getThis() will return undefined.

var str = callsite.getTypeName()

Inherited from V8

Returns the type of this as a string. This is the name of the function stored in the constructor field of this, if available, otherwise the object's [[Class]] internal property.

var str = callsite.getTypeNameSafely()

A safer version of callsite.getTypeName() that safely handles an exception that sometimes is thrown when using "use strict" in which case null is returned.

var fn = callsite.getFunction()

Inherited from V8

Returns the current function.

To maintain restrictions imposed on strict mode functions, frames that have a strict mode function and all frames below (its caller etc.) are not allow to access their receiver and function objects. For those frames, getFunction() will return undefined.

var str = callsite.getFunctionName()

Inherited from V8

Returns the name of the current function, typically its name property. If a name property is not available an attempt will be made to try to infer a name from the function's context.

var str = callsite.getFunctionNameSanitized()

Guaranteed to always return the most meaningful function name. If none can be determined, the string <anonymous> will be returned.

var str = callsite.getMethodName()

Inherited from V8

Returns the name of the property of this or one of its prototypes that holds the current function.

var str = callsite.getFileName()

Inherited from V8 if callsite.sourcemap is undefined

If this function was defined in a script returns the name of the script.

var str = callsite.getRelativeFileName()

Returns a filename realtive to process.cwd().

var num = callsite.getLineNumber()

Inherited from V8 if callsite.sourcemap is undefined

If this function was defined in a script returns the current line number.

var num = callsite.getColumnNumber()

Inherited from V8 if callsite.sourcemap is undefined

If this function was defined in a script returns the current column number.

var str = callsite.getEvalOrigin()

Inherited from V8

If this function was created using a call to eval returns a CallSite object representing the location where eval was called.

Note that since Node.js v12.11.0, this function returns undefined unless eval was used.

var str = callsite.getModuleName()

Returns the name of the module if isModule() is true. Otherwise returns null.

var bool = callsite.isToplevel()

Inherited from V8

Is this a toplevel invocation, that is, is this the global object?

var bool = callsite.isEval()

Inherited from V8

Does this call take place in code defined by a call to eval?

var bool = callsite.isNative()

Inherited from V8

Is this call in native V8 code?

var bool = callsite.isConstructor()

Inherited from V8

Is this a constructor call?

var bool = callsite.isApp()

Is this inside the app? (i.e. not native, not node code and not a module inside the node_modules directory)

var bool = callsite.isModule()

Is this inside the node_modules directory?

var bool = callsite.isNode()

Is this inside node core?

callsite.sourceContext([lines, ]callback)

Get the source code surrounding the call site line.

If the callsite is a node core call site, the callback will be called with an error.

Arguments:

  • lines - Total number of lines of soruce context to be loaded with the call site line in the center (default: 5)
  • callback - called when the source context have been loaded with an optional error object as the first argument and a source context object as the 2nd

Source Context

The source context objects provided by callsite.sourceContext contains the following properties:

  • pre - The lines before the main callsite line
  • line - The main callsite line
  • post - The lines after the main callsite line

Troubleshooting

To enable debug mode, set the environment variable DEBUG=stackman.

Acknowledgements

This project was kindly sponsored by Elastic.

License

MIT

Comments
  • Add sourcemap support

    Add sourcemap support

    Top o' the morning to you!

    I've been toying with getting Opbeat to report sourcemapped locations for errors over the weekend. It's been a bit of a rough ride, and I'm not sure this is the best way of solving it, but I thought I'd open a PR for discussion, at least.

    Basically, I've made a module (sourcemap-decorate-callsites) which takes a stack of callsites returned by error-callsites and decorates them with sourcemap file/line/column getter functions.

    Originally I intended to just integrate this functionality into either stackman or error-callsites, but having to support both sync and async and due to the nature of having to read various files, extract locations and instantiate sourcemap consumers, it turned out to be a bit of code that would significantly enlarge either module. If you'd rather see this functionality added directly into either of these modules, let me know.

    I figured it would be nice to expose some additional methods from stackman which can return these locations if present, and if not gracefully fall back to non-sourcemapped locations. Again something I'm a little unsure of - one could argue it would be better to return undefined or null if no sourcemap is found, and have the user call getSourceMappedLineNumber() || getLineNumber() where applicable. Thoughts welcome, as with everything else.

    Lastly, I've made use of these functions to extract the context object. This seems to work fairly well.

    There's a multitude of things to discuss here, obviously. Perhaps we should only attempt to extract source maps if you pass a sourcemaps option, for instance, but that opens questions on whether the source map getter functions should be present in that case, or not.

    Regardless of all my questions and doubts on how to best implement it, it does seem to work. With a simple change in opbeat-node paired with these changes in stackman, opbeat logs sourcemapped locations.

    Feedback and thoughts are very welcome.

    opened by rexxars 10
  • Sync API

    Sync API

    This module looks like just what I need (getting context for the nearest call site outside by lib) but being async makes it inapplicable to my use case where I'm wrapping synchronous functions with the possibility of them throwing an error (in which case I'd like to show context around the callsites).

    opened by raine 4
  • Version 2 of the stackman API

    Version 2 of the stackman API

    API changes

    Removed functionality

    • [x] It's no longer possible to get the source context in a synchronous manner
    • [x] It's no longer possible to filter the call site objects
    • [x] Node.js v0.8 is no longer supported

    Changes to the main export

    • [x] Remove support for options.context in main initializer function (use the lines option provided to callsite.sourceContext() instead)
    • [x] Remove support for options.filter in main initializer function
    • [x] Allow internal LRU cache sizes to be configured using options.fileCacheMax and options.sourceMapCacheMax
    • [x] Remove the one function used to previously parse the error object (replace with the separate functions listed below)
    • [x] Add var properties = stackman.properties(err) - Returns an array of properties for the given err (same as stack.properties in the v1 API)
    • [x] Add stackman.callsites(err[, options], callback) - Calls callback with array of callsites for the given err (same as stack.frames in the v1 API)
    • [x] Add stackman.sourceContexts(callsites[, options], callback) - Convenience function to get the source context for all call sites in the callsites argument in one go (instead of iterating over the call sites and calling callsite.sourceContext() for each of them). Calls the callback with an optional error object as the first argument and an array of context objects as the 2nd. Each element in the context array matches a call site in the callsites array. The optional options object will be passed on to callsite.sourceContext().

    CallSite object changes

    • [x] Remove the callsite.context object from call sites
    • [x] Add callsite.sourceContext([options, ]callback) - Options object {lines: 5}
    • [x] Add source map support to stackman.callsites()
    • [x] Add source map support to callsite.sourceContext()
    • [x] Add source map support to callsite.getFileName()
    • [x] Add source map support to callsite.getLineNumber()
    • [x] Add source map support to callsite.getColumnNumber()
    • [x] Add source map support to callsite.getRelativeFileName()
    • [x] Add source map support to callsite.getModuleName()
    • [x] Add source map support to callsite.isApp()
    • [x] Add source map support to callsite.isModule()
    opened by watson 3
  • Plugging into Winston

    Plugging into Winston

    This is terrific, but I'd like to plug this into Winston so we can log caller's file, function/method name and line number from source map. First, how efficient is this and is there a way to get a synchronous response so as to return a formatted string back to Winston? Is there a more efficient method for our purposes than to use stackman? Thanks!

    opened by teddis 1
  • [Snyk] Fix for 1 vulnerable dependencies

    [Snyk] Fix for 1 vulnerable dependencies

    Description

    This PR fixes one or more vulnerable packages in the npm dependencies of this project. See the Snyk test report for more details.

    Snyk Project: watson/stackman:package.json

    Snyk Organization: watson

    Changes included in this PR

    • A Snyk policy (.snyk) file, with updated settings.

    Vulnerabilities that will be fixed

    With a Snyk patch:

    You can read more about Snyk's upgrade and patch logic in Snyk's documentation.

    Check the changes in this PR to ensure they won't cause issues with your project.

    Stay secure, The Snyk team

    Note: You are seeing this because you or someone else with access to this repository has authorised Snyk to open Fix PRs. To review the settings for this Snyk project please go to the project settings page.

    opened by snyk-bot 0
  • [Snyk] Fix for 1 vulnerable dependencies

    [Snyk] Fix for 1 vulnerable dependencies

    This PR fixes one or more vulnerable packages in the npm dependencies of this project. See the Snyk test report for this project for details.

    This PR includes:

    • Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
      • package.json

    Vulnerabilities that will be fixed

    With an upgrade:

    You can read more about Snyk's upgrade and patch logic in Snyk's documentation.

    Check the changes in this PR to ensure they won't cause issues with your project.

    Stay secure, The Snyk team

    opened by watson 0
  • [Snyk] Security upgrade standard from 14.3.4 to 16.0.4

    [Snyk] Security upgrade standard from 14.3.4 to 16.0.4

    Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.

    Changes included in this PR

    • Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
      • package.json

    Vulnerabilities that will be fixed

    With an upgrade:

    Severity | Priority Score (*) | Issue | Breaking Change | Exploit Maturity :-------------------------:|-------------------------|:-------------------------|:-------------------------|:------------------------- high severity | 696/1000
    Why? Proof of Concept exploit, Has a fix available, CVSS 7.5 | Regular Expression Denial of Service (ReDoS)
    SNYK-JS-ANSIREGEX-1583908 | Yes | Proof of Concept

    (*) Note that the real score may have changed since the PR was raised.

    Commit messages
    Package name: standard The new version differs by 202 commits.
    • 208c090 16.0.4
    • 8e9964c Update CHANGELOG.md
    • b9abb84 build(deps): update eslint-plugin-import from ~2.24.0 to ~2.24.2 (#1705)
    • 2bb34ef build(deps): bump eslint-plugin-react from 7.24.0 to 7.25.1 (#1706)
    • 1460685 build(deps): bump eslint-plugin-react from 7.21.5 to 7.24.0 (#1671)
    • da5cd9a ci: add Node.js v16 (#1703)
    • 0aacac1 test: separate internal/external (#1680)
    • f0a6b8e build(deps): bump actions/setup-node from 2.3.0 to 2.4.0 (#1698)
    • ce28f2f build(deps): bump eslint-plugin-import from 2.23.4 to 2.24.0 (#1700)
    • acc70cb build(deps-dev): update tape from ^5.3.0 to ^5.3.1 (#1699)
    • a4569c9 build(deps-dev): update tape requirement from ^5.2.2 to ^5.3.0 (#1693)
    • 33bcbe2 build(deps): bump actions/setup-node from 2.2.0 to 2.3.0 (#1689)
    • 7fc229d build(deps): bump actions/setup-node from 2.1.5 to 2.2.0 (#1683)
    • 546d710 build(deps): bump eslint-plugin-promise to 5.1.0 (#1682)
    • 6b7a0fc build(deps): bump eslint-config-standard from 16.0.2 to 16.0.3 (#1667)
    • a94771e build(deps): bump actions/setup-node from 2 to 2.1.5 (#1660)
    • 60b5613 build(deps): bump actions/checkout from 2 to 2.3.4 (#1659)
    • cf4faf5 build(deps): bump eslint-plugin-import from 2.22.1 to 2.23.4 (#1670)
    • eda2cac build(deps): bump actions/cache from 2.1.5 to 2.1.6 (#1669)
    • b0b00b0 test: disable cerebral/url-mapper (#1679)
    • 093b056 chore: remove typescript files from .pre-commit-hooks.yaml (#1675)
    • c4fa507 rules: attempt to markdown formatting issue
    • 9ea14d6 docs(readme): update brand image and url for Vercel (#1662)
    • c260e24 Merge pull request #1657 from eltociear/patch-1

    See the full diff

    Check the changes in this PR to ensure they won't cause issues with your project.


    Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

    For more information: 🧐 View latest project report

    🛠 Adjust project settings

    📚 Read more about Snyk's upgrade and patch logic

    opened by snyk-bot 0
  • [Snyk] Security upgrade standard from 14.3.4 to 15.0.0

    [Snyk] Security upgrade standard from 14.3.4 to 15.0.0

    Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.

    Changes included in this PR

    • Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
      • package.json

    Vulnerabilities that will be fixed

    With an upgrade:

    Severity | Priority Score (*) | Issue | Breaking Change | Exploit Maturity :-------------------------:|-------------------------|:-------------------------|:-------------------------|:------------------------- high severity | 768/1000
    Why? Proof of Concept exploit, Recently disclosed, Has a fix available, CVSS 7.5 | Regular Expression Denial of Service (ReDoS)
    SNYK-JS-ANSIREGEX-1583908 | Yes | Proof of Concept

    (*) Note that the real score may have changed since the PR was raised.

    Commit messages
    Package name: standard The new version differs by 41 commits.
    • 866a666 package metadata
    • 34a39d2 update authors
    • 5a63a03 15.0.0
    • 36cbcd8 changelog
    • ab0e7a5 update deps
    • 3d0ea44 eslint-config-standard-jsx 9.0.0
    • 8c0513a eslint-config-standard 15.0.0
    • c8c255c changelog
    • 1af9b8a use "Indonesian" since it's the language name
    • c0fd567 remove sponsor link
    • b926ce2 remove spammy standard user link
    • 1cc9df7 changelog
    • 8e06e4f hallmark 3
    • e4c002a bump deps
    • 8bdade1 Merge pull request #1516 from pikadun/patch-1
    • 0c27f99 Merge pull request #1544 from yoga1234/master
    • 59b03fb Merge pull request #1461 from munierujp/update_japanese_docs
    • fd72454 Merge pull request #1545 from logustra/add-jublia-to-users
    • 1de7656 Merge pull request #1547 from kidonng/patch-1
    • 6558034 add 14.3.4 changelog
    • e1fa03e Update eslint to 7.11.0
    • 4a0e8b0 changelog
    • 4a84e61 remove weird whitespace
    • 523f004 Merge pull request #1519 from standard/eslint7

    See the full diff

    Check the changes in this PR to ensure they won't cause issues with your project.


    Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

    For more information: 🧐 View latest project report

    🛠 Adjust project settings

    📚 Read more about Snyk's upgrade and patch logic

    opened by snyk-bot 0
  • `properties` throws `RangeError: Invalid time value` when the error object has field of type `Date` with value `Invalid Date`

    `properties` throws `RangeError: Invalid time value` when the error object has field of type `Date` with value `Invalid Date`

    If you call the properties method on an error object that has a field of type Date with a value Invalid Date, it tries to call the toISOString method of this object and throws an error: RangeError: Invalid time value.

    To reproduce this, do the following:

    var stackman = require('stackman')()
    
    var err = new Error('Oops!')
    err.number = Number.NaN;
    err.date = new Date('invalid')
    
    var props = stackman.properties(err)
    console.log(props)
    

    If you comment out err.date = new Date('invalid') or change the value to a valid date, the code works.

    opened by nedyalkov 0
  • Stackman does not resolve filename (path) of sourcemap generated by webpack

    Stackman does not resolve filename (path) of sourcemap generated by webpack

    Description of the issue

    Stackman generate a wrong filepath when the sourcemap is generated with Webpack and using webpack:// URLs.

    For example, the error triggered when using elastic-apm-node with Webpack & Typescript:

    [...]
    this.apmAgent.captureError(err);
    [...]
    
    error while getting callsite source context: ENOENT: no such file or directory, open '/home/kerwan/workspace/kmp-agency/kmp-flow-launcher/dist/webpack:/boilerplate-node-typescript/src/launchers/webhooks/webhook.launcher.ts'
    error while getting callsite source context: ENOENT: no such file or directory, open '/home/kerwan/workspace/kmp-agency/kmp-flow-launcher/dist/webpack:/boilerplate-node-typescript/src/launchers/webhooks/abstract-webhook.launcher.ts'
    error while getting callsite source context: ENOENT: no such file or directory, open '/home/kerwan/workspace/kmp-agency/kmp-flow-launcher/dist/webpack:/boilerplate-node-typescript/src/services/webpack:/boilerplate-node-typescript/src/app.ts'
    error while getting callsite source context: ENOENT: no such file or directory, open '/home/kerwan/workspace/kmp-agency/kmp-flow-launcher/dist/webpack:/boilerplate-node-typescript/src/services/webpack:/boilerplate-node-typescript/src/app.ts'
    

    For example, the sourcemap URL for webpack://boilerplate-node-typescript/./src/launchers/abstract-launcher.ts is resolved to /home/kerwan/workspace/kmp-agency/kmp-flow-launcher/dist/webpack:/boilerplate-node-typescript/src/launchers/webhooks/webhook.launcher.ts when it should be /home/kerwan/workspace/kmp-agency/kmp-flow-launcher/src/launchers/webhooks/webhook.launcher.ts.

    Steps to reproduce

    Setup a project with webpack, typescript and ts-loader with the following configuration:

    package.json:

    {
      [...]
      "devDependencies": {
        "ts-loader": "^8.0.11",
        "typescript": "^4.1.2",
        "webpack": "^5.10.0",
        "webpack-cli": "^4.2.0",
      },
      "dependencies": {
        "stackman": "^4.0.1"
      }
      [...]
    }
    

    webpack.config.js:

    const path = require('path')
    
    const {NODE_ENV} = process.env
    
    module.exports = {
      mode: NODE_ENV,
      target: 'node',
      devtool: 'source-map',
      entry: path.resolve(__dirname, 'src/app.ts'),
      output: {
        path: path.resolve(__dirname, 'dist'),
      },
      module: {
        rules: [
          {
            test: /.ts$/,
            include: /src/,
            loader: 'ts-loader'
          }
        ]
      },
      resolve: {
        extensions: ['.ts', '.js', '.json']
      },
    }
    

    With this configuration it will generate in the folder dist the file main.js and the sourcemap main.js.map.

    Workaround

    Temporarily, we have changed the devtool config in webpack to use relative paths without the namespace:

    module.exports = {
      output: {
        path: path.resolve(__dirname, 'dist'),
        devtoolFallbackModuleFilenameTemplate: '../[resource-path]',
        devtoolModuleFilenameTemplate: '../[resource-path]'
      },
    }
    
    opened by kerwanp 0
  • fix: support file:// protocol seen in node14 ESM modules

    fix: support file:// protocol seen in node14 ESM modules

    Hi! I've been testing ESM support for a work project, and noticed that filenames in stack traces were prefixed by file://. As a result, getSourceContext would return empty results, while getRelativeFileName was unable to properly truncate the filename. This change appears to fix the issue.

    I've added some pretty bare-bones tests to assert that the change works. I rearranged package.json a bit to get it to work (moving standard to npm run lint, run as a posttest command) but please discard that change if it's not your cup of tea!

    opened by chrisdickinson 0
  • Async function error stack trace

    Async function error stack trace

    Hi, I'm using Elastic APM in our node projects and I found it lose stack trace when an async function throws an error. In the source code I found the error stack is first handled by stackman, and the frames will lose "From previous event" part. I found if frames length is 0, error will be handled by error-stack-parser, and the error stack can be parsed correctly. So can the stckman also add this feature? Async functions are very commonly in node.js. code like this:

    const id = someAsyncFunction();
    anotherFunction(id);
    

    error like this:

    nodejs.unhandledRejectionError: Invalid value Promise { <pending> }
        at Object.escape (/node_modules/sequelize/lib/sql-string.js:65:11)
        ......
        at processImmediate (internal/timers.js:439:21)
    From previous event:
        at Function.findAll (/node_modules/sequelize/lib/model.js:1755:8)
        ......
    name: "unhandledRejectionError"
    
    opened by wsl-fe 0
Owner
Thomas Watson
Computer programmer, Node.js Core member, open source hacker and Node.js dev at @elastic, formerly @opbeat
Thomas Watson
Node is running but you don't know why? why-is-node-running is here to help you.

why-is-node-running Node is running but you don't know why? why-is-node-running is here to help you. Installation Node 8 and above: npm i why-is-node-

Mathias Buus 1.5k Dec 30, 2022
A tiny JavaScript debugging utility modelled after Node.js core's debugging technique. Works in Node.js and web browsers

debug A tiny JavaScript debugging utility modelled after Node.js core's debugging technique. Works in Node.js and web browsers. Installation $ npm ins

Sloth 10.5k Dec 30, 2022
An lldb plugin for Node.js and V8, which enables inspection of JavaScript states for insights into Node.js processes and their core dumps.

Node.js v10.x+ C++ plugin for the LLDB debugger. The llnode plugin adds the ability to inspect JavaScript stack frames, objects, source code and more

Node.js 1k Dec 14, 2022
Node.js debugger based on Blink Developer Tools

Node Inspector Overview Node Inspector is a debugger interface for Node.js applications that uses the Blink Developer Tools (formerly WebKit Web Inspe

null 12.6k Dec 29, 2022
ndb is an improved debugging experience for Node.js, enabled by Chrome DevTools

ndb ndb is an improved debugging experience for Node.js, enabled by Chrome DevTools Installation Compatibility: ndb requires Node >=8.0.0. It works be

null 10.8k Dec 28, 2022
[OBSOLETE] runs Node.js programs through Chromium DevTools

devtool ⚠️ Update: This tool is mostly obsolete as much of the philosophy has been brought into Node/DevTool core, see here for details. If you wish t

Jam3 3.8k Dec 20, 2022
Debug Node.js code with Chrome Developer Tools.

Debug Node.js code with Chrome Developer Tools on Linux, Windows and OS X. This software aims to make things easier ?? . With ironNode you have the fu

Stephan Ahlf 2.3k Dec 30, 2022
🐛 Memory leak testing for node.

Leakage - Memory Leak Testing for Node Write leakage tests using Mocha or another test runner of your choice. Does not only support spotting and fixin

Andy Wermke 1.6k Dec 28, 2022
API Observability. Trace API calls and Monitor API performance, health and usage statistics in Node.js Microservices.

swagger-stats | API Observability https://swaggerstats.io | Guide Trace API calls and Monitor API performance, health and usage statistics in Node.js

slana.tech 773 Jan 4, 2023
A Node.js tracing and instrumentation utility

njsTrace - Instrumentation and Tracing njstrace lets you easily instrument and trace you code, see all function calls, arguments, return values, as we

Yuval 354 Dec 29, 2022
Locus is a debugging module for node.js

ʆ Locus Locus is a debugging module which allows you to execute commands at runtime via a REPL. Installing npm install locus --save-dev Using require(

Ali Davut 300 Nov 13, 2022
Streamline Your Node.js Debugging Workflow with Chromium (Chrome, Edge, More) DevTools.

NiM (Node.js --inspector Manager) Streamlines your development process Google Chrome Web Store (works with any Chromium browsers: Google's Chrome, Mic

Will 188 Dec 28, 2022
thetool is a CLI tool to capture different cpu, memory and other profiles for your node app in Chrome DevTools friendly format

thetool thetool is a CLI tool to capture different cpu, memory and other profiles for your node app in Chrome DevTools friendly format. Quick start np

null 200 Oct 28, 2022
Long stack traces for node.js inspired by https://github.com/tlrobinson/long-stack-traces

longjohn Long stack traces for node.js with configurable call trace length Inspiration I wrote this while trying to add long-stack-traces to my server

Matt Insler 815 Dec 23, 2022
Grupprojekt för kurserna 'Javascript med Ramverk' och 'Agil Utveckling'

JavaScript-med-Ramverk-Laboration-3 Grupprojektet för kurserna Javascript med Ramverk och Agil Utveckling. Utvecklingsguide För information om hur utv

Svante Jonsson IT-Högskolan 3 May 18, 2022
Hemsida för personer i Sverige som kan och vill erbjuda boende till människor på flykt

Getting Started with Create React App This project was bootstrapped with Create React App. Available Scripts In the project directory, you can run: np

null 4 May 3, 2022
Kurs-repo för kursen Webbserver och Databaser

Webbserver och databaser This repository is meant for CME students to access exercises and codealongs that happen throughout the course. I hope you wi

null 14 Jan 3, 2023
Prettier formatting for ?_trace=1 traces

datasette-pretty-traces Prettier formatting for ?_trace=1 traces Installation Install this plugin in the same environment as Datasette. $ datasette in

Simon Willison 4 May 26, 2022
Introduction to Metrics, Logs and Traces session companion code.

Introduction to Metrics, Logs and Traces in Grafana This is the companion repository to a series of presentations over the three pillars of observabil

Grafana Labs 35 Dec 24, 2022
This is a full-stack exercise tracker web application built using the MERN (MongoDB, ExpressJS, ReactJS, NodeJS) stack. You can easily track your exercises with this Full-Stack Web Application.

Getting Started with Create React App This project was bootstrapped with Create React App. Available Scripts In the project directory, you can run: np

WMouton 2 Dec 25, 2021