Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Laravel Addressing

Laravel Addressing Laravel Package

galahad/laravel-addressing

Laravel package for managing postal addresses: bundled country, state and city data plus address models and migrations you can attach to users or orders. Seed geographic records and store structured addresses without building the schema yourself.

View on GitHub
Deep Wiki
Context7

Galahad Laravel Addressing gives Laravel applications a complete, ready-to-use address management layer. It provides Eloquent models, migrations, and relationships for countries, states, and cities, plus an address model you can attach to users, orders, or any other entity—eliminating the need to design and maintain location schemas yourself.

  • Prebuilt migrations and models for countries, states, cities, and addresses
  • Polymorphic relationships for attaching addresses to any Eloquent model
  • Normalized location data with sensible geographic hierarchy
  • Query scopes and helpers for filtering and retrieving locations
  • Configurable table names and model customization
Frequently asked questions about Laravel Addressing
What is galahad/laravel-addressing used for?
It is a Laravel package that provides addressing functionality: Eloquent models and helpers for storing, managing, and retrieving address data such as countries, states, and postal information. The intended value is a reusable address model plus the polymorphic glue to attach addresses to arbitrary entities like customers, contacts, or facilities. It is a Laravel-first package, so it assumes an Eloquent-centric codebase backed by a relational database.
How do I install galahad/laravel-addressing?
Installation is the standard Laravel flow: composer require galahad/laravel-addressing, then publish and run the package migrations and any publishable config, and finally add the package trait or relation to your host model. The mechanical setup is low effort; the real work is deciding whether the package becomes your system of record or a projection of existing address data. Verify the composer.json version constraints against your Laravel and PHP versions first, since a mismatch ends the evaluation cheaply.
Does galahad/laravel-addressing support polymorphic addresses on models?
The package is positioned around attaching addresses to arbitrary entities, which suggests a polymorphic relation, but the one-line README does not document the schema. Confirm during a spike whether the address model uses a morphTo-style relation or a fixed foreign key, since that decision determines how easily you can attach one address to many entity types. If you need polymorphic behavior and the package only supports a fixed key, wrapping it in your own repository is the safer route.
Which Laravel and PHP versions does galahad/laravel-addressing support?
The supported Laravel, PHP, and database matrix is not stated in the README excerpt, so check the package's composer.json constraints before adopting it. Also confirm database driver support for anything the schema relies on, such as JSON columns, spatial types, or UUID/ULID keys. Because there is no published release cadence or issue history, treat version support as something you must verify rather than assume.
Does galahad/laravel-addressing validate or normalize address input?
It is unclear from the available documentation whether the package validates or normalizes input, or whether it is purely a storage layer. Test this early if validation matters to you, because a pure storage package leaves normalization, ISO country code handling, and incomplete-address rules entirely to your application code. If validation is needed, plan to add your own FormRequest or value-object layer rather than depending on the package for it.
Where does the country and state reference data come from and how do I update it?
The provenance and refresh path for country and subdivision reference data is not documented, and this is a recurring maintenance liability for any addressing package. Country and administrative-area data goes stale as subdivisions are renamed or created, so you need a known update mechanism if the package ships static data. If no refresh path exists, consider seeding reference data yourself and letting the package handle only the address records.
How do I migrate existing address columns or tables to this package's schema?
Avoid rewriting in place. Keep your current columns and tables, wrap the package behind an internal repository or service boundary, then dual-write and dual-read before cutting over one bounded context at a time. Address data is typically low-write and high-read, which makes dual-write cheap and backfill verification straightforward. Also check that published package migrations will not collide with an existing addresses table.
Is galahad/laravel-addressing safe to use in production?
Treat it with caution: the package has zero stars, zero dependents, and a one-line README, which means there is effectively no external validation signal. There is no evidence of production usage, no visible issue surface, and therefore no community pressure toward semantic versioning discipline. It may still be fine as an extracted utility from a larger shipped product, but that is a question for the maintainer, not something the repository proves.
Does galahad/laravel-addressing handle international addresses without a state or postal code?
This is one of the most important things to verify, because international addresses frequently lack a subdivision or postal code. A schema that assumes US-style completeness will reject or corrupt perfectly valid data. Confirm how the package treats nullable and optional fields, and whether country codes are stored as ISO 3166-1 alpha-2 or alpha-3, since mixing the two silently breaks lookups.
What are the alternatives to galahad/laravel-addressing?
Alternatives include a hand-rolled address model with your own migrations, a vendor address-validation provider's schema if you already standardize on one, or a better-maintained community addressing package with visible dependents. The deciding factor is usually whether you need a storage model, normalization and validation, or geocoding, since few packages do all three well. Even if you adopt this package, put it behind an internal interface so replacing it later stays a contained change.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource