[Archibald1948]

The difference (as code)

trim, trimStart, trimEnd, startsWith and endsWith assume their arguments are already strings, so anything else throws, and the few non-string cases they do handle disagree with lodash:

trim(-0);                   // lodash: "-0"     es-toolkit: "0"
trim(1.5, '');              // lodash: "1.5"    es-toolkit: throw TypeError
trim(' a ', null);          // lodash: " a "    es-toolkit: "a"
trim('null', null);         // lodash: ""       es-toolkit: "null"
startsWith(undefined, '');  // lodash: true     es-toolkit: false
startsWith('null', null);   // lodash: true     es-toolkit: false
startsWith(1.5, 1);         // lodash: true     es-toolkit: throw TypeError
endsWith(undefined, '');    // lodash: true     es-toolkit: false
endsWith('xax', 'x', null); // lodash: false    es-toolkit: true
endsWith(1.5, '');          // lodash: true     es-toolkit: throw TypeError

Cause

Lodash coerces each argument before using it, with three different helpers:

function startsWith(string, target, position) {
  string = toString(string);
  position = position == null ? 0 : baseClamp(toInteger(position), 0, string.length);
  target = baseToString(target);
  return string.slice(position, position + target.length) == target;
}

function trim(string, chars, guard) {
  string = toString(string);
  if (string && (guard || chars === undefined)) {
    return baseTrim(string);
  }
  if (!string || !(chars = baseToString(chars))) {
    return string;
  }
  // ...
}

• the string goes through the public toString: null and undefined become '', and -0 becomes '-0';
• chars / target go through the internal baseToString, which differs on nullish values: null becomes 'null', not '';
• position goes through toInteger and is clamped, so null is 0 and '1' is 1.

es-toolkit/compat instead calls string methods on the raw argument (str.toString().trim(), str.startsWith(...)) and returns early when an argument is nullish:

export function startsWith(str?: string, target?: string, position?: number): boolean {
  if (str == null || target == null) {
    return false;
  }
  if (position == null) {
    position = 0;
  }
  return str.startsWith(target, position);
}

So a number, boolean, array or plain object throws instead of being stringified, -0 loses its sign ((-0).toString() is '0', while lodash's toString special-cases it), a null target or chars short-circuits instead of becoming 'null', and a null position is treated as "absent" rather than 0.

Changes

Coerce the arguments the way lodash does, without changing any public signature.

toString already implements lodash's toString exactly, and it had lodash's baseToString as a private helper in the same file. That helper is now src/compat/_internal/baseToString.ts so the string functions can use it too; toString keeps calling it and is unchanged.

export function startsWith(str?: string, target?: string, position?: number): boolean {
  const string = toString(str);
  const search = baseToString(target);
  const index = position == null ? 0 : Math.min(Math.max(toInteger(position), 0), string.length);

  return string.slice(index, index + search.length) === search;
}

export function trim(str?: string, chars?: string, guard?: object): string {
  const string = toString(str);

  if (string && (guard || chars === undefined)) {
    return string.trim();
  }

  const chrs = baseToString(chars);

  if (!string || !chrs) {
    return string;
  }

  return trimToolkit(string, chrs.split(''));
}

trimStart and trimEnd get the same shape, and endsWith mirrors startsWith with lodash's position === undefined ? length : ... rule.

One consequence worth pointing out: chars given as an array is now stringified by baseToString rather than flattened, so trim('a,b', ['a', 'b']) trims the comma too and returns '', which is what lodash returns (baseToString(['a', 'b']) is 'a,b').

Verification

Focused grid against lodash@4.18.1 — 16 string values x 14 chars / target values (x 11 position values for startsWith / endsWith), 5,600 calls:

	mismatches
before	2,655 / 5,600
after	0 / 5,600

2,585 of those 2,655 were "es-toolkit throws, lodash returns a value"; the remaining 70 were wrong values of the four shapes shown at the top.

Broad sweep, every 1- and 2-argument combination of a 35-value pool (1,260 calls per function):

	trim	trimStart	trimEnd	startsWith	endsWith	toString
before	931	931	931	938	938	0
after	0	0	0	0	0	0

toString is unchanged, before and after, which is the check that moving baseToString out of it changed nothing.

Regression tests were added to all five spec files. On main they fail with:

AssertionError: expected '0' to be '-0' // Object.is equality
AssertionError: expected false to be true // Object.is equality

Full suite: 714 files, 5069 passed / 2 skipped. tsc --noEmit clean, yarn lint 0 errors (no new warnings in the touched files), type-tests pass — the public signatures are untouched, so they still match @types/lodash.

Benchmarks

The added work is one toString / baseToString call per invocation. The comparison itself still runs through the native String.prototype methods: string.startsWith(search, index) is specified as string.slice(index, index + search.length) === search, and endsWith(search, end) matches lodash's position arithmetic, so there is no need to build substrings by hand.

Interleaved A/B (fix, then main, five alternating rounds) over the six benchmark files that cover these functions. The Vite dependency cache was cleared before every run, and after every run I checked the pre-bundled es-toolkit/compat for which implementation had been measured (10/10 matched the intended side). Each row is also divided by the lodash row of the same file in the same round, to cancel machine drift:

benchmark	main (hz)	fix (hz)	normalized
trim	4,767,690	4,719,268	-5.0%
trimStart	5,714,237	6,274,198	+9.1%
trimEnd	5,378,338	4,740,514	-3.5%
startsWith	3,370,315	3,338,847	-3.6%
endsWith	3,777,895	3,685,880	-3.2%
toString (unchanged code)	710,158	714,825	-2.2%

A caveat on how much these numbers are worth: my machine was busy while measuring (load average around 6 on 8 cores), single rounds ranged from -40% to +17%, and the untouched lodash controls moved by -5.3% to +2.8%. toString is the useful reference here — its code is identical on both sides, and it still reads -2.2%. So I would summarise this as no measurable change beyond the noise, with a small constant coercion cost that the benchmarks cannot resolve. I am happy to re-run on a quiet machine if you would like tighter numbers.

(An earlier revision of this branch compared with slice(...) === target instead of the native methods and measured clearly worse — that is why the code keeps startsWith / endsWith.)

🤖 Generated with Claude Code

https://claude.ai/code/session_0129BhQdChg7wJry7bWvRHHm

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
es-toolkit	Ready	Preview	Sep 16, 2026 4:43am UTC

[Copilot]

🟡 Changes recommended

Unresolved Lodash evaluation-order and nullish short-circuit mismatches remain in the string helpers.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

This PR aligns compat string helpers with Lodash argument-coercion behavior and adds regression coverage.

Changes:

• Extracts and reuses baseToString.
• Updates trim, prefix, and suffix helpers to coerce arguments and positions.
• Adds regression tests for non-string and edge-case inputs.

File summaries

File	Summary
src/compat/util/toString.ts	Reuses the extracted coercion helper.
src/compat/string/trimStart.ts	Updates leading-trim coercion. Moderate (2 votes): preserve the nullish-input short circuit before coercing chars.
src/compat/string/trimStart.spec.ts	Adds leading-trim regression tests.
src/compat/string/trimEnd.ts	Updates trailing-trim coercion. Moderate (2 votes): preserve the nullish-input short circuit before coercing chars.
src/compat/string/trimEnd.spec.ts	Adds trailing-trim regression tests.
src/compat/string/trim.ts	Updates trim coercion. Moderate (2 votes): avoid coercing chars before the !string short circuit.
src/compat/string/trim.spec.ts	Adds trim regression tests.
src/compat/string/startsWith.ts	Updates prefix matching. Moderate (2 votes): calculate the clamped index before coercing target.
src/compat/string/startsWith.spec.ts	Adds prefix regression tests.
src/compat/string/endsWith.ts	Updates suffix matching. Moderate (1 vote): calculate the end position before coercing target.
src/compat/string/endsWith.spec.ts	Adds suffix regression tests.
src/compat/_internal/baseToString.ts	Extracts the shared Lodash-compatible coercion helper.

Review details

Suppressed comments (1)

src/compat/string/endsWith.ts:26

• Lodash coerces and clamps position before it calls baseToString(target), but this code converts target first. That order is observable when position.valueOf() mutates state read by target.toString(), and can change the boolean result; calculate end before converting target.

  const search = baseToString(target);
  const length = string.length;
  const end = position === undefined ? length : Math.min(Math.max(toInteger(position), 0), length);

• Files reviewed: 12/12 changed files
• Comments generated: 4
• Review effort level: Lite

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[raon0211]

Thanks for the detailed write-up. We're closing this one, though.

All of the inputs here (trim(1.5), startsWith('null', null), endsWith('xax', 'x', null), …) are ones that @types/lodash rejects, so no typed project can make these calls. Matching Lodash for them adds branches to hot-path functions without helping anyone migrate.

We've written this down as a rule: https://github.com/toss/es-toolkit/blob/main/.github/CONTRIBUTING.md#fixing-behavior-that-differs-from-lodash. We accept a compat difference only if the call compiles against @types/lodash in strict mode, or if real code on GitHub makes the call.

If you find a project that passes such input, please reopen with the permalink.

[Archibald1948]

Thank you for the review. Checked it.