# @environment-safe/runtime-context

> vanilla, browser compatible es module to reveal the executing context

Latest version **0.0.6** (published 2026-04-11) · MIT license · 0 weekly downloads

## Install

```sh
npm install @environment-safe/runtime-context
pnpm add @environment-safe/runtime-context
yarn add @environment-safe/runtime-context
bun add @environment-safe/runtime-context
```

## Health

**Score 50/100 (C)** — status: active.

Positive: esm support; no vulnerabilities.

Warnings: low downloads; no types; pre 1.0.

## Facts

| | |
|---|---|
| Version | 0.0.6 |
| Published | 2026-04-11 |
| First published | 2023-09-24 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | none |
| Module format | ESM + CommonJS |
| Dependencies | 0 |
| Unpacked size | 41.5 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| GitHub stars | 0 |
| Author | Abbey Hawk Sparrow |
| Maintainers | khrome |

## Links

- npm: https://www.npmjs.com/package/@environment-safe/runtime-context
- Repository: https://github.com/environment-safe/runtime-context
- Issues: https://github.com/environment-safe/runtime-context/issues
- npm.io page: https://npm.io/package/@environment-safe/runtime-context

## Recent versions

- 0.0.6 (latest) — 2026-04-11
- 0.0.5 — 2026-04-10
- 0.0.4 — 2026-03-25
- 0.0.3 — 2025-05-05
- 0.0.2 — 2025-04-27
- 0.0.1 — 2023-09-24

## README

@environment-safe/runtime-context
=================================
There are situations where browser support and server support never even *tried* getting on the same page. ex: consider that URL paths all use unix separators, while `file:` urls use platform specific paths and node.js URLs uses both `file:` paths (but with a different interaction pattern) and native paths. In addition most of the places you have access to poll are standard locations which are the same from platform to platform.

Essentially the standards bodies invent something new every time the problem appears.

Imagine how much simpler node would have been with all posix paths and virtual locations for platform specific weirdness?

In these situations you need specific detail about what the running scenario is. That's what this module does. In addition it fixes some logic to make server and client OS detection symmetrical and augments the `detect-browser` code (It now detects a wide array of operating systems).

Usage
-----

```javascript
import { 
    isBrowser, 
    isNode, 
    isWebWorker, 
    isElectron, 
    isElectronRenderer,
    isElectronMain,
    isElectronBrowser,
    isJsDom, 
    isDeno,
    isBun,
    isClient, // is running a client
    isServer, // is running on a server runtime
    variables, // global variables
    isLocalFileRoot, // run within a page using a file: url
    isUrlRoot, //run within a page with a served url
    isServerRoot, //run within a 
    os, // Operating system, machine friendly
    operatingSystem, // Operating System, label
    runtime // server runtime name or browser name
    hasHead // has a running browser environment
} from '@environment-safe/runtime-context';
```

Testing
-------

Run the es module tests to test the root modules
```bash
npm run import-test
```
to run the same test inside the browser:

```bash
npm run browser-test
```
to run the same test headless in chrome:
```bash
npm run headless-browser-test
```

to run the same test inside docker:
```bash
npm run container-test
```

Run the commonjs tests against the `/dist` commonjs source (generated with the `build-commonjs` target).
```bash
npm run require-test
```

Development
-----------
All work is done in the .mjs files and will be transpiled on commit to commonjs and tested.

If the above tests pass, then attempt a commit which will generate .d.ts files alongside the `src` files and commonjs classes in `dist`

---
_Source: https://npm.io/package/@environment-safe/runtime-context · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._