tty-browserify

tty-browserify provides a browser-safe stand-in for Node.js’s built-in tty module. When code written for Node.js calls require(‘tty’), Browserify swaps in this package so the bundle doesn’t crash trying to load a module that only makes sense inside a terminal environment.

The implementation is intentionally minimal: isatty() always returns false (a browser context is never a TTY), and the ReadStream and WriteStream constructors throw immediately if anything tries to instantiate them, since there’s no meaningful browser equivalent for a terminal stream. Most consumers never interact with tty-browserify directly — it’s pulled in transparently through Browserify’s node-core shim resolution alongside siblings like os-browserify and path-browserify.

What You Get

• isatty() stub - Always returns false, correctly signaling that a browser is never a TTY.
• ReadStream/WriteStream stand-ins - Constructors that throw clear errors instead of silently returning broken objects when terminal streams are unavailable.
• Zero runtime dependencies - A tiny single-file shim with no dependency tree to audit or bloat a bundle.
• Automatic resolution via Browserify - No manual wiring needed; Browserify’s built-in node-core shim map picks this package for require(‘tty’) automatically.

Common Use Cases

• Bundling CLI-oriented libraries for the browser - A library written for Node that checks process.stdout.isatty() keeps working (returning false) when bundled for web.
• Porting terminal-aware logging libraries - Loggers that branch on TTY detection (e.g., to decide whether to colorize output) get a safe false instead of a bundler crash.
• Legacy Browserify build pipelines - Projects still using Browserify rely on this package as part of the standard node-core shim set Browserify ships with.

Under The Hood

Architecture tty-browserify has no internal architecture to speak of — the entire package is a single index.js file exporting three members directly off module.exports: an isatty() function that unconditionally returns false, and two constructor functions (ReadStream, WriteStream) that immediately throw when invoked. There are no internal layers, no state, and no configuration; the module’s only ‘behavior’ is being present at the require(‘tty’) resolution path so Browserify’s node-core shim map can substitute it for Node’s real tty module during bundling. Nothing breaks if the abstraction changes because there is no abstraction beyond the three exported names — any consumer touching ReadStream or WriteStream already expects an error in a browser context.

Tech Stack The package declares zero runtime dependencies (an empty dependencies object in package.json) and lists only tape ~1.0.4 as a devDependency for its test script (tape test/*.js), though the test/ directory referenced there is not present in this shallow clone. It targets plain CommonJS module.exports with no transpilation, bundler configuration, or build step — the file that ships is the file that’s written. It’s consumed transitively as part of Browserify’s built-in shim table (alongside sibling packages like os-browserify, path-browserify, and stream-browserify) rather than installed directly by most end users.

Code Quality No test files are present in this clone despite package.json declaring a test script, so coverage cannot be verified directly. There are no type annotations (plain JS, no TypeScript or JSDoc types), no linter or formatter configuration, and no CI workflow files visible in the repo. Error handling is limited to two synchronous throw statements; naming is minimal but clear (isatty, ReadStream, WriteStream), mirroring Node’s actual tty API surface closely. Given the absence of visible tests, types, linting, and CI, code quality is best read as ‘no verifiable safety net’ for such a small, stable surface area.

API Design As a shim, tty-browserify’s design goal is faithful minimalism rather than novelty: its three exports mirror Node’s real tty module’s public surface closely enough that consuming code doesn’t need to special-case a browser build. The deliberate choice to throw on ReadStream/WriteStream construction, rather than silently returning a fake object, surfaces incompatibility loudly instead of masking it with a confusing runtime bug. There’s no boilerplate required to use it — it’s resolved automatically by Browserify’s shim map with zero developer configuration. This is standard practice across the browserify node-core shim family, not a distinctive technical contribution.