A tiny JavaScript debugging utility modelled after Node.js core's debugging technique. Works in Node.js and web browsers

Overview

debug

Build Status Coverage Status Slack OpenCollective OpenCollective

A tiny JavaScript debugging utility modelled after Node.js core's debugging technique. Works in Node.js and web browsers.

Installation

$ npm install debug

Usage

debug exposes a function; simply pass this function the name of your module, and it will return a decorated version of console.error for you to pass debug statements to. This will allow you to toggle the debug output for different parts of your module as well as the module as a whole.

Example app.js:

var debug = require('debug')('http')
  , http = require('http')
  , name = 'My App';

// fake app

debug('booting %o', name);

http.createServer(function(req, res){
  debug(req.method + ' ' + req.url);
  res.end('hello\n');
}).listen(3000, function(){
  debug('listening');
});

// fake worker of some kind

require('./worker');

Example worker.js:

var a = require('debug')('worker:a')
  , b = require('debug')('worker:b');

function work() {
  a('doing lots of uninteresting work');
  setTimeout(work, Math.random() * 1000);
}

work();

function workb() {
  b('doing some work');
  setTimeout(workb, Math.random() * 2000);
}

workb();

The DEBUG environment variable is then used to enable these based on space or comma-delimited names.

Here are some examples:

screen shot 2017-08-08 at 12 53 04 pm

screen shot 2017-08-08 at 12 53 38 pm

screen shot 2017-08-08 at 12 53 25 pm

Windows command prompt notes

CMD

On Windows the environment variable is set using the set command.

set DEBUG=*,-not_this

Example:

set DEBUG=* & node app.js
PowerShell (VS Code default)

PowerShell uses different syntax to set environment variables.

$env:DEBUG = "*,-not_this"

Example:

$env:DEBUG='app';node app.js

Then, run the program to be debugged as usual.

npm script example:

  "windowsDebug": "@powershell -Command $env:DEBUG='*';node app.js",

Namespace Colors

Every debug instance has a color generated for it based on its namespace name. This helps when visually parsing the debug output to identify which debug instance a debug line belongs to.

Node.js

In Node.js, colors are enabled when stderr is a TTY. You also should install the supports-color module alongside debug, otherwise debug will only use a small handful of basic colors.

Web Browser

Colors are also enabled on "Web Inspectors" that understand the %c formatting option. These are WebKit web inspectors, Firefox (since version 31) and the Firebug plugin for Firefox (any version).

Millisecond diff

When actively developing an application it can be useful to see when the time spent between one debug() call and the next. Suppose for example you invoke debug() before requesting a resource, and after as well, the "+NNNms" will show you how much time was spent between calls.

When stdout is not a TTY, Date#toISOString() is used, making it more useful for logging the debug information as shown below:

Conventions

If you're using this in one or more of your libraries, you should use the name of your library so that developers may toggle debugging as desired without guessing names. If you have more than one debuggers you should prefix them with your library name and use ":" to separate features. For example "bodyParser" from Connect would then be "connect:bodyParser". If you append a "*" to the end of your name, it will always be enabled regardless of the setting of the DEBUG environment variable. You can then use it for normal output as well as debug output.

Wildcards

The * character may be used as a wildcard. Suppose for example your library has debuggers named "connect:bodyParser", "connect:compress", "connect:session", instead of listing all three with DEBUG=connect:bodyParser,connect:compress,connect:session, you may simply do DEBUG=connect:*, or to run everything using this module simply use DEBUG=*.

You can also exclude specific debuggers by prefixing them with a "-" character. For example, DEBUG=*,-connect:* would include all debuggers except those starting with "connect:".

Environment Variables

When running through Node.js, you can set a few environment variables that will change the behavior of the debug logging:

Name Purpose
DEBUG Enables/disables specific debugging namespaces.
DEBUG_HIDE_DATE Hide date from debug output (non-TTY).
DEBUG_COLORS Whether or not to use colors in the debug output.
DEBUG_DEPTH Object inspection depth.
DEBUG_SHOW_HIDDEN Shows hidden properties on inspected objects.

Note: The environment variables beginning with DEBUG_ end up being converted into an Options object that gets used with %o/%O formatters. See the Node.js documentation for util.inspect() for the complete list.

Formatters

Debug uses printf-style formatting. Below are the officially supported formatters:

Formatter Representation
%O Pretty-print an Object on multiple lines.
%o Pretty-print an Object all on a single line.
%s String.
%d Number (both integer and float).
%j JSON. Replaced with the string '[Circular]' if the argument contains circular references.
%% Single percent sign ('%'). This does not consume an argument.

Custom formatters

You can add custom formatters by extending the debug.formatters object. For example, if you wanted to add support for rendering a Buffer as hex with %h, you could do something like:

const createDebug = require('debug')
createDebug.formatters.h = (v) => {
  return v.toString('hex')
}

// …elsewhere
const debug = createDebug('foo')
debug('this is hex: %h', new Buffer('hello world'))
//   foo this is hex: 68656c6c6f20776f726c6421 +0ms

Browser Support

You can build a browser-ready script using browserify, or just use the browserify-as-a-service build, if you don't want to build it yourself.

Debug's enable state is currently persisted by localStorage. Consider the situation shown below where you have worker:a and worker:b, and wish to debug both. You can enable this using localStorage.debug:

localStorage.debug = 'worker:*'

And then refresh the page.

a = debug('worker:a');
b = debug('worker:b');

setInterval(function(){
  a('doing some work');
}, 1000);

setInterval(function(){
  b('doing some work');
}, 1200);

Output streams

By default debug will log to stderr, however this can be configured per-namespace by overriding the log method:

Example stdout.js:

var debug = require('debug');
var error = debug('app:error');

// by default stderr is used
error('goes to stderr!');

var log = debug('app:log');
// set this namespace to log via console.log
log.log = console.log.bind(console); // don't forget to bind to console!
log('goes to stdout');
error('still goes to stderr!');

// set all output to go via console.info
// overrides all per-namespace log settings
debug.log = console.info.bind(console);
error('now goes to stdout via console.info');
log('still goes to stdout, but via console.info now');

Extend

You can simply extend debugger

const log = require('debug')('auth');

//creates new debug instance with extended namespace
const logSign = log.extend('sign');
const logLogin = log.extend('login');

log('hello'); // auth hello
logSign('hello'); //auth:sign hello
logLogin('hello'); //auth:login hello

Set dynamically

You can also enable debug dynamically by calling the enable() method :

let debug = require('debug');

console.log(1, debug.enabled('test'));

debug.enable('test');
console.log(2, debug.enabled('test'));

debug.disable();
console.log(3, debug.enabled('test'));

print :

1 false
2 true
3 false

Usage :
enable(namespaces)
namespaces can include modes separated by a colon and wildcards.

Note that calling enable() completely overrides previously set DEBUG variable :

$ DEBUG=foo node -e 'var dbg = require("debug"); dbg.enable("bar"); console.log(dbg.enabled("foo"))'
=> false

disable()

Will disable all namespaces. The functions returns the namespaces currently enabled (and skipped). This can be useful if you want to disable debugging temporarily without knowing what was enabled to begin with.

For example:

let debug = require('debug');
debug.enable('foo:*,-foo:bar');
let namespaces = debug.disable();
debug.enable(namespaces);

Note: There is no guarantee that the string will be identical to the initial enable string, but semantically they will be identical.

Checking whether a debug target is enabled

After you've created a debug instance, you can determine whether or not it is enabled by checking the enabled property:

const debug = require('debug')('http');

if (debug.enabled) {
  // do stuff...
}

You can also manually toggle this property to force the debug instance to be enabled or disabled.

Authors

  • TJ Holowaychuk
  • Nathan Rajlich
  • Andrew Rhyne

Backers

Support us with a monthly donation and help us continue our activities. [Become a backer]

Sponsors

Become a sponsor and get your logo on our README on Github with a link to your site. [Become a sponsor]

License

(The MIT License)

Copyright (c) 2014-2017 TJ Holowaychuk <[email protected]>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Comments
  • RFC: 3.0 API & Ideas

    RFC: 3.0 API & Ideas

    Hey everyone,

    I figured it's time to start discussing the API for V3.

    A few fundamental ideas to get started:

    • (No) Code written in ES2015 (minimal transpilation?, no es6 modules)
    • (Yes) Robust test coverage
    • (Yes) XO Code Styling
    • (Yes) "Replaceable middleware" pattern for formatting, output, etc. Extensible. This allows hooks for stuff like logstash and client-to-server log streaming as desired. Middleware is FIFO and debug comes with a default set for formatting, output, environment adaptation, etc. Ex:
     //Stdout would be default console.log middleware
    import debug, { StdoutMiddleware } from 'debug';
    // Add some sort of new middleware element
    log.use((data, next) => ... )
    // replace Stdout (console.log) with console.info at same position in middleware array
    log.replace(StdoutMiddleware, (data, next) => {
      console.info.apply(console, data);
      next(); 
    });
    
    
    • (Yes) "Child" debug instances (which inherit middleware from parent debug instances). Ex:
    const log1 = debug('foo');
    log1.use((data, next) => ... );
    const log2 = log.child('bar');
    log2('hello world'); // => foo:bar hello world
    
    • (Yes) Formal organized schema for CHANGELOG.md

    • (Yes) Dead-simple generated documentation

    • (Yes) Time locale configuration

    • (Yes) Stdout moved off of APIs that are pending removal (https://github.com/visionmedia/debug/issues/280)

    • (No) Ability to enable/disable debug instances

    • (Maybe) API to overwrite/set environment variables by key (https://github.com/visionmedia/debug/issues/277)

    Any other ideas are welcome. I'd love to have a completed first pass draft by the end of next week.

    discussion 
    opened by thebigredgeek 95
  • DEBUG_FD warning (from this project?)

    DEBUG_FD warning (from this project?)

    I have process.on('warning') logging stuff in a project, I got this today, brand new:

    
    (node:29558) DeprecationWarning: `DEBUG_FD` is deprecated. Override `debug.log` if you want to use a different log function (https://git.io/vMUyr)
    
      => Live-Mutex warning =>  DeprecationWarning: `DEBUG_FD` is deprecated. Override `debug.log` if you want to use a different log function (https://git.io/vMUyr)
        at Object.<anonymous> (/home/oleg/WebstormProjects/oresoftware/observable-persistent-queue/node_modules/debug/src/node.js:62:148)
        at Module._compile (module.js:571:32)
        at Object.Module._extensions..js (module.js:580:10)
        at Module.load (module.js:488:32)
        at tryModuleLoad (module.js:447:12)
        at Function.Module._load (module.js:439:3)
        at Module.require (module.js:498:17)
        at require (internal/module.js:20:19)
        at Object.<anonymous> (/home/oleg/WebstormProjects/oresoftware/observable-persistent-queue/node_modules/debug/src/index.js:9:20)
        at Module._compile (module.js:571:32) 
    

    the git.io link links to this project, but otherwise I am not sure what to do. Can you help? thanks

    opened by ORESoftware 38
  • Add optional dynamic debug instances (react on enable() and disable() once created)

    Add optional dynamic debug instances (react on enable() and disable() once created)

    First of all: this PR is 100% compliant with the current design and adds zero overhead to it. This is, no changes must be done in apps and libraries already using the debug module, and the performance is the same as before.

    This PR adds "dynamic debug instances" which are created by passing true as the second parameter to the module exported function:

    var debug = require('debug');
    var applog = debug('myApp', true);
    

    Those instances do properly react if debug.enable(xxxx) or debug.disable() is called after they are created.

    An usage example is provided in the example/ folder.

    The PR also resets exports.names and exports.skips when enable() or disable() is called (rationale here).

    Related issues:

    • https://github.com/visionmedia/debug/issues/150
    • https://github.com/visionmedia/debug/issues/154
    discussion feature change-major 
    opened by ibc 24
  • memory leak when instance is created inside a function.

    memory leak when instance is created inside a function.

    Hi, I just noticed that when you create debug instance in a function, it is starting to leak the memory without freeing. Here's how you can reproduce it:

    const debug = require('debug');
    
    const loop = () => {
      const d = debug('namespace:that:i:want:for:this:function');
      d('hello world');
      setImmediate(loop);
    };
    
    loop();
    

    If you run this and look at memory, it is leaking a lot without freeing them. also does not matter if I set environment to DEBUG=* or not, it still leaks. Any thoughts?

    EDIT: tested on 3.1.1 and 4.1.1 as well (had 3.1.1 version and then I upgraded to latest one to check if it was fixed).

    EDIT2: using node version 10.13 and Windows 10 x64.

    bug 
    opened by overflowz 22
  • Not showing different color on each log

    Not showing different color on each log

    In app.js file I define debug like below.

    var debug = require('debug')('Project1:app');
    debug('test app.js');
    

    I used window system to first define env like set DEBUG=Project1:*

    Its showing log without different colors for each log line. Only showing all log white white color

    debug version: "debug": "^2.6.6",
    
    opened by vijaypatoliya 21
  • debug no longer works with browserify

    debug no longer works with browserify

    Any version of debug that I use past version 3.1.0 gives this error when trying to browserify code that includes this module

    Cannot find module './common' from '[redacted]/node_modules/debug/dist'
          at FSReqWrap.oncomplete (fs.js:154:21)
    

    There was a mention in #603 about a browserify incompatibility, but it doesn't appear to be the same issue.

    bug 
    opened by wraithgar 20
  • Cannot use debug with Rollup

    Cannot use debug with Rollup

    There're a troubles both using debug directly (via import debug from 'debug') and as a dependency to another package, with Rollup bundler.

    1. import debug from 'debug':

    Non-existent export 'default' is imported from node_modules/debug/src/browser.js

    I believe this is because of that dynamic stuff.

    1. import SocketIo from 'socket.io-client' which has debug as a dependency:

    'default' is not exported by 'node_modules/socket.io-client/node_modules/debug/src/browser.js'

    As far as I understood, the main idea behind browser.js is to import kinda «base» debug object and upgrade it with browser-specific methods' implementations. I believe this can be rewritten in more static and bundler-friendly way. Like requiring base, propagate it with methods and then export as a default in different statements which would simplify the analysis by Rollup and other-like.

    I'm not an active debug user, but debug is very popular tool, so many of my packages' of choice using it as a dependency. So I stumble upon it when bundling, from time to time. Leveraging any workarounds is diffcult, since I do not have precision control over dependencies of my dependencies.

    opened by StreetStrider 20
  • Why not include 'dist' folder in npm package?

    Why not include 'dist' folder in npm package?

    When i use webpack to compile file, console show these error message.

    ERROR in debug (bower component)
    Module not found: Error: Cannot resolve 'file' or 'directory' ./dist/debug.js in /Users/stevenjlho/Work/v4s/htdocs/node_modules/debug
    @ debug (bower component) 1:17-43
    

    Npm package version is 2.2.0.

    opened by stevenjlho 20
  • Doesn't work with dotenv anymore.

    Doesn't work with dotenv anymore.

    The following code snippet works with the version 3.2.6 but it doesn't work with 4.1.1.

    import dotenv from 'dotenv';
    
    dotenv.config();
    
    const debug = require('debug');
    
    const log = debug('app');
    log('Something');
    

    I've checked the 4.x change logs but I couldn't find anything related to this.

    opened by botond-veress 18
  • Add ability to format `debug` as JSON output

    Add ability to format `debug` as JSON output

    I'd like there to be an option (controllable using environment variables) that would make debug module print JSON output instead of plain text.

    This at the moment can be achieved using a module such as debug-to-json (@ping yoshuawuyts). The problem with the pipe solution is that it is not always easy to modify the command used to start the program (e.g. How to append an argument to a container command?).

    Maybe I am doing something wrong, but (in a large deployment) logs coming via debug are quite useless ("large deployment" being a Kubernetes cluster with filebeat + ELK used for logging). [I suppose it is possible to reconize debug output in logstash and convert it to JSON?]

    Being able to configure debug output with environment variable would greatly alleviate the difficulty of log processing here, e.g.

    DEBUG_FORMAT=json
    

    The other thing to note here is that certain log aggregation methods (filebeat) require that logs come in one-per-line. Plain text output does not guarantee this; JSON can.

    Furthermore, the JSON format could be used to supplement debug output with meta information such as package name, version. This can be a controllable option via environment variables too.

    I'd be happy to raise a PR.

    opened by gajus 18
  • Expose enable() & disable() for node.js

    Expose enable() & disable() for node.js

    I have a long running server with repl via socket access - it's very useful for interactive debugging running processes.

    But I would also like to be able to log in into repl and enable/disable some logs without restarting the server with new ENV.

    opened by AlexeyKupershtokh 18
  • Support for console.table like output

    Support for console.table like output

    The format of the output when using console.table in javascript is great. It would be awesome to have the debug function support this format of output for arrays of objects.

    For example, something like this, perhaps with a %t formatter?

    ┌─────────┬──────────────────────────┬───────────┬──────────┬──────────┬───────────┬───────────┬───────┬─────────┬───────┬────────┬───────┬──────┐
    │ (index) │        createdAt         │ creatorId │    x     │    y     │   width   │  height   │ angle │ mediaId │ after │ before │ first │ last │
    ├─────────┼──────────────────────────┼───────────┼──────────┼──────────┼───────────┼───────────┼───────┼─────────┼───────┼────────┼───────┼──────┤
    │    0    │ 2022-12-23T14:56:17.587Z │   null    │ 0.855008 │  0.3881  │ 0.247896  │ 0.371528  │ null  │   20    │   1   │   13   │   1   │  13  │
    │    1    │ 2022-12-23T14:56:18.489Z │   null    │ 0.306923 │ 0.410196 │ 0.356692  │ 0.535038  │ null  │   19    │   2   │   12   │   2   │  12  │
    │    2    │ 2022-12-23T14:56:18.497Z │   null    │ 0.36553  │ 0.323443 │ 0.322601  │ 0.215067  │ null  │   18    │   3   │   11   │   3   │  11  │
    │    3    │ 2022-12-23T14:56:21.602Z │   null    │ 0.513784 │ 0.388415 │ 0.172348  │  0.25726  │ null  │   22    │   4   │   10   │   4   │  10  │
    │    4    │ 2022-12-23T14:56:21.803Z │   null    │ 0.574811 │ 0.303346 │ 0.322601  │ 0.214857  │ null  │   21    │   5   │   9    │   5   │  9   │
    │    5    │ 2022-12-23T14:56:23.526Z │   null    │ 0.138994 │ 0.523832 │ 0.206019  │ 0.309028  │ null  │   22    │   6   │   8    │   6   │  8   │
    │    6    │ 2022-12-23T14:56:24.538Z │   null    │ 0.425821 │ 0.243687 │ 0.322601  │ 0.215067  │ null  │   24    │   7   │   7    │   7   │  7   │
    │    7    │ 2022-12-23T14:56:25.367Z │   null    │ 0.178346 │ 0.544034 │ 0.082702  │ 0.124053  │ null  │   25    │   8   │   6    │   8   │  6   │
    │    8    │ 2022-12-23T14:56:25.727Z │   null    │ 0.611719 │ 0.417708 │ 0.139062  │ 0.185417  │ null  │   27    │   9   │   5    │   9   │  5   │
    │    9    │ 2022-12-23T14:56:28.013Z │   null    │ 0.479497 │ 0.440228 │ 0.166667  │   0.125   │ null  │   28    │  10   │   4    │  10   │  4   │
    │   10    │ 2022-12-23T14:56:29.136Z │   null    │ 0.936887 │ 0.273284 │ 0.064951  │ 0.0866013 │ null  │   29    │  11   │   3    │  11   │  3   │
    │   11    │ 2022-12-23T14:56:32.198Z │   null    │ 0.691942 │ 0.328227 │ 0.0450368 │ 0.060049  │ null  │   30    │  12   │   2    │  12   │  2   │
    │   12    │ 2022-12-23T14:56:32.799Z │   null    │ 0.216912 │ 0.35335  │ 0.064951  │ 0.0866013 │ null  │   30    │  13   │   1    │  13   │  1   │
    └─────────┴──────────────────────────┴───────────┴──────────┴──────────┴───────────┴───────────┴───────┴─────────┴───────┴────────┴───────┴──────┘
    
    opened by robblovell 0
  • namespaces returned by debug.disable are not always accepted by debug.enable

    namespaces returned by debug.disable are not always accepted by debug.enable

    I have seen some strange behavior when temporary disabling the current namespaces, and trying to re-enable the namespaces returned by the debug.disable() call later in the debug.enable() call. This happened while debugging a node-red custom node that I'm working on:

    First I start node-red with some logging enabled: DEBUG="*:error:*" node-red Then using a REST call i fetch the current namespaces as follows:

        RED.httpAdmin.get('/debug', function (req, res) {
            console.log("/debug",req.method);
            var namespaces = debug.disable();
            console.log("/debug",req.method,namespaces);
            debug.enable(namespaces);
            res.end(JSON.stringify(Object({ "namespaces": namespaces })));
        });
    
    

    When this function is called, it prints the following on the console:

    /debug GET
    /debug GET .*?:error:*
    SyntaxError: Invalid regular expression: /^..*??:error:.*?$/: Nothing to repeat
        at new RegExp (<anonymous>)
        at Function.enable (/home/hurenkam/Workspace/node-red-contrib-mh-hue/node_modules/debug/src/common.js:184:28)
        at /home/hurenkam/Workspace/node-red-contrib-mh-hue/src/debug.js:21:15
        at Layer.handle [as handle_request] (/usr/local/lib/node_modules/node-red/node_modules/express/lib/router/layer.js:95:5)
        at next (/usr/local/lib/node_modules/node-red/node_modules/express/lib/router/route.js:144:13)
        at Route.dispatch (/usr/local/lib/node_modules/node-red/node_modules/express/lib/router/route.js:114:3)
        at Layer.handle [as handle_request] (/usr/local/lib/node_modules/node-red/node_modules/express/lib/router/layer.js:95:5)
        at /usr/local/lib/node_modules/node-red/node_modules/express/lib/router/index.js:284:15
        at Function.process_params (/usr/local/lib/node_modules/node-red/node_modules/express/lib/router/index.js:346:12)
        at next (/usr/local/lib/node_modules/node-red/node_modules/express/lib/router/index.js:280:10)
    
    

    It would seem that the wildcard namespace "*:error:*" is being translated to ".*?:error:*" which when fed back into debug.enable() triggers an error in common.js @ line 184 when trying to push the expression into a RegExp:

    common.js: 184: createDebug.names.push(new RegExp('^' + namespaces + '$'));

    bug 
    opened by hurenkam 1
  • Doc suggestion: Using `debug` in WebWorkers / SharedWorkers

    Doc suggestion: Using `debug` in WebWorkers / SharedWorkers

    Just a quick note that localStorage isn't available in web workers. The dynamic approach described under "Set dynamically" works fine in this environment but it might be worth adding a sentence or two in the "Browser Support" section of the docs to hint people in the right direction.

    Thanks for a helpful library!

    opened by pvh 0
  • Exploratory PR for backwards-compatible changes & cross-env alignment: timeFormat

    Exploratory PR for backwards-compatible changes & cross-env alignment: timeFormat

    I started this effort because I was in sore need of localized dates (we have Java & Node microservices and it's a pain that one takes into account timezone while the other does not). Then I realized there was a lot more I could do that would be both backwards-compatible, more powerful and more aligned across browser and Node. So this PR:

    • Adds timeFormat option to debug instances, settable as DEBUG_TIME_FORMAT env var
    • Deprecates hideDate option, equated to timeFormat === 'none'
    • Allows timeFormat of choice: none, iso, diff, or localized (taking into account process.env.TZ in Node, and timezoneOffset in browser)
    • Normalizes behavior across browser & Node: all timeFormats are available in both, but the defaults are kept as-is.
    • Deprecates createDebug.humanize as public member and adds createDebug.withTimeFormat helper instead
    • Documents this in the README.
    • Adds debug format tests that are compatible with browser & Node.

    @Qix- I was surprised at how outdated (dev)Dependencies are and was unable to run npm test (only mocha test.js directly), and dind't find any CI script. The browserify build was not documented so I added an NPM script for it.. It may be useful to add it to the NPM files for those of us wanting to use debug in the browser by copying the dist to an asset folder. I think this change is fully backwards-compatible (at least all tests succeed including the 5 new ones I added)

    opened by webketje 0
  • Reroute logging of an npm package that uses debug to a different logging function

    Reroute logging of an npm package that uses debug to a different logging function

    I am using socket.io, which in turn uses debug for its logging needs. While it's nice that that means I can easily turn on/off logging via an environment variable, I am a bit stumped on how to get it to log to anywhere else but console.log. I am describing my use case (and what I tried and failed to do) here: https://github.com/socketio/socket.io/issues/4482

    While this might in the end be a problem that has to somehow be solved in the socket.io package, I wanted to ask here too, in case there is any easy way to do this myself from the outside.

    opened by TobiasWehrum 0
  • Float's are truncated

    Float's are truncated

    The %d formatter coerces any floating point number such as 0.3123 to an integer.

    The documentation should mention this.

    The only way I could find to print the full number is to use %o .

    It would be nice to have better printf style control e.g. %d3 to print 3 sig figures.

    opened by weepy 6
Releases(4.3.4)
  • 4.3.4(Mar 17, 2022)

    What's Changed

    • Add section about configuring JS console to show debug messages by @gitname in https://github.com/debug-js/debug/pull/866
    • Replace deprecated String.prototype.substr() by @CommanderRoot in https://github.com/debug-js/debug/pull/876

    New Contributors

    • @gitname made their first contribution in https://github.com/debug-js/debug/pull/866
    • @CommanderRoot made their first contribution in https://github.com/debug-js/debug/pull/876

    Full Changelog: https://github.com/debug-js/debug/compare/4.3.3...4.3.4

    Source code(tar.gz)
    Source code(zip)
  • 4.3.3(Nov 27, 2021)

    Patch Release 4.3.3

    This is a documentation-only release. Further, the repository was transferred. Please see notes below.

    • Migrates repository from https://github.com/visionmedia/debug to https://github.com/debug-js/debug. Please see notes below as to why this change was made.
    • Updates repository maintainership information
    • Updates the copyright (no license terms change has been made)
    • Removes accidental epizeuxis (#828)
    • Adds README section regarding usage in child procs (#850)

    Thank you to @taylor1791 and @kristofkalocsai for their contributions.


    Repository Migration Information

    I've formatted this as a FAQ, please feel free to open an issue for any additional question and I'll add the response here.

    Q: What impact will this have on me?

    In most cases, you shouldn't notice any change.

    The only exception I can think of is if you pull code directly from https://github.com/visionmedia/debug, e.g. via a "debug": "visionmedia/debug"-type version entry in your package.json - in which case, you should still be fine due to the automatic redirection Github sets up, but you should also update any references as soon as possible.

    Q: What are the security implications of this change?

    If you pull code directly from the old URL, you should update the URL to https://github.com/debug-js/debug as soon as possible. The old organization has many approved owners and thus a new repository could (in theory) be created at the old URL, circumventing Github's automatic redirect that is in place now and serving malicious code. I (@qix-) also wouldn't have access to that repository, so while I don't think it would happen, it's still something to consider.

    Even in such a case, however, the officially released package on npm (debug) would not be affected. That package is still very much under control (even more than it used to be).

    Q: What should I do if I encounter an issue related to the migration?

    Search the issues first to see if someone has already reported it, and then open a new issue if someone has not.

    Q: Why was this done as a 'patch' release? Isn't this breaking?

    No, it shouldn't be breaking. The package on npm shouldn't be affected (aside from this patch release) and any references to the old repository should automatically redirect.

    Thus, according to all of the "APIs" (loosely put) involved, nothing should have broken.

    I understand there are a lot of edge cases so please open issues as needed so I can assist in any way necessary.

    Q: Why was the repository transferred?

    I'll just list them off in no particular order.

    • The old organization was defunct and abandoned.
    • I was not an owner of the old organization and thus could not ban the non-trivial amount of spam users or the few truly abusive users from the org. This hindered my ability to properly maintain this package.
    • The debug ecosystem intends to grow beyond a single package, and since new packages could not be created in the old org (nor did it make sense for them to live there), a new org made the most sense - especially from a security point of view.
    • The old org has way, way too many approved members with push access, for which there was nothing I could do. This presented a pretty sizable security risk given that many packages in recent years have fallen victim to backdoors and the like due to lax security access.

    Q: Was this approved?

    Yes.[archive]

    Q: Do I need to worry about another migration sometime in the future?

    No.

    Source code(tar.gz)
    Source code(zip)
  • 4.3.2(Dec 9, 2020)

  • 4.3.1(Dec 9, 2020)

  • 4.3.0(Sep 22, 2020)

    Minor release

    • Deprecated debugInstance.destroy(). Future major versions will not have this method; please remove it from your codebases as it currently does nothing.
    • Fixed quoted percent sign
    • Fixed memory leak within debug instances that are created dynamically
    Source code(tar.gz)
    Source code(zip)
  • 4.2.0(Sep 22, 2020)

    Minor Release

    • Replaced phantomJS with chrome backend for browser tests
    • Deprecated and later removed Changelog.md in lieu of releases page
    • Removed bower.json (#602)
    • Removed .eslintrc (since we've switched to XO)
    • Removed .coveralls.yml
    • Removed the build system that was in place for various alternate package managers
    • Removed the examples folder (#650)
    • Switched to console.debug in the browser only when it is available (#600)
    • Copied custom logger to namespace extension (#646)
    • Added issue and pull request templates
    • Added "engines" key to package.json
    • Added ability to control selectColor (#747)
    • Updated dependencies
    • Marked supports-color as an optional peer dependency
    Source code(tar.gz)
    Source code(zip)
  • 4.1.1(Dec 22, 2018)

    This backport fixes a bug in coveralls configuration as well as the .extend() function.

    Patches

    • test: only run coveralls on travis (#663, #664, d0e498f159bd425b3403db38c98fe26a345d4dcd)
    • copy custom logger to namespace extension (#646, 57ef085703a0158679cc4a56a4980653b828ce51)
    Source code(tar.gz)
    Source code(zip)
  • 3.2.6(Oct 10, 2018)

    This backport fixes a 4x performance regression when debug is disabled.

    Patches

    • fix: performance issue (f312a8903a3928c43ff1388828d85f4f8407553d) (#625)
    Source code(tar.gz)
    Source code(zip)
  • 4.1.0(Oct 8, 2018)

    Minor Changes

    • migrate Makefile to npm scripts (4236585a40787fe60ed625452163299600df2ce6)
    • feat: Return namespaces string when invoking disable() (7ef8b417a86941372074f749019b9f439a1f6ef6)

    Massive thank you to @mblarsen and @outsideris for knocking out two long-awaited changes.

    Source code(tar.gz)
    Source code(zip)
  • 4.0.1(Sep 12, 2018)

    This patch restores browserify functionality as well as keeping the intended functionality with Unpkg.com.

    Patches

    • fix browserify and supply alternative unpkg entry point (closes #606): 99c95e3d54b07a918ad65bc148a2930ea8bfdd02
    Source code(tar.gz)
    Source code(zip)
  • 4.0.0(Sep 11, 2018)

    A long-awaited release to debug is available now: 4.0.0.

    Due to the delay in release and the number of changes made (including bumping dependencies in order to mitigate vulnerabilities), it is highly recommended maintainers update to the latest package version and test thoroughly.

    This release drops support for Node 4 and 5 in alignment with the Node.js LTS Release Schedule.


    Major Changes

    • move to XO (closes #397): ba8a424d41e9dc6129e081ac3aa9715be6a45fbd
    • add Node.js 10, remove Node.js 4 (#583): 05b0ceb8856bc7b6bb0f2adc3de5cae3cea9c872

    Minor Changes

    • bump vulnerable packages: 853853f9f588044d76df3daf1959ca56c5f341b7
    • Fix nwjs support (#569): 207a6a2d53507ec9dd57c94c46cc7d3dd272306d
    • add instance extends feature (#524): e43e5fed177b8698674748063f4ed1aaba1d59c8
    • Add TVMLKit support (#579): 02b9ea9fd7ec95c42de47da13b4b6bb8e50025d8

    Patches

    • clean up builds: 3ca23316a470f6bc6e0d75d297179cfc19bbc763
    • remove needless command aliases in makefile: 9f4f8f59ba745166b0c014a61c76de5e73d4841a
    • no longer checking for BROWSER=1: 623c08ef73f8211278d5596c88041c65a2a58ee7
    • fix tests: 57cde56e43003f6b404d4b3d9d76b74aafaeeec8
    • clean up makefile: 62822f12668e8a0b1d1a4fd5a1c2fce1d8715da3
    • fix tests: 833b6f84c8f8dc5b6f13da38ab0ef8a8ff86c0c9
    • add .editorconfig: 2d2509e26bf6df1e1954267e3b1a1cb83973fb09
    • add yarn-error.log to .gitignore: 7e1d5d94f31b37b460fb8d88000ab7ed0be3597e
    • Improve usability of Windows notes w/ examples for prompts & npm script (#577): 1ad1e4a79ff36981c1972bb4e61f93c7d4ade68d
    • Drop usage of chrome.storage (or make the storage backend pluggable): 71d2aa77ff54c3c95a000bdead6b710b2a762c3f
    • Detect 'process' package: 225c66f7198d2995e8232f9486aa9e087dc2a469
    • Update ms to 2.1.1 (#539): 22f993216dcdcee07eb0601ea71a917e4925a30a
    • Update .npmignore (#527): a5ca7a20860e78a4ea47f80770c09c0c663bae1e
    • fix colors with supports-color@5: 285dfe10a5c06d4a86176b54bef2d7591eedaf40
    • Document enable() (#517): ab5083f68a7e4c1ab474ff06cd5995d706abf143
    • refactor to make the common code be a setup function (#507): 71169065b5262f9858ac78cc0b688c84a438f290
    • Simplify and improve: da51af8314436ab532c151583f7fd52b2ebf2a3e
    • use babel-ified distributed source for browsers: b3f8f8e683915ef4fae3a77cbcebc6c410e65a8c

    Credits

    Huge thanks to @DanielRuf, @EirikBirkeland, @KyleStay, @Qix-, @abenhamdine, @alexey-pelykh, @DiegoRBaquero, @febbraro, @kwolfy, and @TooTallNate for their help!

    Source code(tar.gz)
    Source code(zip)
  • 3.2.5(Sep 12, 2018)

    This patch restores browserify functionality as well as keeping the intended functionality with Unpkg.com.

    It is a backport of the 4.0.1 release.

    Patches

    • fix browserify and supply alternative unpkg entry point (closes #606): cc5f1463d1c975bcef0b3172b2527ca204ec474d
    Source code(tar.gz)
    Source code(zip)
  • 3.2.4(Sep 11, 2018)

    3.2.4 is DEPRECATED. See https://github.com/visionmedia/debug/issues/603#issuecomment-420237335 for details.

    This released fixed the missing files entry in package.json, mitigating the faulty 3.2.3 release.

    Source code(tar.gz)
    Source code(zip)
  • 3.2.3(Sep 11, 2018)

    3.2.3 is DEPRECATED. See https://github.com/visionmedia/debug/issues/603#issuecomment-420237335 for details.

    This release mitigated the breaking changes introduced in 3.2.0 where ./node.js was removed, breaking a very select few users on older releases of babel-core, as well as users that used an undocumented require('debug/node').

    ./node.js was temporarily added to the repository at this time; however, this release failed to include node.js in the files key in package.json and thus didn't fix the issue. 3.2.4 rectified this issue.

    Source code(tar.gz)
    Source code(zip)
  • 3.2.2(Sep 11, 2018)

    3.2.2 is DEPRECATED. See https://github.com/visionmedia/debug/issues/603#issuecomment-420237335 for details.

    This release mitigated the breaking changes introduced in 3.2.0 where ES6 features were being used on users of Node 4, causing crashes upon inclusion.

    It employed a temporary Babel pass on the entire codebase in lieu of a hard reversion (so this version is, effectively, a backport of the fixes and features ultimately introduced in 4.0.0).

    Source code(tar.gz)
    Source code(zip)
  • 3.2.1(Sep 11, 2018)

    3.2.1 is DEPRECATED. See https://github.com/visionmedia/debug/issues/603#issuecomment-420237335 for details.

    This release, along with 3.2.0, were subsequently released together as 4.0.0 (a major bump). You can review the complete changes in that release's details.


    A quick hotfix to address Browser builds - debug is now compiled down to IE8-compatible code via Babel upon release.

    CDNs that honor the "browser": key in package.json should now reflect these changes (previously, they would serve the non-bundled ES6 version).

    Patches

    • use babel-ified distributed source for browsers: b3f8f8e683915ef4fae3a77cbcebc6c410e65a8c
    Source code(tar.gz)
    Source code(zip)
  • 3.2.0(Sep 11, 2018)

    3.2.0 is DEPRECATED. See https://github.com/visionmedia/debug/issues/603#issuecomment-420237335 for details.

    This release was intended to be the next release of Debug but introduced breaking changes that were overlooked at the time of release. As such it has been deprecated on npm and should not be used.

    This release, along with 3.2.1, were subsequently released together as 4.0.0 (a major bump). You can review the included changes in that release's details.

    Source code(tar.gz)
    Source code(zip)
  • 3.1.0(Sep 26, 2017)

    Minor Changes

    • Ignore package-lock.json: e7e568a24736486721882282eb21beb31c741647
    • Remove component.json: 47747f329fe159e94262318b52b87a48f6c0acd4
    • Remove "component" from package.json: bdb7e0137f84dc8bcfc95daede7c694799d38dbf
    • Add DEBUG_HIDE_DATE env var: #486

    Patches

    • Correct spelling mistake: daf1a7c8c0f62f5dbc8d48158d6748d0527cc551
    • Examples: fix colors printout: 7cd9e539ce571fc3314d34d9d1dac3124839dbac
    • Fix browser detection: fdfa0f5f6cc7e83fd60b6cf1e7b990cbf6388621
    • Remove ReDoS regexp in %o formatter: #504

    Credits

    Huge thanks to @amejiarosario and @zhuangya for their help!

    Source code(tar.gz)
    Source code(zip)
  • 2.6.9(Sep 22, 2017)

  • 3.0.0(Aug 8, 2017)

    Featuring pretty new colors!

    Major Changes

    • Remove DEBUG_FD: #406
    • Make millisecond timer namespace specific and allow 'always enabled' output: #408
    • Use Date#toISOString() instead to Date#toUTCString() when output is not a TTY: #418
    • enabled() updates existing debug instances: #440

    Minor Changes

    • Add destroy() function: #440
    • Document enabled flag: #465
    • Support 256 colors: #481
    • Update "browserify" to v14.4.0: 826fd94639efeaa3c5701b50d335caead084a5d6
    • Separate Node.js and web browser examples: 87880f6ae1f48b12d9f3346bce564a66cba6b93e
    • Example: use %o formatter: 31f3343de76cb8687041387a1b811745c6e84473
    • More readme screenshots replaced: 25eb545324912dd2863658d0ba35426c0f617619
    • Add Namespace Colors section to readme: 8b5c438a222167bd0cc66db046bac073f01b3c01
    • Separate the Node and Browser tests in Travis: f178d861df18abacac6e9e4607c7306a1147bf3d

    Patches

    • Readme: fix typo: #473
    • Component: update "ms" to v2.0.0: d2dd80aeaf1b037f0b3be21838c4594bbedc4a9c

    Credits

    Huge thanks to @gtjoseph, @timruffles and @FantasticFiasco for their help!

    Source code(tar.gz)
    Source code(zip)
  • 2.6.7(May 17, 2017)

  • 2.6.6(Apr 27, 2017)

  • 2.6.5(Apr 27, 2017)

  • 2.6.4(Apr 20, 2017)

  • 2.6.3(Mar 14, 2017)

  • 2.6.2(Mar 10, 2017)

  • 2.6.1(Feb 10, 2017)

  • 2.6.0(Dec 29, 2016)

  • 2.5.2(Dec 26, 2016)

  • 2.5.1(Dec 21, 2016)

Owner
Sloth
New user is /tj
Sloth
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
📡 Encrypt and authenticate DevTools to use it securely remotely. Add HTTPS, and authentication to --remote-debugging-port to debug, inspect and automate from anywhere and collaborate securely on bugs.

?? Encrypt and authenticate DevTools to use it securely remotely. Add HTTPS, and authentication to --remote-debugging-port to debug, inspect and automate from anywhere and collaborate securely on bugs.

Cris 9 May 5, 2022
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
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 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
Dynamic tracing for javascript, in javascript (similar dtrace, ktap etc)

jstrace Dynamic tracing for JavaScript, written in JavaScript, providing you insight into your live nodejs applications, at the process, machine, or c

null 387 Oct 28, 2022
🎸 A rsocket web devtools

rsocketMan ?? A devtool for rsocket protocol ?? Easy to help you to test your rsocket servers ?? Development Environment ?? Installation ?? In rsocket

Frozen FIsh 5 Jul 27, 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
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
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
[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
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
He is like Batman, but for Node.js stack traces

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

Thomas Watson 242 Jan 1, 2023
A pretty darn cool JavaScript debugger for Brackets

Theseus Theseus is a new type of JavaScript debugger for Node.js, Chrome, and both simultaneously. It is an extension for the Brackets code editor. Th

Adobe Research 1.3k Dec 20, 2022
Well-formatted and improved trace system calls and signals (when the debugger does not help)

ctrace Well-formatted and improved trace system calls and signals (when the debugger does not help). Why? Awesome tools strace and dtruss have only on

Aleksandr Komlev 117 Dec 27, 2022
A project to showcase a poc of distributed systems with message queue, graphql, grpc, http server with added monitoring and tracing capabilities.

trace-sandbox Trace sandbox is a project to showcase a poc of distributed systems with message queue, graphql, grpc, http server with added monitoring

Alfian Pramudita 6 Jun 24, 2021