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 🙏

© 2026 – Pkg Stats / Ryan Hefner

call-next

v0.2.0

Published

Helper for iterating through async tests

Readme

call-next

Build Status npm version

Library to help with asynchronous testing

Installation

npm install call-next --save or yarn add call-next

Usage

See example/index.js.

Rationale

Testing asynchronous code with side effects (e.g. a function that makes an API call and does something with the result) can be difficult. Stubbing specific functions in advance of a test may result in over-stubbing (e.g. stubbing all the API calls the function under test ) or under-stubbing (e.g. forgetting to stub a particular API call, which triggers a side effect during testing).

This library is loosely inspired by how Redux-Saga approaches testing, which uses a combination of generators and declarative effects to let a test "step" through an otherwise asynchronous function and test that the right things happen at each step. This library mimics that functionality for environments where generators are unavilable or where the mental overhead of using something like Redux-Saga is undesirable.

API

call<F>(fn: F): F
call<F>(context: any, fn: F): F
call<F>(context: any, name: string): context[name]

Wraps an async function. Function should return a promise. You can specify a context to bind to the function by providing the context as a first argument and the function or the property name on the context as the second argument.


withStub((getCalls, next) => async { ... })

Stubs the call function. Returns the return value of its callback (which should be a promise). Callback receives the getCalls and next functions (see below). These functions can also be imported directly from the call-next module.


getCalls(): Calls[]
getCalls(n: number): Call

Returns either a list of Call objects (if no argument is passed) or a single Call object if passed an index for the call being examined. There should be one Call object for each invocation of the stubbed call in the last tick. A Call object comes with resolve and reject methods to resolve and reject the promise returned by the stubbed call method. It also contains a cmd property that declaratively describes how it was called and can be deeply compared to an expected value:

interface Cmd {
  fn: Function;
  args: any[];
  context?: any; // If context is undefined, this property will not exist
}

next(): Promise<void>

Jumps one tick forward and resets the value of getCalls.


assertDone<T>(promise: Promise<T>): Promise<T>

Returns a promise that rejects if the given promise does not resolve in the next tick. Use this so that any async call that you forget to resolve doesn't cause our test to timeout.


stub()
unstub()

Manually stub and unstub the call function. You may want to use these functions in lieu of withStub if you want the stubbing to happen in your own setup and teardown functions.


reset()

Manually reset the value of getCalls

Production Builds

call-next is a fairly small library to begin with, but if you want to remove the stubbing functionality in a production or non-test build, you can alias the call-next module to call-next/lib/call instead, which exposes the call function and nothing else.

With Webpack, you would modify your webpack.config.js like this:

module.exports = {

  /*
    Your normal webpack config here
  */

  resolve: {
    alias: process.env.NODE_ENV === "production" ? {
      "call-next": "./node_modules/call-next/lib/call.js"
    } : {}
  }
}