Php Gedcom Laravel Package

Product Decisions This Supports

• Build vs. buy for genealogy import/export: v4.2.0 strengthens the case for buying. Rather than writing GEDCOM parsing and a GEDCOM-X transform layer in-house, the package now covers both: legacy GEDCOM (5.5/5.5.1-lineage) parsing/serialization plus an emerging GEDCOM-X (FamilySearch JSON) mapping path. That is the expensive, error-prone part of any family-history feature.
• Roadmap: FamilySearch / GEDCOM-X interoperability: The [WIP] GEDCOM-X mapping PR is the single most strategically relevant line item. If your roadmap includes FamilySearch API sync, Ancestry-style interchange, or any JSON-native archival format, this release moves the package from "GEDCOM file reader" to "interchange layer." Treat it as an early signal, not a shipping commitment.
• Identity and round-trip integrity: UID/_UID support across all record types with GedcomX export is a deceptively important feature. Stable per-record identifiers are what let you import → edit → export without duplicating individuals or orphaning relationships. This directly reduces support tickets and data-corruption incidents in any edit-capable product.
• Use cases unlocked or de-risked: family-tree import from competitor exports, archival ingestion pipelines, bulk migration of customer-supplied GEDCOM files, and producing JSON output for downstream search/graph services.
• Vendor-concentration risk as a decision input: The package is maintained under the liberu-genealogy org (a genealogy application suite) and this release was authored largely by an automated contributor. That is acceptable for a utility library, but it makes the package a dependency decision, not a platform decision — plan an abstraction boundary around it.

When to Consider This Package

Adopt when:

• You need to ingest user-supplied GEDCOM files and you'd rather not own the grammar, edge cases, and dialect quirks.
• You need GEDCOM-X / JSON output, or you're evaluating FamilySearch-adjacent integrations and want a head start on the mapping.
• Record identity matters in your workflow — you edit and re-export trees rather than doing one-way imports. The new UID/_UID coverage is a direct fit.
• You are in the PHP/Laravel ecosystem (the package targets that stack; it's a natural Composer dependency in an Eloquent-backed app).
• You want a narrow, replaceable dependency — parse/serialize in a service class, map to your own domain model, and keep the library at the edge of your architecture.

Look elsewhere — or gate adoption behind a spike — when:

• You require a stable, documented GEDCOM-X contract. The mapping is explicitly WIP as of v4.2.0; expect breaking changes to shape and naming before it settles. Do not build customer-facing features directly on it without pinning versions.
• You need formal compliance certification or support for the full GEDCOM 7 specification; verify dialect coverage against your real corpora before committing.
• You need SLA-backed vendor support, security review artifacts, or a maintained-by-vendors guarantee. This is a community package with an automated-contribution workflow — budget for reading the source and pinning to exact versions.
• Your stack is not PHP, in which case prefer a native library over a sidecar service unless you already run PHP for other reasons.
• Your volumes are very large and you need streaming-oriented parsing with hard memory ceilings; benchmark before assuming.

How to Pitch It (Stakeholders)

To executives: We can ship genealogy import and modern JSON export on top of an existing open-source library instead of funding a bespoke parser. The v4.2.0 release adds two things that matter commercially — a path to GEDCOM-X (the interchange format FamilySearch and similar platforms speak) and stable record identifiers, which is what prevents duplicate people and broken relationships when customers edit and re-export their trees. Recommendation: adopt as a scoped dependency behind our own interface, fund a short spike on the WIP GEDCOM-X mapper, and avoid committing publicly to GEDCOM-X output until it stabilizes.

To engineering: Pin to v4.2.0 exactly; the GEDCOM-X mapping is flagged WIP and its API surface should be assumed unstable. Wrap the library in a thin adapter and map into our own domain objects so we can swap parsers without touching product code. Prioritize the UID/_UID round-trip path — it's the highest-value, lowest-risk part of this release — and add fixture-based tests covering real-world GEDCOM dialects, including _UID variants. Note the release was largely automated, so review the diff rather than relying on release-note confidence, and confirm our minimum PHP version against the package's composer.json before upgrading from v4.1.1.