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

wreckage

v2.1.0

Published

A convenient, modern request library built around Wreck. A fork of Wrecked.

Downloads

28

Readme

Wreckage

npm version

Build Status

Coverage Status

A convenient, modern request library built around Wreck.

Overview

A simple wrapper around Wreck providing consistent error responses, status code validations, and hashing options.

(Wreck was recently updated to support async/await natively, eliminating my original need for this module, but the sugar is still handy)

Installation

NPM

$ npm install wreckage --save

Yarn

$ yarn add wreckage

Usage

import wreckage from 'wreckage';

const request = wreckage.create({
  request: {
    baseUrl: 'https://jsonplaceholder.typicode.com'
  }
});

const getSomething = async function () {
  const {payload} = await request.get('/posts/1');
  // payload.userId === 1
}

Methods

.get(uri, [options])

.post(uri, payload, [options])

.put(uri, payload, [options])

.patch(uri, payload, [options])

.delete(uri, payload, [options])

.create(configuration)

.request(method, uri, [options])

.defaults

GET

.get(uri, [options])

Performs a GET request

POST

.post(uri, payload, [options])

Performs a POST request

PUT

.put(uri, payload, [options])

Performs a PUT request

PATCH

.patch(uri, payload, [options])

Performs a PUT request

DELETE

.delete(uri, [options])

Performs a DELETE request

Request

.request(method, uri, [options])

Access the Promise request wrapper for Wreck

Create

.create([options])

Create a new instance of Wreckage with your options

Defaults

.defaults

Access the defaults for the instance

Config options

request and read are passed directly to Wreck, so, you get the same options.

Additionally, you'll find:

  • errorHandling which allows you to define return, to return, rather than throw your errors
  • validateStatus allows you to validate the statusCode of your response, to determine what will actually trigger an error
  • read.hash you can optionally have a has generated with your payload. Uses crypto.createHash so all hash types supported there are available. Default is sha1

This is an example, and these are the defaults.

{
  request: {
    headers: {},
    redirects: 3
  },
  read: {
    json: true
  },
  errorHandling: 'throw',
  validateStatus(statusCode) {
    return statusCode >= 200 && statusCode < 300;
  }
}

Response object

Something like this:

{
  statusCode: 200,
  statusMessage: 'ok',
  payload: {
    userId: 1
  },
  config: {...}, // whatever config was used in the request
  headers: {} // response headers
}

Or, if you choose to return your error

{
  error: {...} // A Boom wrapped error object
}

Errors

As mentioned above, can be returned or thrown. They get wrapped by Boom, and a fair amount of information is passed through the data object.

TODO

  • Test coverage