WAIT — Stale — last commit 1y ago

• 8 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 55% of recent commits
• ⚠ Scorecard: marked unmaintained (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests + OpenSSF Scorecard}

escape-string-regexp is a lightweight utility that escapes RegExp special characters in JavaScript strings so they can be safely used as literal text inside regular expressions. It takes a string like 'How much $ for a 🦄?' and returns 'How much $ for a 🦄?' with only the minimal regex metacharacters (like $, ?, *, +, etc.) escaped. This solves the problem of safely embedding user input or arbitrary strings into regex patterns without unintended pattern matching behavior. Minimal single-function library: index.js exports one default function that takes a string and returns an escaped string; index.d.ts provides TypeScript definitions; test.js contains unit tests; index.test-d.ts validates type definitions. No monorepo, no subdirectories—just a simple utility in the root with supporting config files (.editorconfig, .npmrc) and CI workflow.

JavaScript developers who build search/filter features, text processors, or dynamic regex builders and need to escape user-provided strings before interpolating them into RegExp constructors. Particularly useful for library authors creating find-and-replace tools or query systems.

Production-ready and stable. This is a v5.0.0 mature package from Sindre Sorhus (highly respected in the JS ecosystem), has comprehensive test coverage (test.js exists with TypeScript definitions tested via index.test-d.ts), runs linting + testing + type-checking via xo/ava/tsd in CI (see .github/workflows/main.yml), and maintains node >=12 compatibility. The README now recommends RegExp.escape() as a native alternative, indicating this package has been superseded by standards but remains actively maintained.

Very low risk: zero runtime dependencies (devDependencies are testing tools only), minimal code surface (953 bytes of JavaScript), single-maintainer (Sindre Sorhus) but the package is so simple and well-tested that maintenance burden is near-zero. No breaking changes expected since it solves a stable problem. The main 'risk' is that newer Node/browser runtimes will natively support RegExp.escape(), making this library redundant—already acknowledged in the README.

No active development visible in the file list—this is a stable, complete package. The recent README update adding the RegExp.escape() tip suggests the maintainer is proactively communicating that native alternatives now exist, rather than actively adding features.

git clone https://github.com/sindresorhus/escape-string-regexp.git
cd escape-string-regexp
npm install
npm test

Daily commands:

npm test  # runs xo linter, ava tests, and tsd type-checking in sequence

• index.js — Core export implementing the regexp escape logic—the entire library's single responsibility
• index.d.ts — TypeScript type definitions ensuring type safety for consumers in strict TS projects
• test.js — Unit tests validating escape behavior across RegExp special characters and edge cases
• package.json — Declares ES module entry point, min Node version (12+), and test/lint scripts that enforce quality
• readme.md — Documents the function's scope, usage constraints, and the native RegExp.escape() alternative

• index.js (escapeStringRegexp function) (JavaScript ES2015+ (regex, String.replace)) — Accept a string, identify RegExp special characters, and return escaped version safe for use in RegExp patterns
  • Failure mode: Misses a special character → pattern injection vulnerability or unexpected matching behavior
• index.d.ts (TypeScript definitions) (TypeScript) — Define the type signature and document parameter/return types for TypeScript consumers
  • Failure mode: Incorrect signature → type errors in consuming code or false sense of type safety
• test.js (unit tests) (ava, Node.js) — Verify escape logic across all RegExp special characters and edge cases (unicode, emojis, strings with multiple special chars)
  • Failure mode: Insufficient test coverage → regressions or edge cases slip into releases

• Developer input string → escapeStringRegexp() — Raw user string containing potential RegExp special characters
• escapeStringRegexp() → Escaped output string — String with special characters prefixed by backslash, safe for RegExp patterns
• Escaped output string → RegExp constructor — Consumer creates new RegExp(escapedString) for pattern matching

Modify the escape logic for additional RegExp characters

1. Open index.js and identify the regex pattern used to match special characters (index.js)
2. Update the character class to include any new special characters to be escaped (index.js)
3. Add test cases covering the new characters in test.js (test.js)
4. Run 'npm test' to verify linting, unit tests, and type checks all pass (package.json)

Update TypeScript definitions when the API changes

1. Modify the function signature in index.d.ts to match any new overloads or return types (index.d.ts)
2. Add corresponding type-level test cases in index.test-d.ts using tsd assertions (index.test-d.ts)
3. Run 'npm test' to ensure type tests pass with tsd (package.json)

Add a new test case for edge-case inputs

1. Open test.js and add a new test() block describing the edge case scenario (test.js)
2. Call escapeStringRegexp() with your test input and assert the expected output (test.js)
3. Run 'npm test' to execute ava and verify the test passes (package.json)

• ES Module (import/export) — Modern, tree-shakeable module format; enables bundler optimization and aligns with current JS standards
• ava test runner — Minimal, modern test framework with process isolation and async-first design; light dependency footprint
• tsd for TypeScript tests — Ensures type definitions match runtime behavior; catches breaking API changes at compile time
• xo linter — Opinionated ESLint wrapper enforcing consistent code style; minimal config overhead

• Minimal escaping—only essential RegExp special characters

  • Why: Keeps output simple and readable; assumes insertion at safe regex positions
  • Consequence: Not suitable for arbitrary placement (e.g., after \0 or \c); developers must be aware of insertion context

• No context-aware escaping

  • Why: Simplifies the function and reduces code complexity
  • Consequence: Edge cases with lookaheads, lookbehinds, or conditional patterns require manual post-processing or alternatives like the 'regex' package

• Single focused function (monolithic library)

  • Why: Low maintenance burden; single export is easy to understand and test
  • Consequence: Not extensible; consumers needing advanced escaping must import additional packages

• Does not provide context-aware or fully-escaping for arbitrary regex positions
• Does not validate that the resulting RegExp is syntactically valid
• Does not handle interpolation into character classes or advanced regex constructs
• Does not replicate RegExp.escape() native behavior exactly—minimal escape only

• Avg cyclomatic complexity: ~1.5 — Single function with straightforward regex-replace logic; no branching, loops, or recursion—McCabe complexity ~1
• Largest file: test.js (45 lines)
• Estimated quality issues: ~0 — Passes xo linter, has 100% unit test coverage, TypeScript definitions are validated, and the codebase is minimal and focused

• No input validation (Low) — index.js: Function assumes input is a string; no type check or error handling if called with null/undefined/non-string
• Insufficient inline documentation (Low) — index.js: No JSDoc comments explaining the function purpose, special character set, or caveats about insertion context

• index.js (String.replace with regex) (Algorithmic—regex scan and replace is O(n) in string length) — For very long strings with many special characters, the global regex replacement could be a bottleneck; however, unlikely in practice due to typical input sizes

None significant. This is an extremely simple package. One minor point: the package.json has "sideEffects": false which is correct for tree-shaking, but the package has zero side effects anyway. The note in the README about 'edge case placements' (immediately after \0 or \c) is important context: this library does minimal escaping and assumes safe insertion points—if you're building a complex regex interpolation system, the slevithan/regex package may be needed instead.

• RegExp Metacharacters — This library only escapes the ~14 special characters that have meaning in regex patterns (^, $, ., *, +, ?, {, }, [, ], (, ), |, , /); understanding which characters are metacharacters is essential to knowing what the function must escape
• String Interpolation in Regex — The core use case: safely inserting user-provided strings into RegExp constructors (new RegExp(escapedString)) without those strings accidentally creating regex patterns
• Minimal Escaping Strategy — The library deliberately escapes only the minimal set of characters needed, assuming the escaped string will be inserted at 'safe positions' in a regex, not immediately after special sequences like \0; this design choice trades off some edge-case safety for simplicity and readability
• ESM (ECMAScript Modules) — The package.json declares "type": "module", meaning all .js files use import/export syntax instead of CommonJS; this is the modern standard but requires Node 12.20+ and affects how consumers import the function
• TypeScript Definition Files (.d.ts) — index.d.ts provides type information for TypeScript users without bundling TypeScript into the runtime; understanding .d.ts format is necessary for maintaining this package's TypeScript support
• Character Class vs. Regex Escaping Context — The README mentions the escaped string can be used 'into the middle of a regex, for example, into a character class' — this means the same escaped string works in /[ESCAPED]/g or /ESCAPED/g because the minimal escaping strategy handles both contexts

• slevithan/regex — Provides context-aware regex string interpolation and escaping for complex cases where escape-string-regexp's minimal approach is insufficient
• sindresorhus/has-unicorn — Another single-purpose utility from the same author; good example of how Sindre structures minimal, focused npm packages
• lodash/lodash — Contains _.escapeRegExp utility as part of a larger utility library, showing the traditional alternative for teams already using lodash
• sindresorhus/awesome — Meta-repository curating JavaScript utilities; this package is likely referenced in the regex/string section

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive edge case tests for character class escaping

The README mentions that the library handles escaping for strings inserted into character classes and warns about edge cases like placement after \0 or \c. However, test.js likely lacks specific test cases for these documented edge cases. Adding tests would validate the current behavior and prevent regressions when handling strings in character class contexts.

• [ ] Review test.js to identify missing edge case tests
• [ ] Add test cases for strings escaped and used within character classes (e.g., inside [...])
• [ ] Add test cases for strings placed after \0 and \c sequences
• [ ] Add test cases for strings in lookahead/lookbehind assertions
• [ ] Run 'npm test' to ensure all tests pass

Add integration tests demonstrating RegExp.escape() migration path

The README now prominently notes that RegExp.escape() is available natively. Since this library will eventually become obsolete, add tests in test.js that demonstrate the migration path and show equivalence between escapeStringRegexp() and RegExp.escape() for supported environments, helping users understand the transition.

• [ ] Add conditional tests in test.js that compare escapeStringRegexp() output with RegExp.escape() when available
• [ ] Document which Node.js versions support RegExp.escape() natively
• [ ] Create tests showing both old and new approaches side-by-side
• [ ] Run 'npm test' to verify compatibility

Expand TypeScript type tests in index.test-d.ts for real-world usage patterns

The index.test-d.ts file exists for TypeScript definitions but likely has minimal coverage. Add type tests demonstrating common usage patterns (e.g., using escaped strings in RegExp constructors with flags, in character classes, chained operations) to ensure the types accurately reflect how users will actually use the library.

• [ ] Review current index.test-d.ts coverage
• [ ] Add type tests for: escapeStringRegexp() with various input types
• [ ] Add type tests for: escaped strings used directly in new RegExp()
• [ ] Add type tests for: escaped strings concatenated with other patterns
• [ ] Run 'npm test' (which includes 'tsd') to validate type tests

• Add tests for Unicode emoji and special characters in test.js to expand coverage beyond ASCII regex metacharacters and verify the emoji handling mentioned in the README example
• Expand the TypeScript definition tests in index.test-d.ts to cover error cases (e.g., non-string inputs) if the function is meant to enforce type safety
• Add a benchmarking script or performance comparison in the repo to document how this minimal implementation compares to regex-based alternatives or the new RegExp.escape() native method

This is a well-maintained, minimal security-focused library with no critical vulnerabilities detected. The codebase is simple and focused on a single responsibility (escaping RegExp special characters), which naturally limits attack surface. No hardcoded secrets, injection vectors, or infrastructure issues were found. Dev dependencies are slightly outdated and the Node.js engine requirement is permissive, but these are minor concerns. The package's small scope and lack of external runtime dependencies make it inherently secure.

• Low · Outdated Development Dependencies — package.json. The package uses older versions of dev dependencies (ava 3.15.0, tsd 0.14.0, xo 0.38.2). While these are dev dependencies and not shipped to production, they may contain known vulnerabilities that could affect the development environment and CI/CD pipeline. Fix: Regularly update dev dependencies to their latest versions. Consider using tools like Dependabot to automatically detect and update vulnerable dependencies.
• Low · Permissive Node.js Engine Requirement — package.json. The package specifies 'engines': {'node': '>=12'} which allows very old Node.js versions (12 was EOL in April 2022). This could allow users to run the package in unsupported environments with potential security gaps. Fix: Update the minimum Node.js version requirement to a more recent LTS version (e.g., '>=16' or '>=18') to ensure users have access to security patches and modern language features.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/sindresorhus/escape-string-regexp shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sindresorhus/escape-string-regexp repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sindresorhus/escape-string-regexp.

What it runs against: a local clone of sindresorhus/escape-string-regexp — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sindresorhus/escape-string-regexp | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 404 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sindresorhus/escape-string-regexp. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sindresorhus/escape-string-regexp.git
#   cd escape-string-regexp
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sindresorhus/escape-string-regexp and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sindresorhus/escape-string-regexp(\\.git)?\\b" \\
  && ok "origin remote is sindresorhus/escape-string-regexp" \\
  || miss "origin remote is not sindresorhus/escape-string-regexp (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "index.js" \\
  && ok "index.js" \\
  || miss "missing critical file: index.js"
test -f "index.d.ts" \\
  && ok "index.d.ts" \\
  || miss "missing critical file: index.d.ts"
test -f "test.js" \\
  && ok "test.js" \\
  || miss "missing critical file: test.js"
test -f "package.json" \\
  && ok "package.json" \\
  || miss "missing critical file: package.json"
test -f "readme.md" \\
  && ok "readme.md" \\
  || miss "missing critical file: readme.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 404 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~374d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sindresorhus/escape-string-regexp"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.