build(deps): Replace lodash with just-camel-case just-kebab-case just-split

[honey32]

lodash often get reported as vulnerable for some of its functions, even if this package doesn't internally use the reported function. This vulnerability "propagation" feeds us up. 😫

Then, I think this package has better have alternative and seperated dependencies (for each functions like camelcase, kebabCas, chunk).

I found just family seems to be nice in terms of compatibility(not 100% though), maintenance activeness, and good seperation.

https://github.com/angus-c/just

preliminary investigation by AI Agent

Survey: Case-Conversion Libraries Compatible with lodash

Survey date: 2026-05-22

A survey of libraries that claim compatibility with lodash’s -Case helpers (camelCase, snakeCase, etc.) and packages focused on case conversion. From a supply chain security perspective, narrow-scope options (fewer dependencies, smaller attack surface) are preferred.

Related: change-case Issue #351 (change-case is intentionally incompatible with lodash)

---

Summary

• Almost no case-conversion–only libraries explicitly state “compatible with lodash’s -Case helpers” in their README.
• Close options fall into one of these buckets:
  • The lodash implementation itself (lodash.camelcase, etc., or import from lodash/camelCase)
  • Reimplementations aligned with lodash (tiny-case, just-*-case, camelcase)
  • A lodash compatibility layer (es-toolkit/compat — but the scope is broad)
• change-case is not lodash-compatible (prioritizes reversibility and _ separators at ambiguous boundaries)

---

1. Full compatibility (the lodash implementation itself)

lodash.*case (per-method packages)

Packages that export only case-conversion methods, discoverable via the lodash-modularized keyword on npm.

Package	Maps to
lodash.camelcase	_.camelCase
lodash.snakecase	_.snakeCase
lodash.kebabcase	_.kebabCase
lodash.startcase	_.startCase

• Compatibility: Code exported from the main lodash repo → 100% identical implementation
• Scope: Narrow — one function per package
• Caveat: lodash officially discourages per-method packages (planned removal in v5; installing several tends to bloat node_modules)
• Recommended import: import camelCase from 'lodash/camelCase' or named imports from lodash-es

Supply chain: Same implementation as core lodash. Per-method packages are effectively unmaintained (last published 8–10 years ago), so for new projects, lodash / lodash-es + path imports are more practical.

---

2. Case-conversion focused, with “lodash-aligned” claims or mentions

tiny-case

• URL: https://github.com/jquense/tiny-case
• From the README:

  Extremely minimal string casing utilities that mimic most of lodash's casing behavior, e.g. numbers are considered separate "words".

• Provides: camelCase, snakeCase, kebabCase, pascalCase, titleCase, sentenceCase, words, upperFirst in one package
• Dependencies: 0 dependencies per package.json
• Compatibility: “most” ≠ all; no guarantee of passing lodash’s full official test suite
• Adoption: Few GitHub stars, last updated around 2022 — weaker audit/maintenance confidence than lodash / just

Narrow scope is good for supply chain, but it is closer to “a small implementation modeled on lodash” than “advertised lodash compatibility”.

camelcase (sindresorhus)

• URL: https://github.com/sindresorhus/camelcase
• Scope: camelCase only (related: decamelize, camelcase-keys)
• lodash mention: With capitalizeAfterNumber: true (default), docs state it aligns with many utilities such as Lodash
• Compatibility: Not a full -Case suite; no drop-in guarantee

Supply chain: Good as a single-purpose, popular, low-dependency package, but not suitable when you need the full set of -Case helpers.

just-camel-case / just-snake-case, etc. (angus-c/just)

• URL: https://github.com/angus-c/just
• npm: just-camel-case, just-snake-case, etc.
• Scope: One function = one package
• Dependencies: 0 dependencies (the just project policy)
• lodash compatibility: README does not say “lodash compatible”, but in Issue #111 the maintainer states that from v4.0.2 onward behavior is very close to lodash and passes the reporter’s tests
• Compatibility: “very similar” — not a guarantee of bit-for-bit identity

Supply chain: Single-purpose, zero-dependency, proven just family fits requirements well. Multiple -Case helpers mean more packages, but each tarball stays small.

---

3. Explicit lodash compatibility, but broad scope

es-toolkit es-toolkit/compat

• URL: https://es-toolkit.dev/
• Docs label APIs such as camelCase (Lodash compatibility)
• Examples: camelCase, snakeCase, kebabCase, startCase, lowerCase, upperCase, capitalize, etc.
• PR #517 and CHANGELOG entries document fixes to match lodash behavior
• Separately, es-toolkit/string offers a “modern, faster” API whose behavior can differ from compat

Supply chain: Strong lodash alignment, but the compat layer is a wide lodash substitute, so the attack surface is larger than “string case only” unless you import only what you need.

---

4. Not lodash-compatible / does not claim to be

Library	Notes
change-case	Intentionally differs from lodash for reversibility (Issue #351)
case-anything	Lightweight, many cases; no lodash compatibility claim
scule (UnJS)	Case conversion focused; no explicit lodash compatibility

change-case vs lodash (from Issue #351)

Around numbers, change-case inserts _ by default (mergeAmbiguousCharacters: false).

Input	lodash expected	change-case actual
too legit 2 quit	tooLegit2Quit	tooLegit_2Quit
walk 500 miles	walk500Miles	walk_500Miles
enable 6h format	enable6HFormat	enable_6hFormat

Reason: Round-trip conversion (e.g. xhr2Request → xhr2 request). Setting mergeAmbiguousCharacters: true moves some cases closer to lodash.

---

Comparison table

Option	lodash compatible	Narrow scope	Supply chain
lodash/camelCase, etc. (lodash-es)	◎ Same implementation	△ Large repo; import one function	◎ Most audited; tree-shake required
lodash.camelcase, etc.	◎	◎ One function/pkg	△ Discouraged, stale updates, duplication if many
just-*-case	○ Mostly (tests cited)	◎ One function/pkg, 0 deps	◎ Small, split packages
tiny-case	△ “most”	◎ Multiple cases in one pkg, 0 deps	△ Low visibility, infrequent updates
camelcase	△ camelCase only	◎	◎ sindresorhus ecosystem
es-toolkit/compat	◎ Documented Lodash compatibility	✗ Broad compat layer	△ Mitigate by importing only needed APIs
change-case	✗ Intentionally incompatible	○ Case conversion focused	○ Popular, actively maintained

---

Practical recommendations

lodash compatibility is the top priority

Use lodash-es:

import { camelCase, snakeCase } from 'lodash-es';

Or:

import camelCase from 'lodash/camelCase';

Avoid adopting per-method lodash.camelcase packages for new work.

Minimize dependency count (supply chain focus)

Use just just-camel-case / just-snake-case, etc. (0 deps, single responsibility). Multiple case helpers mean more packages, but each tarball stays small.

Bundle multiple case helpers in one package

tiny-case is a candidate, but it is safer if you pin lodash’s official test vectors in your own CI (because it only “mimics most” behavior).

Case-only libraries that say “lodash compatible” in the README

Within this survey, almost none exist. Options are mainly lodash per-method extractions, lodash-aligned reimplementations, or es-toolkit/compat.

---

Supply chain operations notes

• Do not rely on a single README sentence — pin lodash’s test cases in your project for evidence of compatibility
• Lock pnpm-lock.yaml, run npm audit; zero-dependency single-purpose packages (just family) often reduce attack surface versus one large utility library
• Packages like tiny-case with few stars and infrequent updates carry maintenance risk even when dependency count is zero

---

References

• change-case Issue #351 — camelCase function appears incorrect
• lodash per method packages (discouraged)
• just Issue #111 — just-camel-case not a drop-in replacement for lodash.camelcase
• es-toolkit — camelCase (Lodash compatibility)
• es-toolkit PR #517 — add snakeCase, etc. to compat layer

[islobodiuk-figma]

hi @honey32, thanks for your suggestion. Is there any vulnerability report for the 4.18.1 version of lodash?

[honey32]

@islobodiuk-figma No, I'm just concerned about possibile discover of vulerability in the future