- Does siganushka/region-bundle work with Laravel?
- It installs as a normal Composer package, but it is a Symfony bundle built around Doctrine ORM, Symfony Form types and Symfony's DI container, so none of its integrations auto-register in Laravel. The package ships no ServiceProvider, publishable config or migrations, and it only self-registers under Symfony Flex. In a Laravel app you would effectively be consuming the entities and the dataset only, wiring everything else yourself.
- How do I install siganushka/region-bundle in a Laravel project?
- Running composer require siganushka/region-bundle also pulls in doctrine/doctrine-bundle and a Symfony component graph that is inert under Laravel. Pin an explicit version rather than floating on ^1.2, then diff the lockfile with composer why doctrine/doctrine-bundle before merging. Expect to write your own service provider or config layer to expose the repositories to your app.
- What region data does siganushka/region-bundle actually ship?
- It ships a preloaded Chinese administrative hierarchy of provinces, cities, districts and counties with stable administrative codes. The data is exposed as Doctrine entities and repositories so you can query and validate addresses instead of scraping or hand-maintaining lists. Cascading form types and controller endpoints sit on top for interactive address selection.
- Why does it require doctrine/doctrine-bundle and is it needed at runtime?
- The dependency appeared in a patch release (1.2.1 to 1.2.2) with no stated rationale, which is not patch-compatible under semver. doctrine/doctrine-bundle is Symfony's Doctrine ORM integration layer, so if you only want the region dataset it is very likely unused and should have been require-dev or suggest. Ask the maintainer for the changelog entry justifying the change before you adopt it.
- Can I use siganushka/region-bundle with Eloquent instead of Doctrine?
- No. The package models regions as Doctrine entities with Doctrine repositories, and there is no documented Eloquent model or Laravel-native code path. Using it in an Eloquent-first app means either running a second ORM through a Doctrine bridge or importing the dataset into your own tables. For most Laravel projects an Eloquent-native region table is simpler and cheaper to maintain.
- Which Laravel and PHP versions are supported, and what is in the CI matrix?
- The package does not advertise a Laravel support matrix; its constraints are Symfony and Doctrine oriented, and modern Laravel apps carry doctrine/dbal only transitively or not at all on Laravel 11+. Verify on your own targets with a small matrix, for example Laravel 10, 11 and 12 across PHP 8.2 and 8.3, run with both --prefer-lowest and --prefer-stable. Constraint breakage surfaces there, not in staging, so ask the maintainer what their CI actually covers.
- Do the cascading province, city and district form types work in Blade or Livewire?
- The form types are Symfony Form types, so they render Symfony forms rather than Blade components or Livewire properties. You can still call the region repositories from a controller or Livewire component and build the cascade yourself from the shipped dataset. Treat the form types as reference logic rather than a drop-in Laravel UI.
- Is it safe to run composer update with a ^1.2 constraint on this package?
- It is risky. A routine update on ^1.2 can silently acquire the whole Symfony DependencyInjection, HttpKernel and Config graph plus doctrine/doctrine-bundle, because the hard dependency was added in a patch bump. Require an audited lockfile diff and keep the change isolated in one commit so a revert stays trivial. If the dependency turns out unused, a replace entry or a vendored fork is the cheapest mitigation.
- What are the alternatives to siganushka/region-bundle for Chinese region data in Laravel?
- Look for Laravel packages or seeders that ship the same administrative division dataset as migrations and Eloquent models, or import an official dataset into your own tables. Either approach avoids a second ORM, a second container paradigm and coupling to Symfony's release train. If you specifically need ready-made Doctrine entities, the bundle becomes much more defensible.
- How do I keep the region dataset up to date in production?
- The bundle includes a console command that refreshes data from official sources, but it is a Symfony command rather than an Artisan command, so Laravel's scheduler cannot call it without a shim. You can alternatively export the data and load it through your own idempotent job. Administrative codes change rarely but do change, so a periodic refresh check is usually sufficient.