Laravel Setting Laravel Package

Getting Started

Start by requiring the package and publishing its config and migration:

composer require <vendor>/<package>
php artisan vendor:publish --provider="<Vendor>\<Package>\<PackageServiceProvider>"
php artisan migrate

Look first at config/settings.php. Release 1.1.0 adds a configurable table name, so confirm the table matches your migration before writing data. The package’s primary entry points are the service/facade and the new helper function; use those for day-to-day reads and writes rather than querying the settings table directly.

A good first use case is application-wide preferences: store a value once, then read it from controllers, Blade views, or service providers via the facade or helper.

Implementation Patterns

• Store and forget settings through the service. The service exposes store() and forget(); in 1.1.0 store() was renamed to dispatch(). Prefer the new dispatch() name in new code and update existing calls.
• Use the helper for terse access. The new helper function is convenient in Blade templates, closures, and small controller methods. Use the facade when you need dependency injection or test mocking.
• Treat the global settings object as a read-through cache. Release 1.1.0 loads settings into a global object. Use it for frequently read values, but call the service’s forget/refresh path after writes if you need immediate consistency.
• Integrate at the service-provider level. Load settings needed by multiple parts of the app in a service provider or middleware, then resolve them from the container/global object instead of hitting the database repeatedly.
• Keep table names environment-aware. Because the table name is now config-driven, you can point staging and production at different tables without code changes. Pair this with config caching in deployed environments.
• Use the feature tests as living documentation. 1.1.0 adds feature tests for setting methods; read them to confirm expected method signatures, return values, and facade/helper behavior.

Gotchas and Tips

• Breaking rename: store() → dispatch(). Search your codebase for store( calls on the settings service and update them. The facade accessor bug fix in the same release means older facade usage may behave differently—retest any custom facade aliases.
• Config cache quirks. If you run php artisan config:cache, changes to the table name or cache-related config will not take effect until you clear and rebuild the config cache. The 1.1.0 “change value config cache” item may alter cache keys/values, so clear caches after upgrading.
• Global object staleness. Loading settings into a global object improves read performance but can serve stale values after a write. Explicitly forget or refresh the setting when correctness matters.
• Verify the published migration against the configured table name. A mismatch between config/settings.php and the migration is the most common setup failure.
• License change. Review the new license before distributing or using the package commercially.
• .gitignore removal. Published or generated files may now be tracked differently; check your repository status after upgrading.
• Debugging checklist: confirm the service provider is registered, the helper is autoloaded, the facade accessor resolves correctly, and the feature tests pass in your app’s Laravel/PHP version (the dependency version changed in 1.1.0).
• Extension point: bind your own implementation or decorate the service if you need custom cache invalidation or audit logging around dispatch() and forget().