Laravel Airports Laravel Package

Product Decisions This Supports

• Build vs. buy for reference data. Airport/IATA data is commodity reference data, not differentiation. Adopting an MIT package avoids spending a sprint or two on dataset curation, deduplication, and validation plumbing, and lets the team focus on booking flow, search UX, and pricing logic instead.
• MVP scoping. The in-memory lookup API (find, exists, inCountry, search, options) works with zero database setup. That means airport autocomplete, country-filtered dropdowns, and IATA validation can ship in a thin slice rather than waiting on a schema, migration, and seeding workstream.
• Validation quality vs. infrastructure cost. The AirportCode rule validates codes from the in-memory dataset, so you get "no invalid IATA codes in forms/imports" without requiring the published airports table. This is a product-quality win at near-zero operational cost, and it removes a common source of silent validation failures (exists:airports,iata when the table was never seeded).
• Data authority decision. The package creates two possible sources of truth: the compiled in-memory dataset and the optional Eloquent airports table. PM should explicitly decide which is authoritative:
  • In-memory = read-only reference data for validation, dropdowns, and domain logic.
  • Database table = app-owned data for joins, reporting, custom labels, disabled airports, or localized names. Choosing this up front prevents later drift and "why does the dropdown disagree with the report?" bugs.
• Roadmap sequencing. Use the in-memory API for v1 features (autocomplete, validation, country filtering, simple proximity over small candidate sets). Defer the DB table and index-backed radius queries until reporting, joins, or large-scale geospatial search actually appear on the roadmap.
• Use cases this unlocks or accelerates: flight/trip booking forms, travel expense and mileage capture, logistics and dispatch address entry, onboarding/profile airport preferences, search filters ("airports in GB"), and import pipelines that must reject unknown codes before writing.
• Risk posture decision. With 4 stars, 0 dependents, and "readme" maturity, this should be treated as a contained internal utility — not platform-critical infrastructure. PM should approve adoption with a pinning/fork contingency rather than assuming community support.
• Upgrade/replatform decision. v1.0.0 is a hard fork (namespace ijeffro\Airports → FLAIRUK\Airports, PHP 8.2+, Laravel 12/13), not a patch. For teams on Laravel 5–11, this is a migration project with call-site changes (arrays → readonly objects, getByIata → find), so it belongs in roadmap planning, not a routine dependency bump.

When to Consider This Package

Consider it when:

• You are on Laravel 12/13 and PHP 8.2+, or starting greenfield, and can use the current FLAIRUK\Airports release.
• You need IATA code validation, airport dropdowns, or autocomplete and want it working in hours, not sprints.
• Your airport usage is primarily single-code lookup and reference display, with modest filtering by country or name.
• You are comfortable treating the package as vendored utility code: pin the version, wrap it behind one internal service/interface, and keep a fork or data-refresh fallback.
• You can accept the README/install ambiguity (the top-level README still shows stale ijeffro/* and Laravel 5 instructions while v1.0.0 documents flairuk/laravel-airports and auto-discovery). Verify the actual package name and namespace in composer show before committing.

Look elsewhere or proceed with caution when:

• You need authoritative, frequently refreshed airport data, an SLA, or vendor support. The shipped dataset is a snapshot; refresh is your responsibility.
• You need more than IATA/country — ICAO codes, timezones, runway data, multilingual airport names, operational status — as first-class fields.
• You need high-volume geospatial radius search. The in-memory array is fine for small candidate sets, but index-backed SQL/PostGIS is the right tool at scale.
• You are on Laravel 5–11. The old dev-master is effectively unsupported; upgrading is a hard-fork migration, not a composer update.
• You require a healthy community/dependency signal. Four stars and zero dependents means you are an early adopter; budget for reading source and owning fixes.
• You want airport data to be editable business data (custom names, disabled airports, per-tenant curation). In that case, the optional table plus a seed-once policy is workable, but you must own the seed/overwrite semantics — re-seeding can clobber local edits.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed utility that removes a multi-week data and validation chore from the travel/booking roadmap. It lets us ship airport selection and IATA validation in the first release instead of building and maintaining our own airport dataset. The trade-off is maturity: it has very low public adoption, so we should use it narrowly, pin the version, and keep it behind an internal interface so it can be replaced or forked without product disruption. It is low-cost, low-lock-in, and not a platform bet.

For engineering: The v1.0.0 line targets Laravel 12/13 and PHP 8.2+, auto-discovers its provider, and ships an opcache-friendly PHP array backing a readonly Airport value-object API (find, findOrFail, exists, inCountry, search, options), an AirportCode validation rule, and an optional publishable migration/model/seeder with airports:install and airports:seed. It is easy to unit test with no database. Key implementation cautions: the README's top-level install block is stale (ijeffro/*, Laravel 5) versus the v1.0.0 FLAIRUK\Airports namespace; audit for array-offset access and getByIata-era idioms; normalize IATA codes with strtoupper(trim()) at the boundary; and decide explicitly whether the in-memory array or the DB table is authoritative.

Recommendation: Adopt for a narrowly scoped feature — validation, dropdowns, autocomplete — behind a single internal airport service. Pin a specific release, verify the installed package/namespace, document the data-authority decision, and keep a fork/data-refresh contingency. Do not make it a dependency of core pricing, inventory, or reporting logic until adoption and maintenance signals improve.