Laravel Gedcom Laravel Package

Product Decisions This Supports

• Import/onboarding feature: Lets users bring an existing family tree from Ancestry, MyHeritage, FamilySearch, Gramps, or any GEDCOM-compatible tool instead of re-entering data by hand — the single biggest activation blocker in genealogy products.
• Data portability / export feature: GEDCOM 5.5.1 export gives users a "take your data with you" guarantee, which is both an ethical stance and a competitive wedge against walled-garden incumbents.
• Build vs. buy (well, build vs. adopt): GEDCOM parsing looks trivial ("it's just a text file with tags") and is not — encoding declarations, CONC/CONT line folding, custom _-prefixed tags, non-standard date formats, and vendor-specific dialect drift will eat 2–6 engineer-weeks. Adopting this package converts that into days, leaving budget for your actual differentiator.
• Roadmap sequencing: Supports a "interoperability first" thesis — ship import/export before advanced features (DNA matching, source citation UI, chart rendering). It also gates decisions about whether to store trees natively vs. as GEDCOM-derived structures.
• Use cases to scope: migration tooling for users switching from competitors; bulk backfill for a B2B partner feed; GDPR/consumer-data-rights export requests; archival/backup of customer trees.
• Ecosystem fit: If the product is Laravel/PHP, this is a natural fit for a service-layer import job (queue a parse, map to Eloquent models, validate, present a reconciliation/diff UI before commit — never auto-commit an import).

When to Consider This Package

Adopt when all of these hold:

• The product is Laravel/PHP and already uses Eloquent; the package's value is that it speaks the framework's idioms rather than being a generic PHP library you must glue in.
• GEDCOM 5.5.1 is sufficient. That is the de facto lingua franca for consumer exports (Ancestry, MyHeritage, FamilySearch all still emit 5.5.1-flavored output), so this is usually fine — but it is a real ceiling.
• You need both directions (import and export). The dual capability is the main reason to prefer this over a parse-only library.
• Volume is user-initiated, single-file, human-sized (thousands to low hundreds of thousands of individuals). This is a request/job, not a streaming data pipeline.
• You can absorb maintenance risk: 22 stars, a last release in January 2023, and effectively one maintainer. Treat it as a vendored dependency or fork candidate, not as infrastructure you assume will be patched.

Look elsewhere when:

• You are not on Laravel, or you want GEDCOM handling isolated behind a language-agnostic boundary.
• You need GEDCOM 7.0 (released 2021, gaining slow traction) or GEDZIP packaging, or rigorous spec-conformance validation rather than pragmatic parsing.
• You need to ingest very large files (millions of records) with streaming and bounded memory — verify this before committing; a parse-everything-into-objects design will not survive it.
• You need commercial support, an SLA, or security patching guarantees. There is none here.
• The need is one-off/internal (a data migration script, an analysis job). Use an existing CLI converter and skip the dependency entirely.
• The licensing or provenance of the data you're importing carries legal exposure you haven't cleared (see below).

One legal/product note worth flagging early: GEDCOM files are user data and generally fine to import on a user's instruction, but the GEDCOM specification itself is distributed by FamilySearch under terms that have historically been read as restricting independent implementations. Low practical risk for a consumer app, but it belongs in the same conversation as your terms of service and data-processing agreement — not discovered later.

How to Pitch It (Stakeholders)

To executives (one paragraph): GEDCOM is the PDF of family history — the universal file format every genealogy product on earth reads and writes. Supporting it is table stakes for credibility and our best lever against incumbents: it means a customer can leave Ancestry, MyHeritage, or FamilySearch with their tree intact and land in our product in minutes, and it means we can promise them they can leave us just as easily. We can get both directions — import and export — for days of engineering effort rather than the multi-week build a hand-rolled parser would require, using a small MIT-licensed open-source component that fits our existing Laravel stack. The trade-off is maintenance risk on a low-activity project, which we mitigate by forking it internally and owning it. Recommend we adopt it as the substrate for an "Import your tree" onboarding flow and a standing "Export my data" feature, and treat import reconciliation (showing users what we found before we commit it) as our own product investment.

To engineering (summary): MIT-licensed, Laravel-native, parses GEDCOM into the framework and writes GEDCOM 5.5.1 back out. Saves us the parser and the dialect whack-a-mole: CONC/CONT folding, encoding handling, custom _-prefixed vendor tags, non-standard date strings. Constraints you should plan around: GEDCOM 5.5.1 only, no 7.0; last release January 2023; tiny community (~22 stars) — assume we own this code from day one. Plan to vendor or fork it, wrap it behind our own GenealogyImporter interface so we can swap implementations, run every import in a queued job, and stream/validate before loading large files. Budget a spike to confirm memory behavior on a 100k-individual file before we build the import UI on top of it.