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

runna

v3.0.3

Published

Runna - process based task runner for Node

Downloads

2,456

Readme

Runna - process based task runner for Node

Features

  • Fast and simple.
  • NPM scripts compatible - there is no need to reinvent the wheel.
  • Process based - failure of one task does not have to bring the whole process down.
  • Watcher included - built-in consistent performant recursive watching.

Usage

Usage:
  runna <chain> [options]

Options:
  -p <projects>            Run with projects; a comma separated list.
  -w [<path-to-watch>]     Default is current.
  -v                       Verbose mode (debug).
  -o                       Use polling when watching (useful when using Docker).

Quck start

STEP 1: Define your usual NPM scripts

{
  "scripts": {
    "clean": "rimraf ./dist",
    "create-dist-dir": "mkdirp ./dist",
    "build:js": "browserify ./src/index.js -o ./dist/index.js -t [ babelify --presets [ babel-preset-env ] ]",
    "copy:html": "copyfiles --flat ./src/index.html ./dist",
    "serve": "runna-webserver -w ./dist",
    "serve:stop": "runna-webserver -x",
    "serve:reload": "runna-webserver -r"
  }
}

STEP 2: Define your build chain

{
  "scripts": {
    "build": "runna [ clean - create-dist-dir - build:js copy:html ]"
  }
}

The above build chain translates to:

clean             | npm run clean
-                 | wait for all previous scripts to complete
create-dist-dir   | npm run create-dist-dir
-                 | wait for all previous scripts to complete
build:js          | npm run build:js
copy:html         | npm run copy:html

STEP 3: Run your chain

npm run build

And that's it! The build chain executes all scripts as background processes. Note that the - symbol allows to wait for all the previous scripts to complete and behaves consistently on all OSes.

Advanced usage

Interactive development mode

The development mode allows triggering chain upon a file change. To enable watch mode, simply add -w parameter. Let's define develop chain like so:

{
  "scripts": {
    "develop": "runna [ +serve clean - create-dist-dir - build:js copy:html - serve:reload ] -w",
  }
}

The + symbol before a script name indicates, that the script should be run in the backgroud. Waiting for all previous tasks to complete with - igonres all background scripts automatically.

Now, let's define our observe rules like so:

{
  "observe": {
    "build:js - serve:reload": [
      "src/**/*.js"
    ],
    "copy:html - serve:reload": [
      "src/**/*.html"
    ]
  }
}

Notes:

  • Each rule is a chain that is executed whenever a file changes that matches one of the patterns in the array. Patterns must be relative to the current working directory, or the location specified as a -w <path-to-watch> parameter.
  • Any chain with -w flag will be run at least once, before watching begins.
  • Watching leverages recursive flag of fs.watch(), which greatly improves performance on Windows and OS X compared to packages based on Chokidar (e.g. onchange or watchify), especially for large projects.

$FILE variable

It is possible to pass a file path to a script, that triggeted a chain execution when in watch mode. To do so, use $FILE variable like so:

{
  "scripts": {
    "build:html": "node scripts/build-html $FILE",
  }
}

Notes:

  • When in watch mode, the $FILE variable will be replaced with the full path of the file that triggered the chain.
  • When not in watch mode (this also applies to the first run when in watch mode), the $FILE will default to blank, so make sure your script handles it correctly (e.g. builds everything if no file is provided).

$PROJ variable

It is possible to run the same script for multiple sub-projects using the $PROJ variable. Let's define a project-based script like so:

{
  "scripts": {
    "build:js": "browserify ./src/$PROJ/index.js -o ./dist/$PROJ/index.js -t [ babelify --presets [ babel-preset-env ] ]"
  }
}

The presence of $PROJ placeholder enables project-based behaviour automatically. Let's update our develop chain to support projects. To do so, simply add -p parameter:

{
  "scripts": {
    "develop": "runna [ +serve clean - create-dist-dir - build:js copy:html - serve:reload ] -w -p red,blue"
  }
}

When running the above chain with npm run develop, the build:js script will be run twice, once for each project. Scripts that do not use $PROJ placeholder will only run once as per usual. Think of it as of two separate scripts: build:js::red and build:js::blue.

Let's update our observe rule accordingly:

{
  "observe": {
    "build:js - serve:reload": [
      "src/$PROJ/*.js",
      "src/foo/**/*.js"
    ]
  }
}

Notes:

  • When a file changes on the path matching src/blue/*.js, the build:js script will be run only for the the blue project. The $PROJ placeholder will be replaced with the actual folder name.
  • When a file changes on the path matching src/foo/**/*.js, the build:js script will be run for all projects provided (in this case red and blue).
  • If no projects are provided with -p option, all project-based scripts are ignored.