- What is nonsapiens/realaddressfactory used for?
- It is a Laravel package that supplies real-world, geographically accurate addresses for model factories and database seeders. Instead of random strings, you get believable street names, cities, and postal codes that look like data your production address providers would actually accept. It is aimed at demos, fixtures, and local development rather than runtime application logic.
- How do I install nonsapiens/realaddressfactory with Composer?
- Install it as a dev dependency with composer require --dev nonsapiens/realaddressfactory. Laravel 11 and later uses package auto-discovery, so there is no manual service provider registration in most cases, and configuration publishing is optional. After that you can call it from your existing factory definitions or a seeder, much like any other Faker provider.
- Which Laravel and PHP versions does this package support?
- The package requires Laravel 11 or newer and PHP 8.2 or higher. Teams still on Laravel 10 or earlier are excluded outright, so confirm your fleet's minimum supported framework version before trialing it. It is also worth testing explicitly against both Laravel 11 and 12, and against PHP 8.2, 8.3, and 8.4.
- Should I install it in require or require-dev?
- Use require-dev. This is a test-data generator, not a runtime dependency, so its correct architectural slot is alongside seeders, factories, and test fixtures. Keeping it out of production dependencies limits the blast radius if the package is later abandoned or fails a security review, and it keeps your deployment artifact smaller.
- Does it work alongside Faker and my existing factories?
- Yes. It is designed to sit next to your existing fake() calls rather than replace them, which keeps the change surface narrow. The recommended approach is to swap only the address-provider call sites and leave names, emails, and timestamps on stock Faker. Verify that it coexists with the fakerphp/faker version your other fixtures pin, and check any Faker locale configuration you already use.
- Is the address data real, and does it contain personal information?
- Real-world addresses implies data derived from actual postal records, which in some jurisdictions may include occupiable residential addresses. Before adopting it, confirm the upstream source, its license, whether the dataset is bundled or fetched at runtime, and whether unit or apartment-level detail is included. Never commit generated fixtures containing real addresses to a repository or paste them into bug tickets, because that creates a privacy exposure code review will not catch.
- Is the generated output deterministic when I seed Faker?
- That depends on how the dataset is delivered. If the package bundles a static dataset, output is deterministic and seeded suites stay stable; if it fetches or refreshes data at runtime, tests become environment- and time-dependent. Confirm with the maintainer whether output honors a Faker seed for reproducibility before relying on it in assertion-heavy suites.
- Which countries and regions are covered?
- Coverage is not specified in the package overview, so treat it as an open question for the maintainer. Ask which countries are included and how stale the underlying data is, since address formats, postal code schemes, and locale conventions vary significantly. If your test matrix spans multiple locales, validate representative samples before committing to the package.
- Can I use this package in production or in committed fixtures?
- It is not intended for production runtime use; confine it to seeders, factories, and test fixtures. Committed fixtures are riskier, because real addresses can be occupiable residential locations and constitute a privacy concern once they land in version control. If you need synthetic but non-identifying data, this package is the wrong tool.
- How do I migrate away from it if the package is abandoned?
- Wrap it behind a thin internal interface, such as an AddressFixtureProvider with a Faker-backed implementation and a package-backed one selected by config or environment. That costs roughly a day and buys a one-line reversal if the package stops receiving Laravel upgrades or fails review. Keep the default implementation unchanged during rollout so existing fixtures continue to pass.