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

depends-on

v2.2.0

Published

Spins up external processes your tests need

Downloads

9

Readme

depends-on

Manages the external services that your tests depend on. Think of it as async.auto with process control for integration tests.

Build Status

examples

dependencies.json is a file describing your dependencies. Keep it next to your tests.

… with one dependency

test-thing.js:

var ready = require('depends-on')('redis');
var test = require('tape');

test('init dependencies for ' + __filename, ready);

test('test that uses redis', function(t) {
  …
});

dependencies.json:

{
  "redis": {
    "cmd": ["/usr/sbin/redis-server"],
    "wait_for": {
      "port": 6379
    }
  }
}

ready() is a function that takes a callback (or a tape test object). It will call that callback when your dependencies are ready. They'll be stopped automatically when your tests are done.

… with multiple dependencies

Dependencies can have dependencies. This is the typical use case, where multiple services must start before your tests can run.

Building on the previous example, say you want to clear all values from (or load some fixtures into) Redis after it starts, but before your tests run.

test-other-thing.js:

var ready = require('depends-on')('fresh & clean redis');
var test = require('tape');

test('start fresh redis', ready);

test('test that uses redis', function(t) {
  …
});

dependencies.json:

{
  "redis-server": {
    "cmd": ["/usr/sbin/redis-server"],
    "wait_for": {
      "port": 6379
    }
  },
  "fresh & clean redis": {
    "cmd": ["./bin/flushall.sh"],
    "depends": ["redis-server"],
    "wait_for": {
      "exit_code": 0
    }
  }
}

If multiple tests are require()'d and share dependencies, depends-on will share them across the test files, each dependency only being started once. When node exits, all dependencies will stopped (by default with SIGTERM but the signal is configurable).

dependencies.json

dependencies.json is a file containing a json object mapping dependency names to objects that describe each dependency.

dependency fields

wait_for fields

You can wait for either a socket to be accepting connections or for a process to exit, so one of port or exit_code is required to use wait_for.

    "wait_for": {
      "host": "127.0.0.1",
      "port": 22181,
      "timeout": 30
    }

By default, depends-on will throw an error if one of the processes it starts exits before your tests are done. Use an exit_code in your wait_for block if a process is expected to complete and exit prior to tests running (maybe you're loading a db schema).

    "wait_for": {
      "exit_code": 0,
      "timeout": 120
    }

graph dependencies

Just for fun, bin/graph-dependencies.js can graph the dependencies in your project with graphviz.

For example, graphing the dependencies in this repo's fixtures: dot -Tpng -odeps.png <(./bin/graph-dependencies.js) && open deps.png ->

notes

using with tape

Be sure to require('depends-on') before you require('tape'). Like this:

var ready = require('depends-on')('something');
var test = require('tape');

Both depends-on and tape have process.on('exit', …) handlers, but tape calls process.exit in its process.on('exit', …) handler, so if tape's handler runs first, depends-on's handler will never run (and child processes won't be cleaned up). Handlers run in the order they are added, so depends-on must be required first.

why not

… use a bash script or Makefile?

I like to be able to run integration tests individually like $ node tests.js without running anything else or relying on some external service coincidentally being on.