sprintf-js

Complete JavaScript sprintf implementation for the browser and Node.js

Library
npm
v1.1.3
2,139stars
BSD 3-Clause License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
44/100Fair
Development Activity0
Maintenance0
Community76
Maturity60
Momentum40

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
56/100Fair
Architecture50
Code Quality55
Innovation45
Learning Curve75

sprintf-js brings the full C-style sprintf format specification to JavaScript, supporting positional arguments, named/keyword placeholders, padding, sign control, and all the standard numeric and string type specifiers. It works identically in Node.js and browser environments, with an optional AngularJS wrapper for template-friendly formatting.

The library is intentionally small and dependency-free, focusing on doing one thing — string formatting — thoroughly. It is widely used as a building block inside logging libraries, CLI tools, and templating engines that need predictable, locale-independent string interpolation.

What You Get

  • A sprintf(format, ...args) function supporting the full classic format-specifier syntax (%s, %d, %f, %x, %j, etc.)
  • A vsprintf(format, argsArray) variant for passing arguments as an array rather than variadic parameters
  • Named/keyword placeholder support (e.g. %(name)s) for formatting against object properties instead of positional args
  • Argument index swapping (e.g. %2$s %1$s) so placeholders can reference arguments out of order
  • An optional AngularJS module exposing sprintf/vsprintf as fmt/vfmt filters

Common Use Cases

  • Building formatted log lines inside a logging library without pulling in a heavier templating engine
  • Generating user-facing strings with padding/alignment (e.g. columns in CLI output)
  • Interpolating values into templates using named object keys rather than positional arguments
  • Producing locale-independent numeric formatting (hex, octal, binary, fixed precision) for debugging output

Under The Hood

Architecture - The entire implementation lives in a single IIFE in src/sprintf.js (231 lines): a regex table (re) recognizes format-specifier tokens, sprintf_parse tokenizes the format string into a mixed array of literal string chunks and placeholder-descriptor objects (capturing param index, keys for named access, sign/padding/width/precision flags, and type), and sprintf_format walks that parse tree once, resolving each placeholder against the argument list (or nested object keys for named placeholders) and applying padding/sign/precision before concatenating into the output string. vsprintf is a one-line wrapper that spreads an array into sprintf’s variadic call. A separate src/angular-sprintf.js (24 lines) registers the same two functions as an AngularJS module/filter pair. Tech Stack - Zero runtime dependencies; the only devDependencies are eslint, mocha, and gulp for linting/testing/building the UMD bundle in dist/. The package.json main points straight at the untranspiled src/sprintf.js, so consumers get the same code whether they import from src/ or the built dist/ bundle. Code Quality - test/ contains a mocha suite exercising each type specifier, named-argument access, and edge cases (undefined property access throws a descriptive error); code style is enforced via .eslintrc.js and run as a pretest hook. There are no TypeScript types shipped in the package itself (community @types/sprintf-js exists separately), and the regex-driven parser, while compact, has essentially no inline documentation beyond variable names. API Design - The two-function surface (sprintf, vsprintf) mirrors the C standard library’s naming exactly, which makes it instantly familiar, and the format-specifier language documented in the README covers positional swapping, named keys, and computed (function) values — but the terse single-letter regex variable names (ph, k, arg) inside the implementation itself would be a barrier for anyone extending the parser rather than just consuming the public API.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search