js-levenshtein

js-levenshtein is a zero-dependency npm package that computes the Levenshtein distance — the minimum number of single-character edits needed to transform one string into another — between two input strings. It implements the classic Wagner-Fischer dynamic programming algorithm but replaces the usual two-dimensional matrix with a single rolling distance vector, unrolls the inner loop four elements at a time, and strips shared prefixes and suffixes before the comparison begins, so it consistently outpaces popular alternatives like fast-levenshtein and leven in benchmarks.

The library ships as a single small CommonJS module with no runtime dependencies, exporting one function that takes two strings and returns their edit distance as an integer. It’s commonly used for fuzzy string matching, spell-check suggestions, autocomplete ranking, and deduplication of near-identical records.

What You Get

• A single exported function, levenshtein(a, b), that returns the edit distance between two strings as an integer
• An algorithm optimized with a single distance vector instead of a full matrix, reducing memory allocation
• Loop unrolling and common-prefix/suffix trimming baked into the implementation for measurably faster comparisons than similar packages
• A zero-dependency, tiny CommonJS module with no external runtime requirements

Common Use Cases

• Fuzzy search and autocomplete ranking by string similarity
• Spell-check and “did you mean” suggestion engines
• Deduplicating near-identical records or detecting typos in user input
• Comparing search queries against catalog entries for approximate matching

Under The Hood

Architecture js-levenshtein is a single-file micro-library: index.js exports one function produced by an immediately-invoked function expression that closes over a private _min helper, with no supporting directory structure, build step, or public sub-modules. The design trades conventional layering for a flat, self-contained computation: the exported function performs early-exit checks (equal-string short circuit, swapping to compare the shorter string second, common prefix/suffix trimming) before falling into a tight loop that walks the two strings and mutates a single reused distance vector in place. Because everything lives in one function scope, there’s no abstraction to break if internals change — the entire surface area a caller depends on is the one function signature levenshtein(a, b).

Tech Stack The runtime has zero production dependencies and targets plain Node.js (engines.node >= 0.10.0) and any environment supporting CommonJS’s module.exports. Development tooling is limited to testing via ava, linting via xo, and benchmarking via matcha, with several competing edit-distance packages (fast-levenshtein, leven, talisman, levenshtein-edit-distance) pulled in purely as benchmark comparators in bench.js, not as runtime dependencies. There’s no bundler, transpiler, or TypeScript build step — index.js is shipped and required as-is.

Code Quality Tests live in a single test.js file using ava, asserting the function’s output against a comprehensive set of string pairs including short ASCII words, longer sentences, and multi-byte CJK text — but the suite is one test block rather than individually named cases, and there’s no coverage tooling or currently active CI (the repo’s only CI config, .travis.yml, targets a build service unused since the project’s last real commit). There’s no explicit error handling or input validation — the function assumes both arguments are strings and doesn’t guard against null/undefined/non-string input. Naming is terse but consistent (_min, d0-d3, bx0-bx3), with no type definitions or JSDoc annotations.

API Design The public API is a single function with no configuration options, options object, or class to instantiate — require('js-levenshtein')(a, b) is the entire contract, which makes onboarding essentially instantaneous. That minimalism comes at a cost for TypeScript consumers: the package ships no bundled type declarations, so consumers must reach for a community @types package or write their own ambient declaration, and being CommonJS-only means ESM consumers need default interop rather than a native named export.