npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

debug-all

v0.0.0

Published

A debugger that *will* do it all

Downloads

3

Readme

Debug-All

This module has sprung out of a dissatisfaction of all other current modules for debugging, logging, printing, etc. There are some that do color, some that do levels, some that do namespaces, and more. And there are some that do a combination of these. However I could NOT find one that did ALL of them, and some additional features I wanted. So I decided to build my own. How will mine be different? Well...

  • Easy to use

    many of them only have one way of doing things. But I know my preferred way of programming may not be your preferred way. So I will include multiple ways and syntaxes to do the same thing, so we can all build happily.

  • Active

    SOOOO many people have built the exact same logging module! I am starting to think it was a homework assignment! And they all fell into disuse and are not maintained. These modules are sitting on great npm package names too! However, I will be keeping this logger updated and continue adding features for a long time.

  • Feature Full

    All good loggers need this, but many of them stop short of filling out with all the features people want. Even easy features to add. I will be paying attention to feature requests and trying to build anything the people want!

  • Conglomerate

    I will be scouring the features of all other logger, so I can make sure this will be a one-stop-for-all logger module. We will have every feature other loggers have, combined, and then some. I want this to become the #1 logger module on npm, which will be hard, but if I give the people what they want, then we'll see!

So features do we have so far?

Honestly, not much yet. I just started this week (10-10-18), and am adding features in between work and school. But we are going to get there. Here is what we have so far, as basic functionality:

Namespaces

You can add custom loggers with namespaces, to differentiate between several loggin purposes. Like a logger for DataBases, and a logger for Rotues, for example.

Right now there is only one syntax for this, with more coming in the future.

const dbLogger = require('debug-all')('db');
const routesLogger = require('debug-all')('routes');

dbLogger('Something happened with my database');

routesLogger('And now something happened with my routes');

To enable namespace you have three options. The main way is to specify a DEBUG env variable when you run the module. This can be a single namespace, or a comma separated list of them.

DEBUG=db

// OR //

DEBUG=db,routes

More methods listed as features below.

Wildcard Namespace

If you want to see al loggers, which I do a lot, just add a wildcard instead of each namespace.

DEBUG=*

Enabling and Disabling Namespaces

You can also enable and disable namespaces programmatically, very easily.

const dbLogger = require('debug-all')('db');

dbLogger('Trying to use db logger'); // Won't work

dbLogger.enable();

dbLogger('Lets use it now'); // Will work

dbLogger.disable();

dbLogger('Trying it again'); // Won't work

Stack Trace your logging

THIS was a key feature I could not find anywhere else, when it is very simple! I want to see where my program is logging these out. So perhaps if you add a log for some conditional, and then later you see that log, you do not have to remember where it was, you can see the file, the function, and even the line number. You can choose to use none of these, any of them you want, or all of them. Currently there is only one way to enable these, but again...more syntax to come.

So in file app.js:

1: const dbLogger = require('debug-all')('db');
2: 
3: let logFunc = () {
4:    dbLogger('This is logging out somewhere'); 
5: }
6: 
7: logFunc();
8: 
9: dbLogger('This is logging out somewhere else'); 

The above will log out:

db | logFunc() app.js:4 -> This is logging out somewhere
db | Top Level app.js:9 -> This is logging out somewhere else

In reality, these will be colored. Also, notice Top Level. This is what will be the function if it is not in a function, and is just a top level call.

COLORS!

And lots of them! You can pick your own color, or one will be picked for you. And each logger will be its own color. No two will have the same color, and they will keep their colors across program runs. So, unless configured, the namespace 'db' will always be blue, and 'route' will always be red. Here is the syntax if you want to choose your own color:

const dbLogger = require('../../')('db', { colorCode: 163 });
const routeLogger = require('../../')('route', { colorCode: 77 });

dbLogger('Lets see the db color now'); // Now will be pink
routesLogger('Lets see the routes color now'); // Now will be neon green

Remember that since every logger has its own color, the following won't work, and you will get a white log instead.

const dbLogger = require('../../')('db', { colorCode: 163 });
const routeLogger = require('../../')('route', { colorCode: 163 });

dbLogger('Lets see the db color now'); // Now will be pink
routesLogger('Lets see the routes color now'); // Now will be white :(

That's it! (for now)

I can think of a million and one new things to add, and I am excited to add them. However, if you think of anything, please let me know by submitting a issue with my feature request template on github!