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.

Usage in child processes

Due to the way debug detects if the output is a TTY or not, colors are not shown in child processes when stderr is piped. A solution is to pass the DEBUG_COLORS=1 environment variable to the child process.
For example:

worker = fork(WORKER_WRAP_PATH, [workerPath], {
  stdio: [
    /* stdin: */ 0,
    /* stdout: */ 'pipe',
    /* stderr: */ 'pipe',
    'ipc',
  ],
  env: Object.assign({}, process.env, {
    DEBUG_COLORS: 1 // without this settings, colors won't be shown
  }),
});

worker.stderr.pipe(process.stderr, { end: false });

Authors

  • TJ Holowaychuk
  • Nathan Rajlich
  • Andrew Rhyne
  • Josh Junon

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]> Copyright (c) 2018-2021 Josh Junon

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.

Issues
  • 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
  • Please fix the spell mistake in 2.4.0

    Please fix the spell mistake in 2.4.0

    https://github.com/visionmedia/debug/blob/master/debug.js#L126

    https://travis-ci.org/fex-team/node-ral/jobs/183832044

    opened by hefangshi 69
  • 3.2.0 wrongly released as minor version

    3.2.0 wrongly released as minor version

    remove support for node.js v4 is a breaking change, should publish with major version.

    discussion 
    opened by mariodu 45
  • 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
  • Remove ansi decoration

    Remove ansi decoration

    Adding environment variable DEBUG_DISABLE_COLORDECOR=1 disables ansi decoration.

    feature change-minor 
    opened by jabaz 31
  • npm WARN enoent ENOENT: no such file or directory, open '<root>/node_modules/supertest/package.json'

    npm WARN enoent ENOENT: no such file or directory, open '/node_modules/supertest/package.json'

    I installed supertest before installing debug and it fixed this error.

    Maybe make it a dependency of this module?

    opened by joshua-barnett 31
  • 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
  • How can I log info in the chrome devtoll when start nodejs with --inspect

    How can I log info in the chrome devtoll when start nodejs with --inspect

    I know in node environment log use this log function

    function log(...args) {
    	return process.stderr.write(util.format(...args) + '\n');
    }
    

    Messages shown in the terminal is correct.

    But In my app which is build by electron, I want to know log messages only use --inspect to start app, but message will never be shown in the chrome://inspect devtool.

    So, is there a way to do that?

    opened by mqliutie 0
  • feat: add template support

    feat: add template support

    add template strings support image

    opened by suxin2017 1
  • Undocumented ```delete process.env.DEBUG``` when variable is empty

    Undocumented ```delete process.env.DEBUG``` when variable is empty

    I would just like to point out to the fact that when required, debug package will remove the DEBUG env variable if empty.

    I think it would be nice if this is mentioned in the readme, as I feel its a non obvious behavior.

    The use case I noticed this on is:

    command:

    npm install dotenv DEBUG= npx mocha --require bootstrap.js

    files:

    .env DEBUG=*

    bootstrap.js console.log(process.env.DEBUG); require('dotenv').config(); console.log(process.env.DEBUG);

    output:

    undefined // we lost the DEBUG env already '*' // we get .env file DEBUG setting, but we should have gotten '', because dotenv never overrides set env variables (* actually after version 4 I believe)

    problem:

    mocha uses the debug package which deletes the env variable. Our user code in bootstrap.js then has no way of knowing if DEBUG was set to an empty string or not supplied. Therefore we get full debug info instead of none.

    More general - any code used before using process.env.DEBUG might delete the env variable through just depending on the debug package.

    solution

    I propose we either not delete the DEBUG variable or have a section in documentation to explain and suggest maybe using DEBUG=, to disable debug logging.

    bug change-major 
    opened by warriorGod 3
  • not getting any output

    not getting any output

    We upgraded to 4.3.2 and are all of a sudden not getting logs in stderr (using in a node script). The regressions seems to have been caused by #799

    Admittedly we're perhaps using the library not exactly in a way that it was intended to be used. We aren't setting DEBUG environment variable, so process.env.DEBUG is undefined, but our namespaces are named example-namespace* with a trailing *. These were previously logging, now they're not.

    bug 
    opened by twhitbeck 2
  • Upgrade ms to version 2.1.3

    Upgrade ms to version 2.1.3

    This is a minor update only containing stylistic changes: https://github.com/vercel/ms/releases/tag/2.1.3

    It's nice to have so it doesn't show up as an outdated dependency & so it deduplicates with other libraries using it.

    opened by realityking 2
  • node: warn when envvar can't be parsed

    node: warn when envvar can't be parsed

    Just a minimal message to let devs know that their DEBUG_x variable couldn't be parsed

    opened by wmertens 1
  • README: clarify DEBUG_ envvar parsing

    README: clarify DEBUG_ envvar parsing

    I've been using =y without realizing that doesn't work

    opened by wmertens 2
  • Use ESModules instead of module.exports

    Use ESModules instead of module.exports

    Today, debug use module.exports facility. But nodejs and browser can support import / export notation, aka es6 modules. While preparing the v5, why not going into that mode? #656 ?

    opened by jehon 12
  • Fix only replacing wildcard at end in `toNamespace`

    Fix only replacing wildcard at end in `toNamespace`

    The docs state that, when running debug.disable(), it will return the namespaces currently enabled and skipped. They are, however, often malformed. This seems to be because the toNamespace method only replaces a trailing *.

    debug.enable('api:*,-*:verbose,-api:*:verbose');
    const prevConfig = debug.disable();
    console.log(prevConfig); // -> api:*,-.*?:verbose,-api:.*?:verbose
    

    console.log(prevConfig); should have returned api:*,-*:verbose,-api:*:verbose.

    The issue seems to be fixed by removing the $ in the replace regexp in toNamespace.

    It might be nice to improve the following test too:

    describe('rebuild namespaces string (disable)', () => {
    	it('handle names, skips, and wildcards', () => {
    		debug.enable('test,abc*,-abc');
    		const namespaces = debug.disable();
    		assert.deepStrictEqual(namespaces, 'test,abc*,-abc');
    		// ^ could use more tests, maybe: *,test,-test,abc*,*abc,abc:*:xyz,-abc:*:xyz,-*:verbose (etcetera)
    	});
    	// ...
    });
    

    However, for the sake of keeping this PR clean, I haven't added that to this PR.

    opened by Anoesj 2
  • fix(common): escape replaced value

    fix(common): escape replaced value

    Something like this log('I like %O', { name: '%sugar%' }); will cause output incorrect.

    opened by blastZ 4
Releases(4.3.3)
  • 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)
  • 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)
  • 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 [email protected]: 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.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)

  • 2.4.5(Dec 18, 2016)

Owner
Debug.js
Node.js debug package
Debug.js
Litter is a pretty printer library for Go data structures to aid in debugging and testing.

Litter Litter is a pretty printer library for Go data structures to aid in debugging and testing. Litter is provided by Sanity: The Headless CMS Const

Sanity 1.3k Jan 15, 2022
A reference implementation of blockchain in Go to demonstrate how blockchain works. For education purpose.

Mini-Blockchain Mini-Blockchain is a reference design for a blockchain system to demostate a full end2end flow in current blockchain technology. There

codingtmd 35 Dec 22, 2021
Implements a deep pretty printer for Go data structures to aid in debugging

go-spew Go-spew implements a deep pretty printer for Go data structures to aid in debugging. A comprehensive suite of tests with 100% test coverage is

Dave Collins 4.8k Jan 21, 2022
Shikhandi: a tiny load generator for opentelemetry and heavily

shikhandi is a tiny load generator for opentelemetry and heavily inspired by thi

Srikanth Chekuri 1 Dec 21, 2021
gtl - Gemini Tiny Logs - A simple TUI for the tinylog format on gemini

GTL: Gemini Tiny Logs Goal: A TUI for the tinylogs format on the gemini space. See screenshots Installation gtl requires go ≥ 1.16 From Source git clo

bacardi55 15 Dec 5, 2021
Go web monitor - A web monitor with golang

Step Download “go installer” and install on your machine. Open VPN. Go to “web-m

null 0 Jan 6, 2022
common logger utility module in go

Log & Go This is common logging utility tht is implemented only just for fun :) I will be giving the details about how to use this utility to log ever

Yüksel Özdemir 3 Jan 5, 2022
A simple utility tool to profile go code

A simple utility tool to profile go code. Profile timer that works like a stop w

null 1 Dec 18, 2021
BRUS - Parses your web server (e.g. nginx) log files and checks with GreyNoise how much noise your website is exposed to.

BRUS bbbbbb rrrrrr u u sssss b b r r u u s bbbbbb rrrrrr u u sssss b b r r u u s bbbbbb r r

dubs3c 0 Jan 7, 2022
A simple web service for storing text log files

logpaste A minimalist web service for uploading and sharing log files. Run locally go run main.go Run in local Docker container The Docker container a

Michael Lynch 183 Jan 20, 2022
Very powerful server agent for collecting & sending logs & metrics with an easy-to-use web console.

logkit-community 中文版 Introduce Very powerful server agent for collecting & sending logs & metrics with an easy-to-use web console. logkit-community De

Qiniu Cloud 1.2k Jan 13, 2022
Fast, zero config web endpoint change monitor

web monitor fast, zero config web endpoint change monitor. for comparing responses, a selected list of http headers and the full response body is stor

Robin Verton 40 Nov 17, 2021
Port information web scraper written in Go.

Whatport is an open source tool that scrapes port information from SpeedGuide's Port Database Usage whatport [port(s)] (Seperate ports with a space)

Abdelouahab 5 Dec 8, 2021
Wlog: Logging System Desgned For Web

Logging System Desgned For Web Clean This is very clean logging system and easy

AoXiang Li 0 Dec 19, 2021
This is a toolKit/template project for web application/server with Gin, packed common services.

gin-toolKit This is a toolKit/template project for web application/server with Gin, packed common services. These services include fasthttp, xrate, lo

null 9 Jan 7, 2022
The open and composable observability and data visualization platform. Visualize metrics, logs, and traces from multiple sources like Prometheus, Loki, Elasticsearch, InfluxDB, Postgres and many more.

The open-source platform for monitoring and observability. Grafana allows you to query, visualize, alert on and understand your metrics no matter wher

Grafana Labs 46.5k Jan 17, 2022
Gowl is a process management and process monitoring tool at once. An infinite worker pool gives you the ability to control the pool and processes and monitor their status.

Gowl is a process management and process monitoring tool at once. An infinite worker pool gives you the ability to control the pool and processes and monitor their status.

Hamed Yousefi 12 Oct 28, 2021
Simple and configurable Logging in Go, with level, formatters and writers

go-log Logging package similar to log4j for the Golang. Support dynamic log level Support customized formatter TextFormatter JSONFormatter Support mul

Guoqiang Chen 11 Feb 21, 2021
A Go (golang) package providing high-performance asynchronous logging, message filtering by severity and category, and multiple message targets.

ozzo-log Other languages 简体中文 Русский Description ozzo-log is a Go package providing enhanced logging support for Go programs. It has the following fe

Ozzo Framework 118 Jan 11, 2022