FAQ

Why does it not check that sourceString is at the position?

Because 1.0.4 never did, and callers rely on that: the function removes as many code units as sourceString is long, whatever they are. Checking would change the answer for calls that work today (('hello', 'xyz', 'abc', 0) gives 'abclo' in both versions). If your position can be stale, guard the call yourself (Recipes).

Why pass sourceString at all, if only its length counts?

That is the 1.x signature, kept so old calls still work. The usual caller has the matched text in hand anyway (match[0] from a regular expression), and passing it reads better than passing its length. To remove a known number of code units, pass any string that long, or use slice directly.

Why does a string position like '1' throw now?

1.0.4 added the position to a length, so '1' became '11' and the call silently dropped the rest of the text. 2.0.0 refuses anything whose type is not number with a TypeError. Convert with Number() first; a value that is not a whole number in range then gets a RangeError (Edge cases and errors).

Why does a position past the end throw, when slice clamps it?

1.0.4 appended there, which looks like clamping but usually hides a position computed for another text. 2.0.0 throws a RangeError for any position above originalString.length; the position equal to the length is still allowed and appends. This was the modernization plan's recommendation (decision D3c in the repository's ai-docs/plans/), and it stood when the maintainer merged 2.0.0; clamping was the alternative it rejected.

Can I pass code point or grapheme positions?

No. Positions are UTF-16 code units, like every JavaScript string index, so a position inside an emoji splits it. Recipes converts a code point index; How text is replaced shows what a split looks like.

Does it replace every occurrence?

No, one part at one position. Use String.prototype.replaceAll for every occurrence, or loop over matchAll from the last match to the first when each edit needs its own position (Recipes).

Does require() still work?

Yes. require('replace-string-at-position') returns the function, as in 1.x, and it also has .default and .replaceStringAtPosition for code compiled from import (Getting started).

Does it run in browsers, Bun, Deno or workers?

Bun 1.4.2 and Deno 2.9.6 ran it for this wiki, and the repository's CI runs its consumer fixtures under both. Browsers and workers were not tested; the builds use no Node or browser APIs, which the repository's tests check (Getting started).

My TypeScript project fails with TS5108 after upgrading TypeScript

TypeScript 7 removed "moduleResolution": "node10" and "esModuleInterop": false. That error comes from your tsconfig.json, not from this package; the package's types work under nodenext and bundler with TypeScript 7.0.2, 6.0.3 and 5.9.3, and under node10 with 6.0.3 and 5.9.3 (Getting started).

Is 1.x deprecated? Will there be a 1.0.5?

Neither. 1.0.4 is not deprecated and still installs, and the plan chose to release 2.0.0 only. A project pinned to ^1.0.4 keeps getting 1.0.4 (Versions and upgrading).

Where did the command-line tool go?

The old README described one, but 1.0.4's package.json had no bin entry, so installing the package never gave a command. 2.0.0 removed the file and the README section.

How fast is it?

It makes two slices and a concatenation, so its time grows with the text's length. No benchmark was run for this wiki (How text is replaced).