Vcard Bundle Laravel Package

Product Decisions This Supports

• Feature scoping: "Export contact / Add to Contacts" — The underlying capability (emitting a downloadable .vcf) shows up in CRM lead capture, event/networking badges, B2B sales handoff, email-signature generators, and GDPR/PDPA data-portability flows. This package is a data point in the build vs. buy argument for that feature, not a candidate implementation.
• Build vs. buy — resolved toward build. vCard 2.1 is a small, well-specified text format. Generating a valid .vcf is a few hundred lines of string templating and encoding logic. Buying (or adopting) a dependency here trades a ~1–3 day build for an unmaintained artifact with a single star, zero dependents, and no release since November 2019. The dependency is strictly more expensive than the feature.
• Roadmap signal: format generation is a commodity. Because vCard output is cheap to produce in-house, it should never be a roadmap line item on its own. Bundle it into whatever feature actually needs it ("download this contact," "sync to phone") and treat the encoder as an implementation detail, not a product surface.
• Framework fit is a non-decision. The brief frames this as a Laravel/PHP package; it is a Symfony bundle. It will not drop into a Laravel application without adaptation. If the team is on Laravel, the integration cost is the entire feature and then some.
• Use cases it nominally serves, and their real requirements:
  • Lead capture / "scan my badge" — needs vCard 3.0 or 4.0, UTF-8 names, multiple phone/email types, optional photo. 2.1 output will mangle non-ASCII names on some clients.
  • CRM interop — downstream systems increasingly expect RFC 6350 (vCard 4.0); 2.1 is a compatibility fallback, not a default.
  • Data portability / compliance export — must be maintained and auditable. An archived repo with no security response process fails procurement review on principle.
• Not supported by this package at all: vCard 3.0/4.0, QR-code rendering, batch/zip export, i18n of field labels, PHP 8.x compatibility guarantees, Symfony 5/6/7 support.

When to Consider This Package

Adopt only if every one of these is true:

• You are on an older Symfony application (roughly Symfony 2.x/3.x era) and already have this bundle wired in.
• You specifically need vCard 2.1, not 3.0 or 4.0 — e.g., a legacy downstream system that only parses 2.1.
• You are prepared to vendor/fork it into your own repository and own the code, because upstream will not accept or ship fixes.
• The output is low-stakes and internal — no customer-facing contract, no compliance scope.
• You have accepted that any bug is yours and budgeted accordingly.

Look elsewhere — which is almost certainly the right call — if any of these apply:

• You're on Laravel. Wrong framework; there is no integration path worth taking for a feature this small.
• You need PHP 8.0+ or Symfony 5/6/7. Last release predates all of these. No declared compatibility, no CI, no maintenance.
• You need vCard 3.0 or 4.0, UTF-8-correct names, photos, or QR output.
• Your organization has any dependency hygiene policy. Archived repository, 1 star, 0 dependents, 0 downstream consumers = no community to catch regressions and no one to escalate a CVE to.
• You want a "buy" answer. This is not a viable buy. The realistic alternatives are (a) write the encoder in-house — recommended, and (b) evaluate a maintained vCard library on Packagist if you need 3.0/4.0 breadth, applying the same hygiene checklist: recent release, PHP 8 support, tests, an actual maintainer.

Decision for this assessment: do not adopt. The score and adoption signals are near-zero, and the capability is cheaper to build than to inherit.

How to Pitch It (Stakeholders)

For executives — one paragraph: We evaluated a third-party PHP component for exporting contacts as vCard files, a small feature that supports lead capture, CRM handoff, and customer data-portability requests. The component is a poor fit: it was last released in 2019, is formally archived by its author, has effectively zero adoption (one star, zero dependent projects), targets an older framework than ours, and emits only the legacy vCard 2.1 format. Adopting it would add an unmaintained dependency to our supply chain in exchange for saving roughly one to three engineer-days. Recommendation: do not adopt; build the export in-house as part of the feature that needs it. The capability is small, the format is well-documented, and owning ~200 lines of our own code is lower risk than inheriting someone else's abandoned code. Cost: within existing sprint capacity. No new vendor, no procurement, no security-review exception.

For engineering — the short version:

• It's a Symfony bundle, not Laravel. Doesn't apply to our stack.
• Archived, no release since 2019-11-21, 1 star, 0 dependents. No security response path.
• vCard 2.1 only; legacy encoding rules around UTF-8 mean non-ASCII contact names are a known pain point.
• The feature is string templating plus encoding. Write a VCardBuilder with tests against RFC 6350 output, decide on 3.0 vs 4.0 based on target clients, and move on.
• If we later need breadth (photos, QR, multi-format), re-run this evaluation against maintained libraries with a current release and PHP 8 support — don't back into it.