is-running

library2.1.0jsnpmunverified

The `is-running` package provides a minimalist and direct utility for Node.js environments to ascertain if a process with a specific Process ID (PID) is currently active on the system. As of its latest stable release, `2.1.0`, the library focuses on a single, clear function: returning a boolean indicating the presence of a process for a given PID. The package maintains a stable, albeit infrequent, release cadence, with its core functionality having remained consistent since its last major update. Its primary differentiator lies in its extreme simplicity and lack of external dependencies for runtime, making it a lightweight choice for basic process monitoring or cleanup tasks, especially when compared to more comprehensive process management libraries that offer broader control and information beyond just status checks.

devops

npm install is-running

github ↗package ↗

INSTALL

IMPORT

SIG · IS-RUNNING

is-running

devopsjavascriptv2.1.0

Install

—

Import

—

Disk

—

Pass rate

0/ 6

Env Coverage0 / 6

glibc

18–22

musl

18–22

Install & Compatibility

Where this runs

tested against v? · npm install

Install × environment matrix

Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux

musl

node 18–226 runs

build_error

glibc

node 18–226 runs

build_error

Code

Verified usage

Verified import paths — ran on the pinned version, not inferred.

isrunning

✓ import isrunning from 'is-running';

✗ import { isrunning } from 'is-running';

The package exports a default function. While primarily a CommonJS module, Node.js can typically handle a default `import` statement for such modules. Direct named imports (`{ isrunning }`) will not work as it does not expose named exports.

isrunning

✓ const isrunning = require('is-running');

This is the original and intended way to use the CommonJS module.

isrunning

✓ const isrunning = require('is-running'); // Or for TypeScript without explicit ESM config: // import isrunning = require('is-running');

✗ import isrunning from 'is-running'; // May require 'type: module' or transpilation import { default as isrunning } from 'is-running'; // Not typically required for default exports

The package is a CommonJS module. While `import` syntax may work in environments configured for interoperability or transpilation, `require()` is the native and most robust method. TypeScript users might need `esModuleInterop: true` in `tsconfig.json` for `import` syntax or use `import = require()`.

This quickstart demonstrates how to import and use the `is-running` function to check the status of a process by its PID, including a cross-platform example for common system processes and a check for a non-existent PID.

Debug

Known issues

gotchaThe package's latest version (2.1.0) was released in 2016. It primarily supports CommonJS modules. Modern Node.js projects using ESM (`"type": "module"` in `package.json`) might encounter issues with direct `import` statements without proper transpilation or Node.js's CJS-ESM interop features.

fix

For CommonJS projects, use `const isrunning = require('is-running');`. For ESM projects, consider dynamic import `import('is-running').then(mod => mod.default(pid))` or ensure your build setup correctly handles CommonJS module imports.

affects: <=2.1.0

gotchaThe functionality of `is-running` relies on operating system specifics for checking process IDs. While generally reliable, edge cases or permission restrictions on certain systems might lead to unexpected results or errors if Node.js lacks the necessary permissions to query process information.

fix

Ensure the Node.js process has appropriate permissions to query system process tables. For critical applications, wrap calls in `try-catch` blocks and implement robust error handling and logging.

affects: >=1.0.0

gotchaOn Windows, PID 0 and 4 are special (Idle and System processes, respectively). While `is-running` might return true for these, directly interacting with them via signals (e.g., `process.kill`) is generally not advisable and may not behave as expected or be permitted.

fix

Avoid using `is-running` to determine the existence of privileged or critical system processes (like PID 0 or 4 on Windows) for the purpose of termination or manipulation. Focus on userland processes or processes started by your application.

affects: >=1.0.0

Errors

Common errors & fixes

TypeError: isrunning is not a function

Attempting to call `isrunning` after importing it incorrectly as a named export from a CommonJS module, or calling a property of the imported module rather than the module itself.

fix

Ensure you are importing the default export correctly: `const isrunning = require('is-running');` or `import isrunning from 'is-running';` (for ESM-enabled environments).

Error [ERR_REQUIRE_ESM]: require() of ES Module ... from ... not supported.

Attempting to `require()` an ESM-only module, or using `import` in a CommonJS context without proper configuration, although `is-running` itself is CJS. This error might occur in reverse if a user tries to `import` `is-running` in an ESM context and the module resolution fails, especially if a custom resolver or bundler is involved that expects `"type": "module"`.

fix

For `is-running`, it's a CommonJS module, so `require('is-running')` is the correct method. If you are in an ESM context (`"type": "module"` in `package.json`), `import isrunning from 'is-running';` should work due to Node.js interoperability, but if not, consider `const isrunning = await import('is-running').then(mod => mod.default);` or review your `tsconfig.json` for `esModuleInterop`.

Upgrade

Version history

2.1.0latest on npm

Audit

Dependencies

No dependency data recorded yet.

Agent activity

4 hits · last 30 days

node

Resources

githubhttps://github.com/nisaacson/is-running ↗

packagehttps://www.npmjs.com/package/is-running ↗