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

@debugr/html

v3.0.0-rc.9

Published

Html log handler for Debugr

Downloads

11

Readme

Html Log Handler for Debugr

This Handler will create interactive HTML dump files for each top-level task which contains at least one entry at or above a configured threshold.

Installation

npm install --save @debugr/html

Usage

import { Logger, LogLevel } from '@debugr/core';
import { HtmlHandler } from '@debugr/html';

const globalContext = {
  applicationName: 'example',
};

const logger = new Logger(globalContext, [
  new HtmlHandler({
    outputDir: './log',
  }),
]);

logger.runTask(async () => {
  logger.info('Task started.');
  
  await someWorkBeingDone();
  
  logger.info('Work has been done.');
  
  await moreBoringThingsHappeningInTheBackground();
  
  logger.info('Now it looks as though we\'re finally finished.');
});

How it works

When a task is started, the log handler will create an internal queue for that task. Each time a log entry is added, the handler will check if the entry exceeds the configured threshold, and if it does, the entire queue for the current task is marked to be written upon completion. So tasks which don't produce any log entries above the configured threshold will not create a dump file - e.g. HTTP requests which complete successfully. But if even a single entry exceeds the threshold, the entire log for the task will be written, so that you can debug step by step.

This works even with subtasks - if you e.g. separate the authentication step of a request handler into a subtask, and you log an entry during the subtask which would exceed the threshold, a dump will be created and the entire task tree for the request will be included. Notably, though, each task can have its threshold set independently. Initially each task inherits its threshold from its parent task, with the root task getting its threshold from the log handler options. During the execution of a subtask you can get the log handler instance from the Logger instance using the logger.getPlugin('html') method, and then you can use that instance to set options for the current task - change its threshold or force it to generate or to not generate a dump file regardless of whether there is an entry which exceeds the threshold.

Options

The HtmlHandler constructor accepts an options object as the first or second argument, depending on whether you wish to pass a preconfigured HtmlWriter instance. The default HtmlFileWriter simply writes the dump files into a configured directory, but you can get fancy with your own implementation, e.g. sending the files to a central API.

| Option | Type | Default | Description | |-------------|--------------------------|------------------|------------------------------------------------------------------------------------------------------------------------------------------------| | outputDir | string | | The directory where dump files will be written. Will be created if nonexistent. Required if a HtmlWriter instance is not provided. | | threshold | LogLevel | LogLevel.ERROR | The default threshold which needs to be reached or exceeded in order for a dump file to be generated. | | levelMap | Record<number, string> | | A map of custom log levels to their string representation. | | colorMap | Record<number, string> | | A map of custom log levels to a CSS color which should be used in the generated dumps. |

API

The HtmlHandler class has a couple of interesting methods mentioned above which you can use to influence whether a dump file will be generated for a particular task or subtask. Here they are:

  • handler.setThreshold(threshold: LogLevel): void - This method can change the level at or above which a log entry needs to be in order for a dump file to be generated. Note that it doesn't work retroactively - an entry is compared against the threshold at the time it is logged, so if you increase the threshold after an entry already exceeded the original threshold, the dump file will still be generated; and similarly, if you decrease the threshold, previous entries above the new threshold but below the original will not cause a dump file to be generated.
  • handler.markTaskForWriting(force: boolean = false): void - This method can be used to tell the handler that the current task should generate a dump file, even if no entry matches or exceeds the task's threshold. With the force argument omitted or false the method will only have effect if the task wasn't yet flagged either way - that is, if no entry has yet matched or exceeded the task's threshold and neither handler.markTaskForWriting() nor handler.markTaskIgnored() have been called. With force set to true the task will generate a dump file, no questions asked.
  • handler.markTaskIgnored(force: boolean = false): void - This method does the opposite of handler.markTaskForWriting() - it tells the log handler that regardless of any entries which may reach or exceed the task's threshold the task should not generate a dump file. The force argument behaves just as it does in handler.markTaskForWriting(). Note that due to the fact that any single task which is marked for writing will cause the entire task tree to be written these two methods don't have the exact same effect - meaning that when you call handler.markTaskForWriting() (especially with force set to true), you can be sure that a dump file will be generated, whereas even if you call handler.markTaskIgnored() (even with force set to true), there's no guarantee that a different task won't cause a dump file to be generated. It seems logical and desirable from my perspective, but maybe it doesn't from yours, so I thought I'd elaborate.