Laravel Gedcom Laravel Package

Technical Evaluation

Architecture fit. liberu-genealogy/laravel-gedcom is a domain package inside the Liberu Genealogy ecosystem: it parses and generates GEDCOM (the de facto genealogy interchange format) and exposes that capability to a Laravel application. It follows Laravel package conventions — service provider registration, container-resolved collaborators, publishable configuration. That makes it a natural fit for any Laravel host that needs import/export interop with Ancestry, MyHeritage, Gramps, or Geni-style tooling, rather than a framework-agnostic library that must be hand-wired.

Integration feasibility. Low friction. Composer install plus provider auto-discovery; the primary work is mapping the package's record model (Individual, Family, Source, Note, etc.) onto our own domain schema. v8.6.0 changes nothing about the public surface — it is a CI fix and one internal container-resolution change — so adoption effort is identical to v8.5.0. The main unknown remains the breadth of GEDCOM 5.5.1/7.0 tag coverage and how it handles non-UTF-8 encodings (ANSEL, ANSI) common in legacy exports.

Technical risk. For this release: low. Both changes are internal/CI. The one behavioral nuance is PR #94: GedcomGenerator now resolves Source through the service container instead of a direct instantiation. That is an improvement (overridable, testable, injectable), but it means any consumer that relied on the concrete class being constructed inline — or that binds a custom Source without implementing the expected contract — should be regression-tested. No breaking changes or deprecations are declared. Broader package risk is the usual for a single-maintainer domain package: GEDCOM spec edge cases, memory behavior on large files, and a thin public API contract.

Key questions.

1. Which Source contract does the container binding resolve, and is it bound as a singleton or transient?
2. Is Laravel 13 support merely CI-verified, or are there runtime constraints (PHP version floor, deprecated framework APIs)?
3. What is the documented supported matrix for Laravel and PHP versions?
4. How are large GEDCOM files handled — full in-memory parse, or streaming/chunked?
5. What is the maintainer bus factor and release cadence beyond v8.x?

Integration Approach

Stack fit. Targets a standard Laravel application (service provider + container bindings + config). PR #93 extends the CI matrix to Laravel 13 while pinning the CI host, implying the package intends to track current Laravel releases rather than lag. Confirm the PHP floor before committing, since Laravel 13 implies a modern PHP baseline.

Migration path. From any v8.x release this is a drop-in minor bump — no config republication, no schema change, no code edits. From v7.x or earlier, treat as a major upgrade and review the v8.0.0 changelog, not this one.

Compatibility. Semver is being respected: a CI fix and an internal refactor, no public API removal. The container-resolution change is the only item that can alter runtime behavior for subclassers.

Sequencing.

1. Pin ^8.6.0, run the existing import/export test suite against representative GEDCOM fixtures (including at least one legacy-encoded file).
2. Explicitly test any custom Source binding or GedcomGenerator subclass — this is the single regression surface in this release.
3. Validate on the lowest and highest supported Laravel versions in our matrix before promoting beyond staging.
4. Defer Laravel 13 adoption until our own app skeleton upgrades; the package being ready is necessary but not sufficient.

Operational Impact

Maintenance. Active, small-team project with two first-time contributors in this release — a positive community signal but also a reminder that review bandwidth is limited. Budget for periodic dependency bumps; do not assume upstream will absorb Laravel major-version churn on our timeline.

Support. Upstream support is GitHub issues/PRs with no commercial backing. For anything business-critical (e.g. customer data import), we should own a fork or vendor-pin strategy and keep our own fixture corpus for regression detection.

Scaling. GEDCOM files from consumer genealogy services can run to hundreds of thousands of individuals. Parsing is likely memory-bound; plan to run imports as queued jobs with generous memory limits and hard timeouts, and to chunk exports. Validate throughput against a realistic large file before promising import SLAs.

Failure modes.

• Malformed or non-conformant GEDCOM input → parse exceptions; needs defensive validation and user-facing error messaging rather than 500s.
• Legacy encodings (ANSEL) → mojibake in names/places if not normalized at ingest.
• Custom Source bindings now resolved via container → a misconfigured or missing binding could fail at generation time rather than construction time; add a smoke test for export paths.
• Unbounded memory on large imports → worker OOM; mitigate with limits and backpressure.

Ramp-up. A Laravel developer is productive with the API in under a day; the real learning curve is GEDCOM domain semantics (record linkage, FAMC/FAMS relationships, source citations, custom tags). Assign one engineer as the domain owner and maintain an annotated fixture set — that person becomes the reviewer for all future package upgrades.