Inter-Process Complexity

It’s easy to forget the technical wonders your OS is built upon. Something as basic as typing the following command in a terminal involves multiple abstraction layers.

npx open-cli "https://www.youtube.com/watch?v=dQw4w9WgXcQ"

npx runs in a process, separate from the shell that called it, then spawns another subprocess for open-cli. Each process has its own executable file and resources (memory, CPU state, file descriptors, etc.).

Processes are isolated from each other. While this is great for security reasons, this also creates a need for Inter-Process Communication (IPC).

The most common IPC mechanisms are: arguments, exit codes, environment variables, signals, standard streams (stdin, stdout, stderr), file descriptors, files, shared memory, and network calls.

However, those solutions are often either too limited or too complicated. Execa 9.2, which was just released, aims at simplifying IPC when both processes use Node.js.

Pass anything to a process

Sending a string is straightforward with most IPC methods. However, any structured data requires serializing and parsing. For instance, plain objects can use JSON.

With Execa, the ipcInput option converts most types automatically, so you don’t need to manually serialize or parse anything.

This follows the structured clone algorithm. In a nutshell, almost all JavaScript values are allowed, with the notable exception of functions (which includes class instance methods).

Also, while the size limit of arguments and environment variables is usually lower than 1MB, the ipcInput option can handle up to 2GB.

// main.js
import {execaNode} from 'execa';

const ipcInput = [
  {
    task: 'lint', 
    ignore: /test\.js/,
  },
  {
    task: 'copy', 
    files: new Set([
      'main.js', 
      'index.js',
    ]),
  },
];
await execaNode({ipcInput})`build.js`;

// build.js
import {getOneMessage} from 'execa';

const ipcInput = await getOneMessage();
for (const {task, ignore, files} of ipcInput) {
  await runTask(task, {ignore, files});
}

Return anything from a process

The same problem holds for the process’s output. stdout and stderr can print anything, but the caller needs to parse it.

With Execa, a process can return almost any data by calling sendMessage(message). The parent process retrieves it, kept as is, using the result.ipcOutput array.

// main.js
import {execaNode} from 'execa';

const {ipcOutput} = await execaNode`build.js`;
console.log(ipcOutput[0]); // {kind: 'start', timestamp: date}
console.log(ipcOutput[1]); // {kind: 'stop', timestamp: date}

// build.js
import {sendMessage} from 'execa';

await sendMessage({kind: 'start', timestamp: new Date()});
await runBuild();
await sendMessage({kind: 'stop', timestamp: new Date()});

Exchange messages

What if you need to retrieve the process’s output while it is still running, for example to show a progress bar? Or provide additional input after the process already started?

Usually, this is solved by streaming stdin, stdout, stderr, or making network calls. This can be tricky to get right, especially when tuning performance and handling any potential I/O errors.

Execa provides a simple set of methods to exchange messages: sendMessage(message) and getOneMessage().

// parent.js
import {execaNode} from 'execa';

const subprocess = execaNode`child.js`;
await subprocess.sendMessage('Hello from parent');
const message = await subprocess.getOneMessage();
console.log(message); // 'Hello from child'
await subprocess;

// child.js
import {getOneMessage, sendMessage} from 'execa';

const message = await getOneMessage(); // 'Hello from parent'
const newMessage = message.replace('parent', 'child'); // 'Hello from child'
await sendMessage(newMessage);

Listen to messages

You can also follow a client/server model where one process (or both) handles requests from the other. This is achieved by listening to all incoming messages with getEachMessage().

// parent.js
import {execaNode} from 'execa';

const subprocess = execaNode`child.js`;
await subprocess.sendMessage(0);

// This loop ends when the subprocess exits.
// It throws if the subprocess fails.
for await (const message of subprocess.getEachMessage()) {
  console.log(message); // 1, 3, 5, 7, 9
  await subprocess.sendMessage(message + 1);
}

// child.js
import {sendMessage, getEachMessage} from 'execa';

// The subprocess exits when hitting `break`
for await (const message of getEachMessage()) {
  if (message === 10) {
    break;
  }

  console.log(message); // 0, 2, 4, 6, 8
  await sendMessage(message + 1);
}

Filter messages

The getOneMessage() method has a filter option to select the specific message you want to retrieve. This is handy when receiving events of different types.

import {execaNode} from 'execa';

const subprocess = execaNode`build.js`;
const stopMessage = await subprocess.getOneMessage({
  filter: message => message.type === 'stop',
});

Guaranteed reception

IPC is stateful and time-sensitive by nature, which can create subtle race condition bugs. Most network protocols prevent against those by ensuring that any message sent is also well received. For example, TCP uses an ACK number.

With Execa, the strict option fulfills that purpose. When enabled, it guarantees that the other process properly receives your message.

// main.js
import {execaNode} from 'execa';

const subprocess = execaNode`build.js`;
// This `build` message is received
await subprocess.sendMessage('build', {strict: true});
// This `lint` message is not received, so it throws
await subprocess.sendMessage('lint', {strict: true});
await subprocess; 

// build.js
import {getOneMessage} from 'execa';

// Receives the 'build' message
const task = await getOneMessage();
// The `lint` message is sent while `runTask()` is ongoing
// Therefore the `lint` message is discarded
await runTask(task);

// Does not receive the `lint` message
// Without `strict`, this would wait forever
const secondTask = await getOneMessage();
await runTask(secondTask);

No process left hanging

To ensure every message sent by one end is received by the other, processes are kept alive when listening to messages.

However, this does not work well when you’re unsure whether those messages might be sent or not, as it can keep processes hanging forever. This can be fixed using the reference: false option.

import {getEachMessage} from 'execa';

// {type: 'gracefulExit'} is sometimes received, but not always
for await (const message of getEachMessage({reference: false})) {
  if (message.type === 'gracefulExit') {
    gracefulExit();
  }
}

Debugging

Since processes are isolated by design, they can become black boxes that are hard to debug. To help with this, every IPC message sent by an Execa process is automatically printed in both error messages and verbose logs.

// build.js
import {execaNode} from 'execa';

await execaNode`npm run build`;

# Run in verbose mode
# Each line with a * symbol is an IPC message

$ NODE_DEBUG=execa node build.js
[00:57:44.658] [0] $ npm run build
[00:57:44.670] [0]   Build application...
[00:57:44.692] [0] * {name: 'start'}
[00:57:44.701] [0] * {name: 'entrypoint', value: 'mispelled_index.js'} 
[00:57:44.740] [0]   Error: the entrypoint is invalid.
[00:57:44.747] [0] ✘ Command failed with exit code 1: npm run build
[00:57:44.747] [0] ✘ (done in 89ms)

Graceful termination

Being gentle with processes is not easy. In fact, terminating them is usually quite brutal. The standard approach is to send a signal like SIGTERM. However, this makes the process end abruptly, including any ongoing operation. This can leave a file half-written, an HTTP request hanging, or some data broken.

On Unix, handlers can intercept signals to run any cleanup logic. Unfortunately, this does not work on Windows.

The gracefulCancel option offers a cross-platform solution to this problem. It uses IPC to share an AbortSignal between a process and its parent process.

// main.js
import {execaNode} from 'execa';

const controller = new AbortController();
setTimeout(() => {
  controller.abort();
}, 5000);

const cancelSignal = controller.signal;
await execaNode({cancelSignal, gracefulCancel: true})`build.js`;

// build.js
import {getCancelSignal} from 'execa';

const cancelSignal = await getCancelSignal();
const url = 'https://example.com/build/info';
const response = await fetch(url, {signal: cancelSignal});

Under the hood

We’ve built those features on top of Node’s builtin IPC. Named pipes are used as a communication channel between the processes. The message payloads are serialized with V8.

IPC is an advanced feature. 95% of the time, you won’t need it: Execa already provides simpler ways to perform common tasks, from scripts to piping or streaming. However, in more elaborate scenarios, IPC could become a time saver.

IPC made easy with Execa 9.2 was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Execa runs commands in your script, application or library. Unlike zx and Bun shell, Execa distances itself from shells and the old days of Bash scripts. Instead, it embraces a modern, purely JavaScript approach, optimized for programmatic usage. This makes executing commands simple, secure, cross-platform and easy to debug.

import {$} from 'execa';

const tokensUrl = 'https://example.com/api/tokens';
const token = await $`curl ${tokensUrl}`
  .pipe`grep api_token`
  .pipe`head -n 1`;

const branch = await $`git branch --show-current`;

const logFile = 'logs.txt';
await $({stderr: logFile})`dep deploy
  --parallel
  --token=${token} 
  --branch=${branch}`;

Despite being 8 years old, the project is very active. In fact, today’s release is our biggest so far, involving 6 contributors, 9 months of development, 317 PRs and 3915 automated tests. Here’s a highlight of some of the new features.

Read the output, one line at a time

If a command lasts for a long time, you might want to read its output while it is still running. Since most commands are text-based, this usually means iterating over each output line. Although this might seem simple at first sight, it is surprisingly hard to get right.

With Execa, commands are iterable, one line at a time. The lines option can also be used to split the full output into multiple lines.

import {execa} from 'execa';

// One line at a time
for await (const line of execa`npm run build`) {
  if (line.includes('ERROR')) {
    await reportError(line);
  }
}

// All lines at once
const {stdout: lines} = await execa({
  lines: true,
})`npm run build`;
const errorLines = lines
  .filter(line => line.includes('ERROR'))
  .join('\n');
console.error(errorLines);

Map/filter the input and output

Node.js Duplexes and Transforms are streams that map or filter data. There are many available modules based on them, from parsing CSV to compressing data or logging.

With Execa, they can be passed directly to a command’s stdin, stdout or stderr option to transform its input or output. Web-based TransformStreams are supported too.

Streaming consumes memory progressively and holds the CPU in small bursts. If a command is slow or its output is big, this is more efficient than modifying its final result all at once.

import {execa} from 'execa';

const {stdout} = await execa({
  stdout: new CompressionStream('gzip'),
  encoding: 'buffer',
})`npm run build`;

// `stdout` is compressed with gzip
console.log(stdout); 

Generator-based transforms

That being said, writing your own streams can be tricky. To enjoy their benefits without diving into their intricate ins and outs, simple generator functions can be used instead.

import {execa} from 'execa';

let count = 0;
const {stdout} = await execa({
  * stdout(line) {
    yield `[${count++}] ${line}`;
  },
})`npm run build`;

// Prefix line number:
// [0] ...
// [1] ...
// [2] ...
console.log(stdout);

Redirect the input and output

A command’s input or output is commonly redirected from/to a file, as shown by the < and > builtin operators in Unix shells. With Execa, this can be done by passing a {file: './path'} object to the stdin, stdout or stderr option.

Another usual task is to print a command’s output progressively. Passing 'inherit' to the stdout or stderr option achieves that, but it prevents storing the output in a variable. This can be fixed by passing ['inherit', 'pipe'] instead.

import {execa} from 'execa';

const {stderr} = await execa({
  // Write stdout to a file
  stdout: {file: './stdout.txt'},
  // Return stderr, but also print it
  stderr: ['inherit', 'pipe'],
})`npm run build`;

Pipe multiple commands

The pipe operator | is great in interactive terminals. However, in a script file, it cannot easily:

• Retrieve the output of each command in the pipeline, as opposed to only the last one, making debugging difficult.
• Handle errors: unless the pipefail option is set, the pipeline might succeed even if some of its commands failed.
• Pipe one command to several, or several commands to one.
• Change a command’s piping destination.
• Benefit from strong types, since parsing the pipeline string in TypeScript is not feasible.

Execa’s subprocess.pipe() method can do all of the above, enabling a better experience in a programmatic context.

import {execa, execaNode} from 'execa';

// `npm run build | sort | head -n 2`
// Throws if any of the three commands fails 
const finalResult = await execa`npm run build`
  .pipe`sort`
  .pipe`head -n 2`;
// `npm run build | sort`
const sortResult = finalResult.pipedFrom[0];
// `npm run build`
const buildResult = sortResult.pipedFrom[0];

// Pipe several commands to the same logging process
const logger = execaNode`log-remotely.js`;
await Promise.all([
  execa`npm run build`.pipe(logger),
  execa`npm run test`.pipe(logger),
]);

Verbose mode

Commands sometimes feel like black boxes. They run in processes isolated from each other, which can turn a small typo into an hours-long debugging headache.

To alleviate this problem, the verbose mode has been improved to automatically print the commands’ arguments, output, errors, completion and duration.

// build.js
import {execa} from 'execa';

await execa`npm run build`;
await execa`npm run test`;

$ NODE_DEBUG=execa node build.js
[00:57:44.581] [0] $ npm run build
[00:57:44.653] [0]   Building application...
[00:57:44.653] [0]   Done building.
[00:57:44.658] [0] ✔ (done in 78ms)
[00:57:44.658] [1] $ npm run test
[00:57:44.740] [1]   Running tests...
[00:57:44.740] [1]   Error: the entrypoint is invalid.
[00:57:44.747] [1] ✘ Command failed with exit code 1: npm run test
[00:57:44.747] [1] ✘ (done in 89ms)

Detailed errors

Errors now include richer information including the interleaved output, the duration, and additional insights into the failure’s root cause.

import {execa} from 'execa';

try {
  await execa({timeout: 5000})`npm run build`;
} catch (error) {
  console.error(error);
  // ExecaError: Command timed out after 5000 milliseconds: npm run build
  //     at file:///home/me/Desktop/example.js:2:20
  //     at ... {
  //   command: 'npm run build',
  //   escapedCommand: 'npm run build',
  //   cwd: '/path/to/cwd',
  //   durationMs: 19.95693,
  //   failed: true,
  //   timedOut: true,
  //   isCanceled: false,
  //   isTerminated: true,
  //   isMaxBuffer: false,
  //   signal: 'SIGTERM',
  //   signalDescription: 'Termination',
  //   stdout: 'Building the application...',
  //   stderr: 'Warning: deprecated API.',
  //   stdio: [
  //     undefined, 
  //     'Building the application...', 
  //     'Warning: deprecated API.',
  //   ],
  //   pipedFrom: []
  // }
}

Debug termination signals

Have you ever wondered why a specific command ended abruptly? Termination signals like SIGTERM do not carry any information: no message, no stack trace.

This can be solved by passing an error instance to subprocess.kill(), which could be a time-saver when debugging complex bugs.

import {execa} from 'execa';

const subprocess = execa`npm run build`;
onCancel(reason => {
  const error = new Error(`Canceled by ${reason}`);
  subprocess.kill(error);
});
await subprocess;

Template strings

Since Execa 7, commands can be specified using a template string, like zx. However, this was previously limited to the $ method.

Both the template string syntax and the traditional array syntax can now be used with all Execa methods. They are equivalent and mostly a matter of preference.

Also, template strings can span multiple lines, which is useful when passing many CLI flags.

When executing a series of commands in a script, $ is recommended. When calling individual commands in an application or library, execa and execaNode are preferred instead. The only difference is that $ uses script-friendly default options. For example, it automatically reads its stdin from the terminal.

import {execa} from 'execa';

await execa`npm run build
  --concurrency 2
  --fail-fast`;

Share options

All Execa methods can bind options. This enables setting global options or re-using them between multiple commands.

import {execa as execa_} from 'execa';

// Set global options
const execa = execa_({timeout: 5000});

await execa`npm run build`;
await execa`npm run test`;

Embrace web APIs

Server-side JavaScript is increasingly adopting web APIs in lieu of Node.js core modules. So is Execa: instead of Node.js streams, file path strings and Buffer, you can use web streams, file URLs and Uint8Array.

import {execaNode} from 'execa';

const response = await fetch('https://example.com/api/orders');
await execaNode({
  stdin: response.body,
})`send_orders.js`;

Convert to streams

Some modules take streams as arguments or return them. In order to let you use commands to those modules directly, Execa subprocesses can be converted to streams using subprocess.readable(), subprocess.writable() or subprocess.duplex().

import {execaNode} from 'execa';
import {pipeline} from 'node:stream/promises';
import {
  createReadStream, 
  createWriteStream,
} from 'node:fs';

await pipeline(
  createReadStream('./input.txt'),
  execaNode`transform.js`.duplex(),
  createWriteStream('./output.txt'),
);

For a full list of the breaking changes, new features and bug fixes, please check out the release notes.

Also, we’ve completely revamped the documentation: aside from the reference section, it now includes many user guides and examples. We’d love to encourage new users to better understand processes, which can be a daunting topic at first. Hopefully, the new documentation will also help long-time users discover specific features they previously missed.

While shell scripts are very handy, many developers enjoy the flexibility, expressiveness and ecosystem that come with programming languages like JavaScript. zx, a recent popular project from Google, combines the best of both worlds.

const branch = await $`git branch --show-current`
await $`deploy --branch=${branch}`

Execa is a 7-year-old Node module used by 15 million repositories that makes commands and processes easy to execute. Our 7.1 release features a mode similar to zx but with a simpler JavaScript-only approach. This article focuses on the main differences with zx.

import { $ } from 'execa'

const branch = await $`git branch --show-current`
await $`deploy --branch=${branch}`

Scripting without a shell

Why use both Node and Bash? With Execa, there is no shell syntax to remember: everything is just plain JavaScript. Almost all shell-specific features can be expressed in JavaScript. For the remaining edge cases, a shell option is available.

This is more:

• Secure: shell injections are not technically feasible.
• Cross-platform: not all Windows machines have Bash available.
• Performant: spawning a shell for every command comes at a cost. Even npx can be skipped since Execa can directly execute locally installed binaries.

# In Bash
API_KEY="secret" npx deploy "$cluster" &> logs.txt && echo "done"

// In JavaScript
import { $ } from 'execa'

const options = { env: { API_KEY: 'secret' } }
await $(options)`deploy ${cluster}`.pipeAll(’logs.txt’)
console.log('done')

Simplicity

Execa does not require any special binary, inject global variables nor include any utility. It focuses on being small and modular instead. Any Node module can be used in your scripts.

import { $ } from 'execa'
import pRetry from 'p-retry'

await pRetry(
  async () => await $`deploy dev_cluster`,
  { retries: 5 },
)

Options

The child_process core Node module includes many useful features: timeout, cancellation, background processes, IPC, PID, UID/GID, weak references, and more. Execa adds a few additional ones: graceful termination, cleanup, interleaved output, etc. Those can be set using $(options) for either one or multiple commands.

import { $ } from 'execa'

const $$ = $({ timeout: 5000, all: true })

// `all` retrieves both stdout and stderr
const { all } = $$`deploy dev_cluster`

Debugging

Child processes can be hard to debug. This is why Execa:

• Includes a verbose option, which can be set using NODE_DEBUG=execa.
• Reports detailed error messages and properties.
• Is purely stateless, making it straightforward to figure out what is the current directory, or any other option.

> NODE_DEBUG=execa node deploy.js

[16:50:03.305] deploy dev_cluster
........dev_cluster successfully deployed.

[16:53:06.378] deploy prod_cluster
.............prod_cluster successfully deployed.

Piping

Redirecting input/output is a common shell pattern that’s available with Execa.

import { $ } from 'execa'

// Pipe input from a string or buffer, like <<< in Bash
await $({ input: 'dev_cluster' })`deploy`

// Pipe input from a file, like < in Bash
await $({ inputFile: 'clusters.txt' })`deploy`

// Pipe output to a file, like >, 2> and &> in Bash
await $`deploy dev_cluster`.pipeStdout('stdout.txt')
await $`deploy dev_cluster`.pipeStderr('stderr.txt')
await $({ all: true })`deploy dev_cluster`.pipeAll('logs.txt')

// Pipe output to another command, like | and |& in Bash
await $`deploy dev_cluster`.pipeStdout($`grep done`)

// Pipe output to a stream, like 2>&1 in Bash
const { stdout } = await $`deploy dev_cluster`.pipeStderr(process.stdout)

If you’re curious, please feel free to check our main documentation and the page dedicated to Node.js scripts. Huge thanks to Aaron Casanova, a new contributor to Execa, who added this feature, and to Sindre Sorhus, who reviewed it!

Shell-free scripts with Execa 7 was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

When measuring a string in JavaScript, string.length comes to mind. However, that property does not tell the full story. Strings have many sizes: code units, code points, bytes, pixels, terminal columns.

Let’s dive into their differences.

Code units

Each string element in JavaScript is a UTF-16 code unit. In other words, any string[index], commonly (and ambiguously) referred to as a string “character.”

Code units are fast and convenient to use since they underpin all string operations (with a few exceptions noted below) including string.length, string.slice(), string === string, string.replace() and so on.

Strings have a maximum size in code units. While the standard defines it as at most ~9e15, JavaScript engines implement much lower limits: ~5e8 with V8, ~1e9 with SpiderMonkey and ~2e9 with JavaScriptCore.

Code points

A Unicode code point is a number identifying a single abstract character. It is often noted in hexadecimal: for example, the decimal number 129445 would be written U+01F9A5 🦥 (sloth). Unicode maintains a list of characters with code points ranging:

• From U+000000 to U+00007F: ASCII
• From U+000080 to U+00FFFF: BMP (Basic Multilingual Plane)
• From U+010000 to U+10FFFF: Astral code points. This is where you’ll find emoji! 🎶

Usually, a UTF-16 code unit is equivalent to a code point. For example, "Olá!" has 4 code units with their own code points: U+004F, U+006C, U+00E1 and U+0021.

However, astral code points (U+010000 and above) are broken down into two code units:

• First, a “high/leading surrogate” from \uD800 to \uDBFF
• Then, a “low/trailing surrogate” from \uDC00 to \uDFFF

For example, U+01F9A5 becomes \uD83E and \uDDA5. This conversion from a code point to a surrogate pair is specific to UTF-16. If you’re curious about it, please check this code sample.

This only applies if the two surrogates follow each other in that order. In JavaScript, isolated or inverted surrogates are valid but considered their own code points and generally either invisible or printed as � (replacement character U+FFFD).

Since most string operations use code units, surrogates can be a problem. In some cases, they work just fine. For example, the following statements are correct because "🦥" is equivalent to "\uD83E\uDDA5", i.e. to the full surrogates pair.

However, some string operations might target individual surrogates and split the pair.

Fortunately, a few string operations use code points instead of code units:

• Iterations, including [...string] and for (const codepoint of string), but excluding for (const index in string)
• Regular expressions with the Unicode flag: /.../u
• \u{000000} instead of \u0000
• string.codePointAt() and String.fromCodePoint() instead of string.charCodeAt() and String.fromCharCode()
• string.to*Case() and string.trim*()

Bytes

When a string is written to a file or sent over the network, it is first serialized to a series of bytes. This binary representation differs from code units and code points.

Character encodings translate each code point into one or several bytes. While there are quite many of them, the most common ones these days are UTF-16 and UTF-8.

Since JavaScript strings are based on UTF-16, their binary representation in that character encoding is straightforward (aside from endianness): each code unit translates to an equivalent bytes pair.

For UTF-8, each code point translates to a series of 1 to 4 bytes. Lower Unicode code points take fewer bytes. In particular, ASCII characters are 1 byte long. On the other hand, astral code points are 4 bytes long. The conversion logic is explained in details here.

Some JavaScript packages are available for common operations like retrieving a string’s size in bytes or slicing it bytewise (see string-byte-length and string-byte-slice). Otherwise, Uint8Arrays can be used to represent series of bytes and TextEncoder/TextDecoder to convert strings to/from them.

Buffers are a Node.js alternative with a few additional features.

Width

When displayed, a string occupies a platform-specific width. For example, browsers use pixels, em, etc. We’ll focus on terminals, which use columns.

Terminals print characters in a grid pattern. Computing a string’s width primarily helps with vertical alignment and padding. Also, while terminals do wrap lines automatically, manual wrapping can be needed for similar reasons.

Determining a string’s terminal width is rather intricate.

To begin with, considering some terminals or fonts might not handle exotic characters well, cross-platform terminal characters should be preferred for consistent behavior.

Also, while most code points are 1 column wide, fullwidth characters are 2 columns wide. Those usually represent Chinese, Japanese and Korean logograms. Common code points such as ASCII characters are sometimes available as wide or narrow variants. Unicode provides a list with each code point’s width, which can be accessed through some helper modules.

Furthermore, some code points are meant to be combined with another. Those are usually accents and other diacritics. For example, a (U+0061) followed by a combining grave accent (U+0300) is displayed like à (U+00E0) which is 1 column wide. string.normalize() composes/decomposes those.

Other examples include variation selectors: # (U+0023) succeeded by the emoji variation (U+FE0F) produces a hashtag emoji#️. Or flags: 🇪 (U+1F1EA) and 🇺 (U+1F1FA) result in the EU flag 🇪🇺.

Emoji modifiers behave similarly. For instance, 👩 (woman, U+1F469) followed by medium skin tone (U+1F3FD), zero-width joiner (U+200D) and 🔬(microscope, U+1F52C) is shown as 👩🏽‍🔬 (woman scientist, medium skin tone), 2 columns wide.

A few code points are even invisible. Among many purposes (even music notation! 🎷), those are intended to join or separate characters, symbols or words (zero-width space U+200B, word joiner U+2060) and set text direction (left-to-right mark U+200E, right-to-left mark U+200F).

Finally, control characters don’t have any width because they are not meant to be printed. Instead, they modify terminal parameters such as cursor position, scrolling, character set, communication, message structure, etc. One of them even emits sounds 🎤. They are divided into several categories:

• C0 control characters (U+0000 to U+001F) which are part of ASCII. Those are the oldest ones, with some dating back to 1870 🚂! They include line feed, null and backspace. Some of them can be represented using backslash sequences such as \n, \0 or \b.
• C1 control characters (U+0080 to U+009F) which are rarely used.
• Other code points such as language tags.
• ANSI escape sequences. Those do not have any Unicode code points. They are represented using sequences that start with \e. The most common ones change colors, e.g. \e[31m sets the font’s color to red. But many more are available. Several modules simplify detecting or stripping them.

With everything considered, manipulating a string’s width in terminals might seem daunting. Fortunately, a few packages help with computing it or slicing/truncating a string to fit a specific amount of columns.

In most cases, the difference between the above units is straightforward. Choosing the right one can prevent some bugs, such as computing a string’s terminal width using string.length or matching an emoji string with a RegExp lacking the u flag.

That being said, their performance cost might vary. For example, converting a large string to/from binary can be slow. Also, JavaScript operations using code units tend to run slightly faster than the code points ones. This can lead to preferring a less accurate unit inside critical hot paths.

In a nutshell, each unit presents the same information to different targets: machines (bytes), developers at an implementation (code units) or abstract level (code points), and users (width).

Go composable: Build apps faster like Lego

Bit is an open-source tool for building apps in a modular and collaborative way. Go composable to ship faster, more consistently, and easily scale.

→ Learn more

Build apps, pages, user-experiences and UIs as standalone components. Use them to compose new apps and experiences faster. Bring any framework and tool into your workflow. Share, reuse, and collaborate to build together.

Help your team with:

→ Micro-Frontends

→ Design Systems

→ Code-Sharing and reuse

→ Monorepos

Learn more

• How We Build Micro Frontends
• How we Build a Component Design System
• How to reuse React components across your projects
• 5 Ways to Build a React Monorepo

How big is a JavaScript string? was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we are releasing a new major version of Execa. This Node.js library enhances child processes with:

• Promises instead of callbacks
• Execution of locally installed binaries
• Better cross-platform support, including shebangs
• Cleanup of child processes when their parent exits
• And more

Thanks to Sindre Sorhus, ehmicky, GMartigny, BendingBender, tomsotte, Malik Ammar Faisal, zokker13, stroncium, Satya Rohith, Brad Lemley, coreyfarrell, Brandon Smith, Thai Pangsakulyanont and Pedro Augusto de Paula Barbosa, the following features are now available:

• TypeScript support
• Interleaved stdout and stderr
• Shell mode updates
• Changes to local binaries execution
• Improved spawning of Node.js scripts
• Graceful exit
• Process cancellation
• Enhanced errors
• Stricter exit codes
• Gulp plugin
• And more updates and bug fixes

TypeScript

We have added TypeScript declarations.

Interleaved stdout and stderr

Node.js returns a child process’s stdout and stderr separately. However, those streams are usually connected and intertwined in the console. We made it easy for you to retrieve their combined output.

Avoid the shell option

While it has (very) few legitimate uses, the shell option should be avoided.

Why? First, it encourages shell-specific syntax (Bash, cmd.exe) which won’t work on every OS. Almost every shell feature is available directly in Node.js.

Second, it is much slower as it makes every command go through the shell interpreter.

Last but not least, it increases the risk of command injection:

As a consequence, we have removed execa.shell() and execa.shellSync() which were merely shortcuts to the shell option.

Furthermore, execa.command() and execa.commandSync() can now be used to specify the command and its arguments as a single string without the shell option. Nothing needs to be escaped/quoted except for significant spaces (with a backslash).

Changes to local binaries execution

The preferLocal option now defaults to false. If you are executing locally installed binaries, you’ll need to specify the preferLocal: true option.

Improved spawning of Node.js scripts

We have added execa.node() which (like child_process.fork()) executes a Node.js script as a child process.

It uses the current Node version and options. This can be overridden using the nodePath and nodeOptionsflags.

Graceful exit

Some processes handle the SIGTERM signal in order to cleanup resources and exit gracefully. This might take a long time or even never finish. childProcess.kill() now sends a SIGKILL signal after 5 seconds to prevent this. This can be configured using the forceKillAfterTimeout option.

Process cancellation

Cancelling a child process execution is common, so we added support for it. It behaves like childProcess.kill() but with better error messages and properties.

Enhanced errors

We have improved error messages and properties. Node.js child process errors contain less information, scattered over several events:

Execa produces better errors:

Stricter exit codes

Previously, the exit code could either be a number or a string. That property was removed in favor of exitCode (a number) and exitCodeName (a string).

Gulp plugin

Execute commands in Gulp.js with Gulp Execa. This thin wrapper around Execa adds Gulp-specific features related to verbosity, output, errors and streaming.

More breaking changes

Node.js 6 support has been dropped.

The stripEof option was renamed to stripFinalNewline and the cmd property to command.

execa.stdout() and execa.stderr() have been removed since you can directly use the stdout and stderr properties of the resolved value.

Other updates

The windowsHide option is now always true. This ensures that no window pops up on Windows.

The maxBuffer option default value has been increased from 10 MB to 100 MB.

Several bugs have also been fixed.

For more information, check the full changelog.

Execa 2 release — process execution for humans was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s something wrong with your code. At least, this is what the following warning seems to indicate:

All the tests are passing but this ExperimentalWarning leaves you unsettled. What baffles you is that queueMicrotask() is not directly used anywhere.

Warnings are harder to debug because they are not part of a program’s control flow. Instead, Node.js emits them on the global process. This is also the case for uncaught exceptions and mishandled promises.

Ignoring those process errors is not an option as they usually point to a bug. However, the way they are reported by Node.js is not developer-friendly.

✘ ️Problem 1: lack of context

The issue above would be simple to solve if stack traces had been printed:

It would then be clear that the warning is caused by lolex, a mocking library used in unit tests. A quick search on the GitHub issues would show the root of the problem.

Unfortunately, Node.js does not print stack traces with warnings.

Context is also missing from other process errors such as rejectionHandled. Those are fired when a promise has been handled too late. However, the error message does not show which line of code is to blame:

✘ Problem 2: missing errors

Promises resolved or rejected twice usually indicate a bug.

In the code above, the promise will be resolved with the wrong value because it’s missing return statements:

Node.js tracks those errors with the multipleResolves process event. However, this event is silent by default, which means you would need to handle it yourself in each of your repositories.

This is not as simple at it seems. Since the event handler modifies global state, it should only be used in development when writing a library. It must also avoid triggering another process error itself — otherwise your application will crash with an infinite recursion.

✘ Problem 3: false alarms

Not all process errors indicate a bug.

Some multipleResolves events can be intentional. Also, you might choose to ignore some deprecation warnings.

✘ Problem 4: remote logging

Node.js prints process errors on the console using an unstructured format. This is not ideal when redirecting logs to a dashboard like Rollbar or Sentry.

First it requires parsing the console output to distinguish process errors from regular logs like HTTP requests.

Then the process errors messages themselves need to be parsed in order to log their type (is it an uncaught exception or a warning?) and values (which exception was thrown?) in a structured way.

✘ Problem 5: testing

Test runners like Ava, Jest or Jasmine handle uncaught exceptions and promises. Unfortunately, if process warnings are fired, your tests will still pass.

Testing warnings can be hard since they are emitted globally — outside of the test that triggered them.

Solution

The log-process-errors library solves those problems. It turns Node.js behavior from:

To:

After installing log-process-errors it can be used by using the node -r CLI flag:

or by calling it in JavaScript:

The log transport can be customized. For example to use Winston:

Specific process errors can be skipped:

It can also be used in testing. Ensuring no process errors are fired is as simple as:

Most JavaScript test runners are supported.

Check out the GitHub repository for the full list of options.

Node.js process errors are broken was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.