Fine Diff Bundle Laravel Package

Technical Evaluation

Architecture fit. The -bundle suffix is a strong signal that this is a Symfony bundle, not a Laravel package. That is a category mismatch, not a minor incompatibility: there is no ServiceProvider, no facade, no publishable config, no Laravel-native container bindings. The underlying capability — fine-grained (character- or word-level) diffing — is stack-agnostic and potentially useful for audit trails, version comparison UIs, editorial review workflows, and change-history rendering. The value, if any, sits in the diff algorithm, not in the bundle wiring. Assume ~90% of the shipped code is Symfony DI/configuration scaffolding we would discard.

Integration feasibility. Low as-is, moderate as a source to mine. Two concrete blockers:

• Dependency graph conflict. A package last released 2017-10-30 will almost certainly pin Symfony 2.x/3.x components and PHP 5.6/7.0 constraints. Modern Laravel (10/11) requires Symfony 6/7 components and PHP 8.1+. Composer will refuse to resolve, or will resolve only by downgrading the framework — which is a non-starter.
• No adoption signal. 0 stars, 0 dependents, score 0.03. There is no evidence of production use, no issue history to mine for known failure modes, and no third party who has validated the algorithm's correctness. For a diff engine, correctness on edge cases (Unicode, CRLF, large files, binary-ish input) is the entire product.

Technical risk: High. Abandoned for ~7 years means no security patching, no PHP 8 deprecation fixes, and no maintenance path. Untested third-party code running on user-supplied text is also an input-validation surface. Treat this as untrusted source material, not a dependency.

Key questions before any investment:

1. Is the diff algorithm cleanly separable from the Symfony bundle classes, or is it entangled with container/event wiring?
2. What is the license, and does it permit vendoring or forking?
3. Does it outperform or underperform sebastian/diff (already a Laravel transitive dependency via PHPUnit) or jfcherng/php-diff on our actual content shapes?
4. What was the original intent — is this a wrapper over an existing library, or a novel implementation?
5. Is fine-grained diffing a real product requirement, or a "nice to have" that a line-level diff already satisfies?

Integration Approach

Stack fit. Do not attempt composer require. Three viable paths, in order of preference:

Migration path (if we vendor). Isolate the algorithm classes into app/Support/Diff or a first-party packages/diff path repository; define a DiffEngine interface; bind it in a service provider; add a config file for size limits and rendering options. No Laravel code should ever reference a Greywolfs\ namespace directly — the interface is the seam that lets us swap implementations later.

Compatibility work. Expect to: raise PHP constraints, replace Symfony 2/3 type hints, remove bundle DependencyInjection/Resources/config directories, and run the code under PHP 8.1+ with E_ALL to surface deprecations. Add multibyte (mb_*) handling if absent — a 2017 diff library is a common source of strlen-based corruption on UTF-8 input.

Sequencing.

1. Spike (1–2 days): read the repo, extract the algorithm, benchmark against sebastian/diff on 20–30 representative documents from our own data.
2. Decision gate: only proceed to vendoring if output quality is demonstrably better AND the license permits it.
3. Wrap: interface + provider + config + size guards.
4. Harden: property-based tests on Unicode, CRLF, empty input, and pathological repetition; fuzz for memory blowups.
5. Ship behind a flag, with the alternative implementation available for rollback.

Operational Impact

Maintenance. We become the sole maintainer of any vendored code. Bus factor goes from one (already effectively zero) to "whoever touched it last." Budget a recurring line item, or accept that the fork will rot — which is precisely how this package got here.

Support. None available. No upstream to file issues against, no CVE feed, no version bumps. Every future PHP or Laravel upgrade becomes our problem to solve. This is the dominant long-term cost and it should be stated explicitly in the business case.

Scaling. Diffing is CPU- and memory-bound, and fine-grained diffing is worse than line-level — typically O(n·m) in the worst case. Production realities to plan for:

• Hard cap input size (e.g. 256 KB per side) and reject or fall back to line-level diff above it.
• Run large diffs on a queue, never in a request cycle.
• Cache diff results keyed on both content hashes; diffs are recomputed far more often than content changes.
• Monitor p95 latency and peak memory per diff as first-class metrics.

Failure modes.

• Memory exhaustion on long, low-similarity documents — the classic fine-diff failure. Mitigate with the size cap, not with memory_limit increases.
• Composer resolution failure if anyone later tries to add it as a real dependency — document loudly that this must never be added to composer.json.
• Silent Unicode corruption producing plausible-looking but wrong diffs — worse than a crash in an audit-log context.
• Deprecation-to-error promotion on a future PHP upgrade if the vendored code is never revisited.
• Correctness drift with no upstream to validate against; there is no oracle telling us when output is wrong.

Ramp-up. The code volume is likely small (a few thousand lines at most), so reading it is cheap. The expensive part is archaeology: reverse-engineering intent from 2017 code with no tests, no docs, and no maintainer. Estimate 3–5 days before anyone can confidently answer "is this correct?" — which is why the spike should be timeboxed and treated as a genuine go/no-go, not a formality.

Recommendation. Do not integrate as a dependency. Run a short, timeboxed spike against sebastian/diff; absent a clear, measurable quality win on our own content, close the evaluation and use the maintained alternative. The metadata here — 0 stars, 0 dependents, 7 years stale, 0.03 score — is not a signal to investigate harder; it is the answer.