Accordion Laravel Package

Getting Started

This release (v1.0.1) is a patch that corrects the package's config file naming to use the sb- prefix. There is no new API surface, so the first thing to do is confirm which config filename you actually have on disk before writing any code against the package.

1. Upgrade the package and re-publish config. The config filename changed, so an existing published file will not be picked up under its new name:

   composer update <vendor>/<package>
   php artisan vendor:publish --provider="<Vendor>\\<Package>\\<PackageServiceProvider>" --tag=config --force
   

   Verify the published file is now named with the sb- prefix (e.g. config/sb-<package>.php) and that its contents match the package's config/ source.
2. Look first at the service provider's mergeConfigFrom call. That is where the filename is referenced. If the package ships a config file under one name and merges it under another, the published file silently does nothing — this is exactly the class of bug v1.0.1 fixes.
3. Clear cached config before testing: php artisan config:clear. Config is resolved at boot, so a stale bootstrap/cache/config.php will mask the fix entirely.
4. First use case: publish the config, set one non-default value (e.g. an API key or a driver/queue name), dump config('sb-<package>.<key>') in tinker, and confirm you get your value rather than the package default. If you get the default, the old filename is still being merged and you are not actually running v1.0.1's fix.

Implementation Patterns

• Treat the config file as package-owned-but-app-published. Read values only through config('sb-<package>.*') — never include or require the file directly. This keeps you insulated from future filename or key reshuffles.
• Wrap config access in your own config layer. Define config/myapp.php keys that reference the package config via env(), so your application code depends on your keys, not the package's. When a future patch renames something again, you change one file.
• Upgrade path for existing installs (the common case here): if you had published the pre-1.0.1 filename, do not just re-publish with --force — diff first.

  # copy the old published file aside, then re-publish
  cp config/<old-name>.php config/<old-name>.php.bak
  php artisan vendor:publish --tag=config --force
  diff config/<old-name>.php.bak config/sb-<package>.php
  

  Port any local customisations forward, then delete the stale file. Leaving both files present is the most common cause of "my config changes do nothing".
• CI/deploy pattern: publish config at build time as part of your release artifact, not at runtime. Config file naming changes are deploy-time events, and a container that publishes during boot will produce inconsistent state across replicas.
• Test the wiring, not the values. A small feature test that asserts config('sb-<package>.<key>') is non-null catches the entire class of bug this release fixed:

  public function test_package_config_is_merged(): void
  {
      $this->assertNotNull(config('sb-<package>.some_key'));
  }
  

• Pin the version. Since this was a filename fix in a 1.0.x patch, pin to ^1.0.1 rather than ^1.0 if you have any automation that relies on the published filename.

Gotchas and Tips

• mergeConfigFrom vs publishes must agree. The two-argument mergeConfigFrom(__DIR__.'/../config/sb-package.php', 'sb-package') and the publishes([... => config_path('sb-package.php')], 'config') array must reference the same source file and the same destination name. A mismatch is invisible until someone publishes and wonders why edits are ignored. Audit both lines after upgrading.
• Stale published configs survive upgrades. vendor:publish never overwrites without --force, and it never deletes the old file. After any config-filename change, explicitly check config/ for orphans.
• Config cache hides everything. php artisan config:cache bakes the resolved config. If you upgrade and see no change, run config:clear before concluding the patch is broken. On Laravel Octane, you also need to reload the workers.
• Env vars bypass the published file. If the package reads env('SB_...') directly in its config file, changing the published config has no effect once config is cached — the env is only read during the cache build. Change the env var and rebuild the cache.
• The sb- prefix is a namespace hint, not decoration. Laravel does not enforce unique config filenames across packages, so an unprefixed name can collide with another package or with an app-level config of the same name. The prefix reduces that risk; do not strip it when copying values into your own config.
• Debugging checklist for "config not applied": (1) correct version installed — composer show <vendor>/<package>; (2) config:clear run; (3) published filename matches the sb- prefix; (4) mergeConfigFrom path exists on disk; (5) no duplicate/old config file shadowing it; (6) provider registered in bootstrap/providers.php (Laravel 11+) or config/app.php.
• Extension point: because the config is now correctly named and merged, you can override any key from config/sb-<package>.php without touching vendor code. Prefer that over subclassing the package's service provider — provider subclassing breaks whenever the provider's internal boot order changes.
• If you maintain a fork or a wrapper package that referenced the old filename in its own mergeConfigFrom or publish tags, update it in lockstep. The patch is non-breaking for consumers but breaking for anything that hardcoded the previous path.