Tckimlik Laravel Package

Technical Evaluation

Architecture fit: epigra/tckimlik is a narrowly scoped validation utility for Turkish Republic identification numbers (TCKN). It is a leaf dependency — no service provider coupling, no persistence, no queue/event surface — so it slots into a Laravel app as a composable validator rule or a small value-object check. v1.2.0 changes only the internal trUpper helper to delegate to PHP's Transliterator structure, which is a correctness fix for Turkish locale casing (the dotted/dotless i problem), not an architectural change. Package shape and public surface are unchanged.

Integration feasibility: Straightforward. Add via Composer, use the validation rule on form requests or call the check directly in a domain service. Because the release touches only an internal helper, existing call sites should compile and behave identically for the overwhelmingly common case (valid/invalid TCKN). Effort is measured in hours, not sprints.

Technical risk: The material risk in this release is the implicit dependency shift. Transliterator is provided by PHP's intl extension; if the previous implementation was pure PHP string handling, v1.2.0 may have introduced a hard requirement on ext-intl that is not reflected in the package's declared composer.json requirements. Environments that previously ran the package — minimal container images, older shared hosting, some CI runners — could fail at runtime with a class-not-found error rather than at install time. Secondary risk is behavioural: transliteration-based uppercasing can differ from the prior hand-rolled mapping for edge inputs, which could silently change validation outcomes for malformed or non-ASCII input. For a validator, a false positive (accepting an invalid ID) is a compliance concern; a false negative is a UX annoyance. Both need a regression check.

Key questions:

• Does composer.json now declare ext-intl as a requirement, and is that a breaking change for our build images?
• What is the test coverage for trUpper and for TCKN validation more broadly, and did the PR add tests for the transliteration path?
• Was behaviour for non-ASCII or Unicode input intentionally changed, or is this intended to be a no-op refactor?
• Is the maintainer responsive? This is a single-maintainer, low-activity package — bus factor matters more than the diff.
• Do we actually need this package, or is the TCKN algorithm (~20 lines) worth vendoring to remove the dependency entirely?

Integration Approach

Stack fit: Compatible with any Laravel 9/10/11 application on PHP 8.x with intl enabled. It is a pure validation helper, so it fits equally well in a controller-layer form request, a form request's rules(), or a domain-level TcKimlikNumber value object. Recommend wrapping it behind our own TurkishIdValidator interface so the vendor call is swappable — the algorithm is stable and public, and insulating ourselves costs almost nothing.

Migration path: No migration required for existing consumers beyond confirming ext-intl availability. For new adoption: (1) install and pin to ^1.2, (2) add ext-intl to the platform requirements / Dockerfile base image, (3) wrap the call in an application-owned adapter, (4) add a feature test asserting known-valid and known-invalid TCKNs plus a handful of Unicode edge cases.

Compatibility: Public API unchanged between v1.1.0 and v1.2.0. The compatibility question is environmental (PHP extension), not semver. Verify on our actual runtime image before rollout; do not assume the dev machine's PHP build matches production.

Sequencing: Confirm ext-intl on all target environments first — this is the only blocking gate. Then adopt v1.2.0 in a non-production environment, run the validation regression suite, and promote. Because there is no prior assessment and no existing adoption, treat this as a greenfield evaluation rather than an upgrade: pilot behind the adapter in one service, measure, then standardise.

Operational Impact

Maintenance: Effectively zero carrying cost — no config, no migrations, no scheduled work, no runtime state. The maintenance burden is entirely in dependency hygiene: watching for PHP major-version compatibility and for maintainer abandonment. Budget a periodic (quarterly) check, not ongoing effort.

Support: Low support surface, but the failure mode users will report is confusing: an ID that "should be valid" being rejected. Document the validation rules we enforce (format, checksum, and any policy-level checks such as "must not start with 0") so support can triage without engineering. Note that TCKN validity is algorithmic; there is no authoritative online check to escalate to.

Scaling: Negligible — pure CPU string/arithmetic work, microseconds per call, no I/O. No scaling concerns at any realistic volume. Only caution is calling it in a tight loop over large batches; even then, the dominant cost is the request, not the check.

Failure modes:

• Missing ext-intl → Class "Transliterator" not found at runtime. Mitigation: declare the extension in composer/platform requirements and assert in CI.
• Silent behaviour change on non-ASCII input → accepts/rejects differently than v1.1.0. Mitigation: regression tests on representative inputs before promoting.
• Upstream abandonment → no security patches, no PHP 9 support. Mitigation: adapter wrapper makes the swap or a vendored ~20-line implementation a one-file change.
• Over-trust in the library → teams may assume it validates identity against a registry. It does not; it checks format and checksum only. Document this distinction explicitly, as it has compliance implications.

Ramp-up: Under an hour for any PHP developer. The package is small enough to read end-to-end. The only non-obvious knowledge is the Turkish i/İ casing rule that motivated this release — worth a one-paragraph note in the adapter's docblock so the next maintainer does not "simplify" it back to strtoupper().