js-string-escape

js-string-escape is a minimal, dependency-free utility that turns any string into the body of a valid JavaScript string literal. It escapes exactly the characters the ECMAScript 5.1 grammar requires — double quotes, single quotes, backslashes, and the four LineTerminator characters (\n, \r, U+2028, U+2029) — so the result can be safely wrapped in either quote style and re-evaluated back to the original value, even for untrusted input.

Non-string arguments are coerced to strings first, matching JavaScript’s own semantics, and the test suite verifies the escaping invariant across every Unicode code point in the Basic Multilingual Plane as well as astral-plane characters. It has been a long-running transitive dependency of several build-tooling and templating packages that need to safely inline arbitrary data into generated JavaScript source.

What You Get

• A single module.exports function, jsStringEscape(string), with no configuration surface
• Escaping for double quotes, single quotes, backslashes, and all four LineTerminator characters per ECMA-262 7.8.4
• Automatic coercion of non-string arguments (numbers, booleans, null, undefined, objects) to strings before escaping
• A test suite (tap) that verifies the escape/eval round-trip invariant across every BMP and astral Unicode code point

Common Use Cases

• Code generation - Templating engines and bundlers that inline dynamic string data into generated JavaScript source use it to guarantee the emitted literal re-parses to the original value.
• Server-side rendering of inline scripts - SSR frameworks embed dynamic values into <script> tags after escaping so untrusted strings can’t break out of the literal.
• Safe eval-based serialization - Any code path building a string literal via concatenation rather than JSON.stringify relies on it to keep the eval(...) === original invariant intact.
• Legacy build tooling dependency - Numerous older bundler/templating packages pull it in transitively as their string-escaping primitive rather than re-implementing the ECMA-262 escape table.

Under The Hood

Architecture js-string-escape ships as a single CommonJS module (index.js) exporting one function that runs a String.prototype.replace with a character-class regex and a switch statement mapping each matched character to its escaped form; there are no internal layers, classes, or abstractions because the problem — mapping a fixed set of ECMAScript LineTerminator and quote characters to escape sequences — doesn’t need any. Non-string inputs are coerced via string concatenation ('' + string) before the replace runs, so the entire public contract collapses to one pure function with no state, no configuration, and nothing that would break if the surrounding code changed.

Tech Stack The package targets plain Node (engines: node >= 0.8) with zero runtime dependencies; its only devDependencies are tap (>0.4.2) for the test runner and a pinned local copy of punycode (>1.2.1) used solely to generate astral-plane code points in the test suite, since Node 0.8’s built-in Punycode.js was outdated. There is no build step, bundler, or transpilation — index.js is shipped and required as-is, and .travis.yml runs the test suite against Node 0.10, 0.12, and io.js.

Code Quality test/test.js exercises three cases: a basic quoting example, an invariant check that walks every BMP code point plus every astral code point (via Punycode-generated UCS-2 encoding) and asserts eval("'" + escaped + "'") === original and the double-quote equivalent, and a coercion check for null/undefined/booleans/numbers/objects. That invariant test is unusually thorough for a package this size — effectively an exhaustive-input test. There is no TypeScript, no linter config, and no modern CI (Travis, last configured for Node 0.10/0.12/io.js, is defunct); error handling isn’t applicable since the function can’t throw on any input.

What Makes It Unique The API surface is a single function taking one argument and returning a string — no configuration object, no options, nothing to look up beyond the one README example, so the adoption barrier is effectively zero. Functionally it isn’t novel: the same escaping logic exists inline in many templating and code-generation libraries, and modern code can often reach for JSON.stringify plus manual quote-swapping instead. Its value is being exactly this — a single well-tested, dependency-free unit doing one narrow spec-defined transform, extracted so other packages don’t have to re-derive the ECMA-262 escaping table themselves.