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

@offirmo/error-utils

v0.0.1

Published

utilities around JavaScript Error creation and manipulation

Downloads

2

Readme

Some utilities around JavaScript Error creation and manipulation.

  • written in TypeScript
  • no dependencies

Usage

Exposed constants: known error fields

Exposes the properties we can expect on a JavaScript "Error" object.

See the source code for more details.

import {
	STRICT_STANDARD_ERROR_FIELDS,
	QUASI_STANDARD_ERROR_FIELDS,
	COMMON_ERROR_FIELDS,
	COMMON_ERROR_FIELDS_EXTENDED,
} from '@offirmo/error-utils'

Note that COMMON_ERROR_FIELDS_EXTENDED contains private properties, but since they are optional and have rare names, there shouldn't be any conflict.

Exposed types: error interface with more properties

  • XError (eXtended error) = with properties up to COMMON_ERROR_FIELDS
  • XXError = idem with properties up to COMMON_ERROR_FIELDS_EXTENDED
import {
	XError,
	XXError,
} from '@offirmo/error-utils'

Utility: slightly more convenient way to create errors than new Error(…)

Allows passing additional properties along the error creation, in one go.

  • if the properties are recognized as top level (COMMON_ERROR_FIELDS_EXTENDED) they'll be attached directly
  • if not, they'll be attached to a root details property

Also:

  • Will ensure that the string "error" is present in the message (case-insensitive), will prepend it if not
  • Will pick the message from the details as a fallback if the 1st param is not provided/falsy (convenience for rare cases)
import { createError } from '@offirmo/error-utils'

// classic = it's the same
const err = new Error(`Foo API: bar is incorrect!`)
const err = createError(`Foo API: bar is incorrect!`) // return type = XXError

// advanced: extra properties
const err = createError(`Foo API: bar is incorrect!`, { statusCode: 401, foo: 'bar' })

// advanced: extra properties + custom constructor
const err = createError(`Foo API: bar is incorrect!`, { statusCode: 401, foo: 'bar' }, TypeError)
// above is equivalent to:
const err = new TypeError(`Foo API: bar is incorrect!`)
err.statusCode = 401
err.details = {
	foo: 'bar',
}

Utility: normalize anything into a true, writable Error object

Normalize anything into a true, normal error.

Anything can be thrown in JavaScript: undefined, string, number... But that's obviously not a good practice. Even Error-like objects are sometime fancy:

  • seen: in a browser, sometimes, an error-like, un-writable object is thrown
  • seen: frozen
  • seen: non-enumerable props

So we want to ensure a true, safe, writable error object.

NOTE: will always recreate the error

import { normalizeError } from '@offirmo/error-utils'

try {
	...(unreliable code)
}
catch (err_like) {
	throw normalizeError(err_like)
}

See also

  • https://github.com/jshttp/http-errors