Skip to content

Replace StringHelper with symfony/string - #252

Open
lyrixx wants to merge 1 commit into
mainfrom
worktree-stringhelper-symfony-string
Open

Replace StringHelper with symfony/string#252
lyrixx wants to merge 1 commit into
mainfrom
worktree-stringhelper-symfony-string

Conversation

@lyrixx

@lyrixx lyrixx commented Sep 7, 2026

Copy link
Copy Markdown
Member

Summary

  • Remove Gitonomy\Git\Util\StringHelper, a small mb_*-based wrapper (strlen/substr/strpos/strrpos) with a configurable encoding.
  • Use symfony/string's CodePointString instead, which provides the exact same UTF-8-aware, code-point-based string operations (length(), slice(), indexOf(), indexOfLast()).
  • Drop the now-unneeded direct symfony/polyfill-mbstring requirement (symfony/string already depends on it transitively).

Breaking change: StringHelper and its getEncoding()/setEncoding() are removed. The library now consistently targets UTF-8; Log::getCommits() hardcodes --encoding=UTF-8, matching the previous default (no test or usage relied on a non-default encoding).

Test plan

  • castor cs --dry-run — clean (after running castor cs to apply the two formatting fixes triggered by the new syntax)
  • castor phpstan — no errors
  • castor phpunit — 235 tests, 596 assertions, all passing

StringHelper was a small mb_*-based wrapper (strlen/substr/strpos/strrpos)
with a configurable encoding, used to keep string offsets correct on
multi-byte commit messages, paths and branch names. symfony/string's
CodePointString covers the exact same UTF-8-aware, code-point-based
operations, so drop the custom class in favor of it.

Breaking: StringHelper and its getEncoding()/setEncoding() are removed;
the library now consistently targets UTF-8 (Log::getCommits() hardcodes
--encoding=UTF-8, matching the previous default).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant