- How do I install dipeshsukhia/laravel-country-state-city-data in a Laravel application?
- Install it with Composer using composer require dipeshsukhia/laravel-country-state-city-data, then publish the package config and migrations and run the bundled seeder. Before installing, check the package's illuminate/support and illuminate/database constraints in composer.json against your Laravel version. A short spike that runs the migrations and seeds a real dataset on a staging database will surface most integration issues early.
- Which Laravel and PHP versions does this country, state, city package support?
- The package targets modern Laravel applications in the Laravel 8 through 12 era, but verify the actual illuminate/* and php constraints declared in its composer.json instead of assuming. Also check which versions the maintainer's CI actually tests, since declared constraints and tested versions are not always the same. If you run an older or newer Laravel release, install and seed in a throwaway branch first.
- How do I seed the country, state, and city tables after installing the package?
- Publish the package migrations and config, run your migrations, and then execute the package seeder. A full city dataset is on the order of 150,000 rows, so plan for batched inserts and watch memory limits and execution time. Seeding on every deploy is risky; prefer a one-off command or a controlled release step, and measure wall time and peak memory during a spike.
- Is the seeder safe to re-run, or will it create duplicate countries, states, and cities?
- That depends on whether the seeder truncates and reloads the tables or uses upserts, so read the seeder source before running it more than once. Test a second run on a staging database and compare row counts and unique constraints. If it is not idempotent, run it once as a controlled data load and keep it out of routine deploy hooks.
- Does the MIT license on this package cover the country, state, and city data itself?
- Not necessarily. An MIT license on the PHP code does not automatically extend to the underlying dataset, which is likely derived from an upstream project such as dr5hn or GeoNames with its own attribution or share-alike terms. Confirm the upstream data source, its license, and any attribution requirement before shipping the data in a product. This provenance question is the most likely adoption blocker and should be resolved before you build on the package.
- Does this package include latitude, longitude, timezones, currencies, or postal codes?
- The package is reference data for country, state, and city names and their relationships, not a geospatial solution. It is a poor fit for boundary polygons, lat/lng proximity search, postal codes, or administrative levels beyond city. Check the bundled dataset and schema for ISO 3166 codes, lat/lng, timezones, currencies, and translations before assuming they exist.
- How do I create cascading country, state, and city dropdowns with this package?
- Query the package models for countries, then filter states by country_id and cities by state_id, ideally behind a small internal repository interface. For the city level, load options by AJAX rather than embedding 150,000 rows in a Blade view. Cache the country and state lists, which are small and change rarely, and keep the city query indexed and paginated or search-filtered.
- Should my application code depend directly on this package's Eloquent models?
- Prefer not to. Publish the package migrations once, own the resulting tables under your own migration history, and wrap access in a small GeoRepository interface with the package models as one implementation. That seam lets you swap in another dataset, a hosted API, or a self-curated import without touching controllers, form requests, or Blade views. Treat the package as the source of the data, not a runtime dependency your domain code imports everywhere.
- What are the alternatives to this package for country, state, and city data in Laravel?
- Alternatives include nnjeim/world, importing a dataset such as dr5hn or GeoNames yourself, or calling a hosted geography API. This package is commodity plumbing: useful, but with roughly 81 stars and a single maintainer it has limited community scrutiny and no guaranteed future. Choose it for bounded dropdown and validation use cases, and keep the repository wrapper so replacing it later is cheap.
- How reliable and well maintained is this package for production use?
- It is a small, single-maintainer package with modest community traction, so expect limited external review of data defects and no guarantee of ongoing updates. Geographic data is also politically and legally sensitive: city renames, disputed territories, and transliteration differences can surface in user-facing forms. Pin the version, own the schema, review the data license, and plan for a data refresh path that does not require a code upgrade.