Alhazen Laravel Package

Getting Started

• Install the package with Composer and let Laravel package discovery register the service provider. If discovery is disabled, register the provider manually.
• Look first at the service provider boot logic and any published config file. In 0.1.1, the key paths to verify are migration loading and location loading.
• First use case: install the package, publish config only if you need to customize locations, run php artisan migrate, then use the package’s location data/models from your application.
• Do not publish migrations unless you need to modify the schema. The 0.1.1 release specifically fixes package migration loading, so the default workflow should rely on the package’s own migrations.

Implementation Patterns

• Use the package migrations as the source of truth for its default schema. If you publish them for customization, make sure the package migrations are not also loaded to avoid duplicate table creation.
• Configure locations through the package config/env rather than editing vendor files. Cache config in production after setting location values.
• In tests, use RefreshDatabase and confirm package migrations run automatically. For existing applications, run migrations after upgrading to 0.1.1.
• Upgrade workflow: update the package, clear Laravel caches, run migrations, and smoke-test that locations load correctly in the target environment.
• Keep application-specific overrides in your app layer—config overrides, repositories, or custom models—rather than modifying package internals.

Gotchas and Tips

• 0.1.1 fixes migration and location loading. After upgrading, run composer dump-autoload, php artisan config:clear, php artisan cache:clear, and php artisan migrate.
• Duplicate migration errors usually mean both the package migration and a published copy are running. Choose one migration source.
• If locations do not appear, check service provider registration, cached config, published config values, and filesystem/path permissions.
• Since this is an early 0.1.x package with sparse release notes, pin the version in production and validate upgrades in staging.
• Extension should happen through published config and app-level overrides; avoid editing vendor files so future fixes remain upgradeable.