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

easy-attach

v2.0.1

Published

A helper tool that makes launching the debugger to step through obscure node-js scripts (e.g. webpack configurations) extremely easy.

Downloads

10

Readme

Easy Attach

A helper tool that makes launching the debugger to step through node applications where the entry point is unclear (e.g. webpack configurations) extremely easy.

Like Debugger.Break() from C#. Everything the debugger; statement should be.

Why debugger; doesn't do it

debugger; does nothing if no debugger is attached.

This means you have to either launch the process in debug mode from the start (which is complicated if you don't control how the process is launched) or be quick to attach it before the line you want to break at is executed.

With this project you can just paste one line and it will launch a debugger of your choice (VSCode or Chrome) while suspending the running process, regardless of how it was started.

Requirements

Developed on Windows, tested on Windows and Linux.

Installation

easy-attach should best be installed globally:

yarn global add easy-attach

Or if you use npm:

npm install --global easy-attach

Demo

demo

Usage

Run easy-attach to see instructions:

cli

Then, in the script you want to debug, insert the code from the instructions:

function obscureFunction(args) {
	// this require call launches the debugger and waits
	require("C:\\Users\\henni\\AppData\\Local\\Yarn\\Data\\global\\node_modules\\easy-attach\\debugger")();
	anotherObscureFunction(args.data);
}

When the require("[...]\\debugger")() is called, a chrome window is launched with further instructions. By pasting the displayed link into chrome you can debug your node js application! This even works in node repl!

You can also pass a label to the call so that you don't mix up various breakpoints:

require("...\\easy-attach\\debugger")({ label: "Server" });

If you don't want the debugger to halt, you can pass a continue flag:

require("...\\easy-attach\\debugger")({ continue: true });

Flags

You can specify flags by passing an object:

require("...\\easy-attach\\debugger")({ ...flags });

These flags are supported:

export interface EasyAttachArgs {
	/**
	 * Sets a label for the debug target.
	 * Defaults to `undefined`..
	 */
	label?: string;
	/**
	 * If enabled, it does not break after attaching the debugger.
	 * Defaults to `false`.
	 */
	continue?: boolean;
	/**
	 * Specifies the port to use for the debug port.
	 * Use `preconfigured` when the debugger was already launched.
	 * Defaults to `random`;
	 */
	debugPort?: DebugPortConfig;
	/**
	 * Specifies the port to use for the debug proxy.
	 * This is usefull if you want to forward this port.
	 * Defaults to `random`;
	 */
	debugProxyPort?: PortConfig;
	/**
	 * Use this option when the debug proxy does not recognize connection attempts and does not close automatically. Defaults to `false`.
	 */
	eagerExitDebugProxy?: boolean;
	/**
	 * Print logs from background worker. Defaults to `false`.
	 */
	logBackgroundWorker?: boolean;
	/**
	 * Use this option to control whether the UI is shown.
	 * If only the VS Code Extension is used, disabling the UI speeds up the auto attach feature.
	 * Defaults to `true`.
	 */
	showUI?: boolean;
}

export type PortConfig = "random" | number | number[];
export type DebugPortConfig = PortConfig | "preconfigured";

Design Notes

Actually, going from debugger; to C#'s Debugger.Break() was unexpectedly easy (in terms of a node js developer).

This sequence diagram roughly describes what is needed for that little upgrade:

sequence-diagram

background-worker

The background-worker process is required as we don't want to return from the require call before a debugger successfully attached, otherwise we would miss the debugger; breakpoint. Thus, we cannot use the event loop of the debugee and have to spawn a new process and wait for it to exit synchronously.

debugger-proxy

The debugger-proxy is used to inform the background-worker that a debugger has attached. There seems to be no other way. Care has to be taken that is exits neither too early nor never.

Used Dependencies

Utility functions:

For typed communicating between background-worker and debugger-proxy:

For proxying node debug:

For the CLI:

To get the chrome debug url and launch chrome:

To notify vscode:

To find free ports:

Known Problems

  • Sometimes, when launchend, the background-worker appears for a short moment as black terminal window. I don't know why.

Changelog

  • 2.0.0
    • Migrated from _debugProcess to inspector.open. This solves some race conditions.
    • Removed debug entry points.
    • Uses debug API to automatically step out or continue.