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

module-error

v1.0.2

Published

Create errors with code and cause properties

Downloads

577,700

Readme

module-error

Create errors with code and cause properties. Simple and extensible.

npm status node Test Standard Common Changelog

Usage

Works like a regular Error constructor but adds an options argument (as proposal-error-cause does).

const ModuleError = require('module-error')

throw new ModuleError('Message goes here', {
  code: 'EXAMPLE_NOT_FOUND'
})

The primary purpose of ModuleError is to define a code property on the error object following Node.js conventions. It should be set to an uppercase string that uniquely identifies a situation, prefixed with the name of your module (or a collection of modules) to prevent conflicts.

The output looks like this in Node.js (some stack frames omitted for brevity):

ModuleError: Message goes here
    at Object.<anonymous> (/home/app/example.js:5:7)
    at node:internal/main/run_main_module:17:47 {
  code: 'EXAMPLE_NOT_FOUND'
}

The benefit of error codes is that messages can be changed without a semver-major release because your semver contract will be on the codes. Codes can be reused across related modules while allowing individual modules to customize messages. I also prefer it over instanceof MyError logic because codes work cross-realm and when a tree of node_modules contains multiple versions of a module.

To wrap another error:

try {
  JSON.parse(await fs.readFile('state.json'))
} catch (err) {
  throw new ModuleError('Could not load state', {
    code: 'EXAMPLE_INVALID_STATE',
    cause: err
  })
}

If for convenience you want to create subclasses with prepared codes:

class NotFoundError extends ModuleError {
  constructor(message, options) {
    super(message, { ...options, code: 'EXAMPLE_NOT_FOUND' })
  }
}

Then you can do:

throw new NotFoundError('Message goes here')

Under Node.js the stack trace will be adjusted accordingly, to skip the frame containing your error constructor.

API

ModuleError(message, [options])

Constructor to create an error with the provided message string. Options:

  • code (string): if provided, define a code property with this value.
  • cause (Error): if provided, define a cause property with this value. Unlike the spec of proposal-error-cause the property is enumerable so that Node.js (v16 at the time of writing) will print it. Firefox prints it regardless, Chromium doesn't yet.
  • expected: if truthy, define a expected property with value true. This is useful for command line interfaces to differentiate unexpected errors from e.g. invalid user input. A pattern I like to follow is to print only an error message if err.expected is true and no --verbose flag was provided. Otherwise print the full stack.
  • transient: if truthy, define a transient property with value true. This communicates to users that the operation that caused the error may be retried. See also transient-error to mark existing errors as transient.

Install

With npm do:

npm install module-error

License

MIT