WAIT — Slowing — last commit 8mo ago

• Last commit 8mo ago
• 19 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 8mo ago
• ⚠ Concentrated ownership — top contributor handles 69% 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}

@sindresorhus/slugify converts strings into URL-safe, filename-safe slugs while handling transliteration for 100+ languages. It transforms 'Déjà Vu!' → 'deja-vu' and 'я люблю единорогов' → 'ya-lyublyu-edinorogov' using the @sindresorhus/transliterate dependency, with built-in symbol replacements (♥ → love, 🦄 → unicorn) and camelCase splitting (fooBar → foo-bar). Single-file ESM module: index.js exports the main slugify() function, index.d.ts provides TypeScript types, overridable-replacements.js contains the customizable symbol-to-word mapping table, and test.js validates all features via ava.

Full-stack developers, content management systems, and e-commerce platforms that need to auto-generate URL slugs, safe filenames, and IDs from multilingual user input without manual sanitization.

Production-ready: version 3.0.0 with ES modules, Node 20+ requirement, comprehensive test coverage via ava, and active CI/CD (main.yml workflow). Single maintained package with stable, focused scope—no major changes visible but well-tested and commonly used.

Low risk: only 2 production dependencies (transliterate + escape-string-regexp, both maintained by Sindre Sorhus), small surface area (3 shipped files), and no obvious issue backlog visible. Primary risk is single-maintainer dependency on @sindresorhus/transliterate for language support; monitor that upstream library.

No active development signals visible in provided data—appears to be a stable, mature package in maintenance mode rather than active feature development. Check GitHub Actions workflow history and recent commits for actual activity.

git clone https://github.com/sindresorhus/slugify.git
cd slugify
npm install
npm test

Daily commands: This is a library, not an executable. Use npm test to run the ava test suite and xo linter. To use in your project: npm install @sindresorhus/slugify && import slugify from '@sindresorhus/slugify'.

• index.js — Main entry point that orchestrates the slugification logic; all contributors must understand the core algorithm and option handling
• index.d.ts — TypeScript type definitions that define the public API contract; critical for type safety and IDE support
• overridable-replacements.js — Character replacement mappings that enable language support and customization; contributors extending slug behavior must understand this
• package.json — Defines module type (ESM), Node version requirement (>=20), and published artifacts; essential for build and distribution
• test.js — Comprehensive test suite validating core functionality, options, and edge cases; required reading to understand expected behavior

• slugify() (JavaScript ES2020+, String.prototype.normalize(), RegExp) — Main function that orchestrates the full pipeline: merges options, applies custom replacements, normalizes unicode, removes special characters, handles spacing, applies separator, enforces case
  • Failure mode: Returns unmodified input if input is not a string; no error thrown, fails silently
• overridable-replacements export (JavaScript plain object, Object.freeze()) — Provides a frozen object of character mappings (♥ → love, accented chars → base chars, etc.); users can pass custom replacements via options
  • Failure mode: If replacements object is corrupted or missing keys, slugify() still functions using defaults; partial replacements accepted
• Type Definitions (index.d.ts) (TypeScript 4.0+) — Declares function signature, options interface, and return type for TypeScript consumers; no runtime behavior
  • Failure mode: Type mismatches caught at compile-time; no runtime impact if index.d.ts is stale

• User input (string) → slugify() function — Raw string passed as first argument; may contain unicode, special characters, whitespace, mixed case
• Options object → slugify() defaults merge — Optional second parameter with separator, lowercase, and replacements overrides; merged with built-in defaults
• overridable-replacements → String replacement loop — Character map loaded at function call time; each custom replacement applied in sequence
• Normalized string (NFKD) → Regex patterns — Decomposed unicode fed into regex for whitespace trimming, non-alphanumeric removal, separator insertion
• Processed string → Case transformation — If lowercase: true (default), apply toLowerCase(); otherwise preserve input case
• Final string → Return value — Slugified output returned to caller; suitable for URLs, filenames, IDs

Add support for a new special character replacement

1. Open overridable-replacements.js and identify the replacement object (overridable-replacements.js)
2. Add a new key-value pair mapping the special character to its replacement string (e.g., '♫': 'music') (overridable-replacements.js)
3. Add a test case in test.js to verify the character is replaced correctly (test.js)
4. Run npm test to validate the change and ensure no regressions (package.json)

Add a new option to the slugify function

1. Update the options parameter handling in index.js to accept and process the new option (index.js)
2. Update the TypeScript interface in index.d.ts to include the new optional option property with its type (index.d.ts)
3. Add test cases in test.js demonstrating the new option's behavior with different inputs (test.js)
4. Update readme.md with a new #### subsection under 'options' documenting the new parameter (readme.md)

Modify the core slugification algorithm

1. Identify the specific step in the algorithm within index.js (normalization, replacement, spacing, lowercasing, etc.) (index.js)
2. Apply the change and ensure it interacts correctly with custom replacements from overridable-replacements.js (index.js)
3. Run the existing test suite in test.js to ensure no regressions in supported languages or options (test.js)
4. Add new test cases for edge cases introduced by the algorithm change (test.js)

• ES Modules (ESM) — Modern standard for JavaScript module system; package.json specifies 'type': 'module' for native Node.js support without bundler configuration
• Unicode Normalization (NFKD) — Decomposes accented characters (é → e + ´) enabling removal of diacritics and consistent transliteration across multiple languages
• Regular Expressions — Efficient pattern matching for whitespace, non-alphanumeric removal, and word boundary detection during slug generation
• Node.js 20+ — Ensures modern JavaScript features (optional chaining, nullish coalescing) and stable native APIs; aligns with LTS schedule

• Fixed character replacement map in overridable-replacements.js rather than dynamic language detection

  • Why: Simplicity, predictability, and zero runtime overhead; users can override via options parameter
  • Consequence: Users must explicitly handle language-specific edge cases; no automatic language inference but full customization available

• Single function export instead of a class or configuration builder

  • Why: Minimal API surface, easy for simple use-cases, no state management needed
  • Consequence: Options must be passed on every call; cannot reuse configuration across multiple slugify invocations without wrapper functions

• No external dependencies; pure JavaScript implementation

  • Why: Reduces bundle size, deployment complexity, and security surface; faster installation and no transitive dependency vulnerabilities
  • Consequence: All language support and transliteration implemented via lookup tables; more maintenance burden for adding new languages

• Does not perform actual linguistic transliteration or phonetic conversion for all languages
• Does not provide language auto-detection or locale-aware slug generation
• Does not support bi-directional text (RTL) preserving reading order
• Does not create URL-safe hashes or handle collision prevention
• Does not support dynamic or streaming input; operates only on complete strings

• Silent failure on non-string input (Medium) — index.js: If input is null, undefined, or non-string type, the function may return unexpected results or hang; no explicit type validation or early throw
• Potential ReDoS in regex patterns (Low) — index.js: If regex patterns use unbounded quantifiers or nested quantifiers without careful construction, extremely long inputs could cause exponential backtracking
• Global mutable replacements object (Low) — overridable-replacements.js: Export of a frozen object prevents accidental mutation but type system doesn't prevent type coercion exploits in edge cases

• index.js — character replacement loop (Algorithmic complexity) — Iterating over every custom replacement key and applying replace() sequentially; O(n*m) where n=string length, m=replacement map size (~50 entries)
• String.prototype.normalize('NFKD') (undefined) — Unicode norm

Careful with customReplacements: order matters because replacements run sequentially before transliteration. Leading/trailing spaces in replacement strings affect dash separation (key gotcha in docs). The package uses @sindresorhus/transliterate which may silently fail for unsupported languages without error—test with your target languages. Node 20+ is hard requirement.

• Transliteration — Core capability of this library—converts non-Latin scripts (Cyrillic, Arabic, etc.) into phonetic ASCII equivalents; essential to understand how 'я люблю' becomes 'ya-lyublyu'
• Normalization (Unicode) — The library must handle Unicode combining characters and diacritics (é, ü, ñ) consistently; understanding NFC/NFD normalization helps debug international text issues
• Camelcase-to-kebab-case conversion — The decamelize option splits fooBar into foo bar; understanding the algorithm helps extend or debug word boundary detection
• Symbol/emoji replacement tables — The overridable-replacements.js pattern uses lookup tables instead of regex; choosing this approach impacts performance and customizability
• ES Modules (ESM) — The package is pure ESM (no CommonJS export); understanding import/export syntax and the 'type': 'module' package.json flag is required to use and modify this repo
• URL-safe character sets — Slugs must avoid spaces and special characters to be valid URL/filename components; the library removes or replaces chars outside [a-z0-9-_]
• Regex character escaping — The escape-string-regexp dependency is used to safely escape user-provided symbols in customReplacements; regex metacharacters (., *, +) must not be interpreted as regex

• sindresorhus/transliterate — Upstream dependency that provides Unicode-to-ASCII conversion for 100+ languages; slugify builds on top of it
• sindresorhus/decamelize — Extracted utility for converting camelCase to separate words; slugify uses camelCase-to-words logic
• blakeembrey/changecase — Alternative comprehensive string transformation library with similar slug/camelCase features, useful comparison
• getable/url-slug — Alternative slug generator; compare approach and test coverage with sindresorhus/slugify
• sindresorhus/escape-string-regexp — Direct production dependency used for safe regex escaping of custom replacement keys

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 test coverage for overridable-replacements.js

The overridable-replacements.js file is included in the package exports but there's no visible test coverage shown for its API and override mechanisms. This is a core feature that allows users to customize transliteration behavior, making it critical to test thoroughly.

• [ ] Review overridable-replacements.js to understand the override API
• [ ] Add test cases in test.js for creating custom replacement rules
• [ ] Add test cases for merging/extending default replacements
• [ ] Add test cases for edge cases (empty overrides, invalid formats, conflicts)
• [ ] Verify the tests pass with npm test

Complete the 'lower' option documentation in readme.md

The README shows the API section mentions a 'lower' option but the description is cut off (ends with 'Suggest 3'). This option is referenced but not fully documented, leaving users unclear about its behavior and default value.

• [ ] Check index.d.ts to understand the 'lower' option type and default
• [ ] Check index.js implementation to confirm the lower option behavior
• [ ] Add complete documentation in readme.md with description, type, default value, and usage examples
• [ ] Include examples showing difference between lower: true and lower: false
• [ ] Verify readme renders correctly

Add TypeScript type tests for index.d.ts

The package exports TypeScript types but there's no visible type testing (e.g., using tsd or dtslint). This ensures the types match the actual implementation and remain accurate across updates.

• [ ] Install a TypeScript type testing library (e.g., tsd or dtslint)
• [ ] Create a type test file (e.g., test-types.ts or test-d directory)
• [ ] Add tests verifying the slugify function signature matches index.d.ts
• [ ] Add tests for options object type checking (separator, lower, etc.)
• [ ] Add tests for type inference and autocomplete behavior
• [ ] Update package.json scripts to run type tests alongside xo && ava

• Add test cases for all supported languages listed in the transliterate dependency (Arabic, Russian, Vietnamese, German umlauts)—currently no visible language-specific test coverage in test.js
• Document the exact order of operations in a code comment within index.js (custom replacements → transliteration → decamelization → separator insertion → casing) to prevent contributor confusion
• Add example in readme.md showing how to chain customReplacements with the default replacements array (e.g., extending defaults rather than replacing them entirely)

The codebase demonstrates good security practices for a utility library. No critical vulnerabilities were identified. The package uses established, well-maintained dependencies and includes proper TypeScript type definitions. The main security concerns are typical of dependencies: monitoring upstream packages for vulnerabilities and ensuring user input (separator parameter) is properly handled in regex contexts. The project appears well-maintained with automated testing (ava) and linting (xo) in place.

• Low · Dependency on External Transliteration Library — package.json - dependencies. The package depends on '@sindresorhus/transliterate' which performs character transliteration. While this is a legitimate use case, any vulnerabilities in the upstream dependency could affect this package. The dependency is pinned to '^2.0.0', allowing minor version updates that could introduce issues. Fix: Monitor the '@sindresorhus/transliterate' package for security advisories. Consider using exact version pinning (e.g., '2.0.0') if stricter control is needed, or use npm audit regularly to detect vulnerabilities.
• Low · Potential ReDoS via Separator Parameter — index.js - separator parameter handling. The 'separator' option accepts user input without apparent validation. If the implementation uses the separator in a regular expression without proper escaping, it could be vulnerable to Regular Expression Denial of Service (ReDoS) attacks. However, the dependency on 'escape-string-regexp' suggests awareness of this issue. Fix: Ensure the separator parameter is properly escaped using 'escape-string-regexp' before use in any regex patterns. Add input validation to reject overly complex separator values if needed.

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/slugify 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/slugify repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sindresorhus/slugify.

What it runs against: a local clone of sindresorhus/slugify — 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/slugify | 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 ≤ 276 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sindresorhus/slugify. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sindresorhus/slugify.git
#   cd slugify
#
# 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/slugify and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sindresorhus/slugify(\\.git)?\\b" \\
  && ok "origin remote is sindresorhus/slugify" \\
  || miss "origin remote is not sindresorhus/slugify (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 "overridable-replacements.js" \\
  && ok "overridable-replacements.js" \\
  || miss "missing critical file: overridable-replacements.js"
test -f "package.json" \\
  && ok "package.json" \\
  || miss "missing critical file: package.json"
test -f "test.js" \\
  && ok "test.js" \\
  || miss "missing critical file: test.js"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 276 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~246d)"
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/slugify"
  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.