nr
(short for npm run
) is a
task runner for
JavaScript projects.
It can serve as a replacement for or complement to traditional NPM package scripts.
npm install --save-dev @darkobits/nr
This will install the package and create an executable in the local NPM bin path (ie:
node_modules/.bin
). If your shell is configured to add this location to your $PATH
,
you can invoke the CLI by simply running nr
. Otherwise, you may invoke the CLI by running npx nr
.
You may install nr
globally, but this is highly discouraged; a project that depends on nr
should
enumerate it in its devDependencies
, guaranteeing version compatibility. And, if your $PATH
is
configured to include $(npm bin)
, the developer experience is identical to installing nr
globally.
tl;dr Modern task runners don't need plugin systems.
When tools like Grunt and Gulp were conceived, it was common to build JavaScript projects by explicitly streaming source files from one tool to another, each performing some specific modification before writing the resulting set of files to an adjacent directory for distribution.
This pattern almost always relied on Node streams, a notoriously unwieldy API, resulting in the need for a plugin for each tool that a task-runner supported, pushing a lot of complexity from build tools up to the developers that used them.
Modern tools like Babel, Webpack, TypeScript, and Vite allow for robust enough configuration that they can often perform all of these jobs using a single invocation of a (usually well-documented) command-line interface, making plugin systems a superfluous layer of abstraction between the user and the CLI.
Rather than relying on plugins to interface with tooling, nr
provides an API for invoking other CLIs,
and a means to formalize these invocations in a JavaScript configuration file.
nr
is configured using a JavaScript configuration file, nr.config.js
, or a TypeScript configuration
file, nr.config.ts
. nr
will search for this file in the directory from which it was invoked, and
then every directory above it until a configuration file is found.
A configuration file is responsible for creating commands, functions, and scripts:
- Commands describe the invocation of a single executable and any arguments provided to it, as well as any configuration related to how the command will run, such as environment variables and how STDIN and STDOUT will be handled.
- Functions are JavaScript functions that may execute arbitrary code. They may be synchronous or asynchronous. Functions can be used to interface with another application's Node API, or to perform any in-process work that does not rely on the invocation of an external CLI.
- Scripts describe a set of instructions composed of commands, functions, and other scripts. These instructions may be run in serial, in parallel, or a combination of both.
A configuration file must default-export a function that will be passed a context object that contains the following keys:
Key | Type | Description |
---|---|---|
command |
function |
Create a new command. |
fn |
function |
Create a new function. |
script |
function |
Create a new script. |
Example:
nr.config.ts
export default ({ command, fn, script }) => {
script('build', [
command('babel', { args: ['src', { outDir: 'dist' }] }),
command('eslint', { args: 'src' })
]);
};
We can then invoke the build
script thusly:
nr build
The next sections detail how to create and compose commands, functions, and scripts.
Parameter | Type | Description |
---|---|---|
executable |
string |
Name of the executable to run. |
options? |
CommandOptions |
Optional arguments and configuration. |
Return Type | Description |
---|---|
CommandThunk |
Value that may be provided to script to run the command. |
This function accepts an executable name and an options object. The object's args
property may be used
to specify any CommandArguments
to pass to the executable.
CommandOptions
also supports a variety of ways to customize the
invocation of a command.
Commands are executed using execa
, and CommandOptions
supports all valid Execa options.
To reference a command in a script, use either the return value from command
or a string in the
format cmd:name
where name is the value provided in options.name
.
Assuming the type Primitive
refers to the union of string | number | boolean
, CommandArguments
may take one the following three forms:
-
Primitive
to pass a singular positional argument or to list all arguments as a `string`` -
Record<string, Primitive>
to provide named arguments only -
Array<Primitive | Record<string, Primitive>>
to mix positional and named arguments
Each of these forms is documented in the example below.
The vast majority of modern CLIs use kebab-case for named arguments, while idiomatic JavaScript uses
camelCase to define object keys. Therefore, nr
will by default convert objects keys from camelCase to
kebab-case. However, some CLIs (Such as the TypeScript compiler) use camelCase for named arguments. In
such cases, set the preserveArgumentCasing
option to true
in the commands' options.
Example:
nr.config.ts
import defineConfig from '@darkobits/nr';
export default defineConfig(({ command }) => {
// Using single primitive arguments. These commands will invoke
command('echo', { args: 'Hello world!' }); // echo "Hello world!"
command('sleep', { args: 5 }); // sleep 5
// Example using a single object of named arguments and preserving argument
// casing.
command('tsc', {
args: { emitDeclarationOnly: true },
preserveArgumentCasing: true
}); // tsc --emitDeclarationOnly=true
// Example using a mix of positional and named arguments.
command('eslint', {
args: ['src', { ext: '.ts,.tsx,.js,.jsx' }]
}); // eslint src --ext=".ts,.tsx,.js,.jsx"
// Execa's default configuration for stdio is 'pipe'. If a command opens an
// application that involves interactivity, you'll need to set Execa's stdio
// option to 'inherit':
command('vitest', {
stdio: 'inherit'
});
});
This function has the same signature as command
. It can be used to execute a Node script using the
current version of Node installed on the system. This variant uses execaNode
and the options argument supports all execaNode
options.
Parameter | Type | Description |
---|---|---|
userFn |
Fn |
Function to execute. |
options? |
FnOptions |
Function options. |
Return Type | Description |
---|---|
FnThunk |
Value that may be provided to script to run the function. |
This function accepts a function userFn
and an optional options
object.
To reference a function in a script, use either the return value from fn
directly or a string in the
format fn:name
where name is the value provided in options.name
.
Example:
nr.config.ts
import defineConfig from '@darkobits/nr';
export default defineConfig(({ fn, script }) => {
const helloWorldFn = fn(() => {
console.log('Hello world!');
}, {
name: 'helloWorld'
});
const doneFn = fn(() => {
console.log('Done.');
}, {
name: 'done'
});
// Just like commands, functions may be referenced in a script by value (and
// thus defined inline) or using a string with the prefix 'fn:'. The following
// two examples are therefore equivalent:
script('myAwesomeScript', [
helloWorldFn,
doneFn
]);
script('myAwesomeScript', [
'fn:helloWorld',
'fn:done'
]);
});
Parameter | Type | Description |
---|---|---|
name |
string |
Name of the script. |
instructions |
Instruction |
Instruction or Array<Instruction> ; commands, functions, or other scripts to execute in serial. |
options? |
ScriptOptions |
Optional script configuration. |
Return Type | Description |
---|---|
ScriptThunk |
Value that may be provided to script to run the script. |
This function accepts a name, an instruction set, and an options object, ScriptOptions
.
It will register the script using the provided name
and return a value.
To reference a script in another script, use either the return value from script
directly or a string
in the format script:name
.
The second argument must be an Instruction
or array of Instructions.
For reference, an Instruction may be one of:
- A reference to a command by name using a
string
in the formatcmd:name
or by value using the value returned bycommand
. - A reference to a function by name using a
string
in the formatfn:name
or by value using the value returned byfn
. - A reference to another script by name using a
string
in the formatscript:name
or by value using the value returned byscript
.
To indicate that a group of Instructions
should be run in parallel,
wrap them in an an additional array. However, no more than one level of array nesting is allowed. If you
need more complex parallelization, define separate, smaller scripts and compose them.
Example:
nr.config.ts
import defineConfig from '@darkobits/nr';
export default defineConfig(({ command, fn, script }) => {
command('babel', {
args: ['src', { outDir: 'dist' }],
name: 'babel'
});
command('eslint', {
args: ['src'],
name: 'lint'
});
// This script runs a single command, so its second argument need not be
// wrapped in an array.
script('test', command('vitest'), {
description: 'Run unit tests with Vitest.'
});
const doneFn = fn(() => console.log('Done!'));
script('prepare', [
// 1. Run these two commands in parallel.
['cmd:babel', 'cmd:lint']
// 2. Then, run this script.
'script:test',
// 3. Finally, run this function.
doneFn
], {
description: 'Build and lint in parallel, then run unit tests.'
});
script('test.coverage', command('vitest', {
args: ['run', { coverage: true }]
}), {
description: 'Run unit tests and generate a coverage report.'
});
});
Warning
Scripts will deference their instructions after the entire configuration file has been parsed. This means that if a script calls a command via a string token and something downstream re-defines a new command with the same name, the script will use the latter implementation of the command. This can be a powerful feature, allowing shareable configurations that users can modify in very specific ways. If you want to ensure that a script always uses a specific version of a command, use the pass-by-value method instead of a string token.
For users who want to ensure their configuration file is type-safe, or who want IntelliSense, you may use a JSDoc annotation in a JavaScript configuration file:
nr.config.ts
/** @type { import('@darkobits/nr').UserConfigurationExport } */
export default ({ command, fn, script }) => {
};
If using a TypeScript configuration file, you can use the satisfies
operator:
nr.config.ts
import type { UserConfigurationExport } from '@darkobits/nr';
export default (({ command, fn, script }) => {
// Define configuration here.
}) satisfies UserConfigurationExport;
Or, nr
exports a helper which provides type-safety and IntelliSense without requiring a JSDoc or
explicit type annotation.
nr.config.ts
import defineConfig from '@darkobits/nr';
export default defineConfig(({ command, fn, script }) => {
// Define configuration here.
});
Once you have created an nr.config.(ts|js)
file in your project and registered commands, functions,
and scripts, you may invoke a registered script using the nr
CLI:
nr test.coverage
Or, using a shorthand:
nr t.c
More on using shorthands below.
nr
supports a matching feature that allows the user to pass a shorthand for the desired script name.
Script names may be segmented using a dot, and the matcher will match each segment individually.
For example, if we wanted to execute a script named build.watch
, we could use any of the following:
nr build.w
nr bu.wa
nr b.w
Additionally, script name matching is case insensitive, so if we had a script named testScript
, the
query testscript
would successfully match it.
💡 Protip
If a provided shorthand matches more than one script,
nr
will ask you to disambiguate by providing more characters. What shorthands you will be able to use is therefore dependent on how similarly-named your project's scripts are.
Like NPM package scripts, nr
supports pre and post scripts. Once a query from the CLI is matched to a specific script, nr
will look
for a script named pre<matchedScriptName>
and post<matchedScriptName>
. If found, these scripts will
be run before and after the matched script, respectively.
💡 Protip
Because script name matching is case insensitive, a script named
build
may have pre and post scripts namedpreBuild
andpostBuild
.
Discoverability and self-documentation are encouraged with nr
. While optional, consider leveraging the
name
, group
, and description
options where available when defining commands, functions, and
scripts. Thoughtfully organizing your scripts and documenting what they do can go a long way in reducing
friction for new contributors.
The --commands
, --functions
, and --scripts
flags may be passed to list information about all known
entities of that type. If nr
detects that a command, function, or script was registered from a
third-party package, it will indicate the name of the package that created it.
A new contributor to a project may want an overview of available scripts, and may not be familiar with
with the nr
CLI. To make this feature easily accessible, consider adding an NPM script to the
project's package.json
:
{
"scripts": {
"help": "nr --scripts"
}
}
npm run help
will now print instructions on how to interact with nr
, what scripts are available, and
(hopefully) what each one does. Here's an example:
To have nr
skip searching for a configuration file and use a file at a particular path, pass the
--config
flag with the path to the configuration file to use.
-
NPS -
nr
was heavily inspired by NPS, originally created by Kent C. Dodds, which itself was inspired by a tweet by Sindre is a Horse. -
npm-run-all
- The original package scripts parallelization tool. - Grunt - The JavaScript task-runner.
- Gulp - The streaming build system.