- How do I install kossa/algerian-cities in a Laravel app?
- Require the package with composer require kossa/algerian-cities and pin it to ^4.1 for the current release line. Then publish the migrations and any config with vendor:publish, run php artisan migrate, and seed the reference data. Adoption is additive to your schema, so there is no existing install to migrate from. Inspect the resolved dependency graph in isolation before merging the branch.
- Does kossa/algerian-cities support Laravel 12 and PHP 8.4?
- Version 4.1.2 adds Laravel 12 compatibility and extends CI to PHP 8.4, so teams on Laravel 11 or 12 can adopt it without a version fork. Note that Laravel 12 support is currently evidenced by CI dependency resolution rather than documented functional tests against a real database. Check the composer.json constraints and run a quick migrate and seed against your exact PHP and Laravel combination. If you are on Laravel 10 or earlier, confirm the constraint floor before planning.
- How do I seed the wilayas and communes data?
- After publishing the migrations, run the package seeder, either the bundled one or a call from your DatabaseSeeder, in a non-production environment first. Reference-data seeders for communes can be large, so benchmark row counts and duration against your expectations. Design a deliberate re-seed strategy for deploys, such as an idempotent upsert or a one-off data step, instead of running it on every release.
- What Eloquent models and relationships does the package provide?
- The package ships Eloquent models for wilayas and communes with a relationship linking each commune to its parent wilaya. That lets you query communes directly or eager-load wilaya data for addresses, delivery zones, and onboarding forms. Review the published schema and model namespaces before depending on them, and check whether lookup scopes or helpers are documented. Pin the version and treat the public API as something to re-verify across minor releases.
- How do I look up a commune by name or zip code?
- Communes store Arabic and French names plus a zip code and latitude/longitude, so you can query by name, zip code, or approximate geography. For user-facing search, query both name columns, or add normalized and indexed variants if your volume is high. After reviewing the published migrations, confirm indexes exist on the columns you filter by. Validate results against a known sample before shipping the feature.
- Are the wilaya and commune names available in both Arabic and French?
- Yes, the dataset stores wilaya and commune names in Arabic and French, which supports bilingual forms, address display, and search. The practical implication is that you choose a default locale and a fallback, then expose both in your API resources. Test Arabic rendering and text direction in your UI to confirm column lengths and encoding hold. Verify the shipped columns during your schema review.
- Do communes include zip codes and latitude/longitude coordinates?
- Each commune record includes a zip code and latitude/longitude, so the package can back delivery addressing, map centering, and distance-based routing. Coordinates are commune-level rather than street-level, so treat them as approximate for logistics and last-mile work. Validate a sample against your own address records before relying on them for production features.
- Can I change the table names or avoid collisions with an existing cities table?
- Table names come from the published migrations, so review them and rename or wrap them in a prefixed variant if they collide with an existing cities or communes table. Publishing the config, where available, is the cleanest place to adjust naming before you migrate. Make the change in a feature branch before any production data exists in those tables. Confirm the result matches your naming conventions and index requirements.
- Are the migrations and seeders safe to re-run in production?
- Treat migrations and seeders as separate concerns: migrations create schema and are normally run once, while the seeder loads reference data. Check whether the seeder uses plain inserts, updateOrCreate, or truncation before running it against production, because that decides whether a re-run duplicates rows. For deploys, prefer an explicit one-off seeding step over an every-release hook. Test a re-run in staging with a copy of production data.
- How current is the Algerian data, and what are the maintenance risks?
- Data freshness is the biggest risk, since Algerian commune lists change by decree and the release notes do not document provenance or a refresh cadence. Verify the last-refresh date against an authoritative source before depending on it for KYC, regulatory, or logistics use. Maintenance is concentrated in a small contributor base, so plan a fallback such as forking and self-hosting the dataset if updates stall. Recent releases are patch-level with no announced breaking changes, but treat the package as a dataset plus Eloquent integration you may need to own long term.