Afip Bundle Laravel Package

Getting Started

The v1.2 release renames the vendor namespace from Gonz\... (Gonzakpo) to Gonzaloalonsod and adds Symfony 5 support. Treat this as a migration, not a drop-in upgrade.

1. Swap the Composer requirement. Replace the old package name in composer.json with the new vendor-prefixed one, then composer remove the old one first — Composer will happily install both side by side and you'll get duplicate class definitions rather than a clean error.

   composer remove gonzakpo/<package>
   composer require gonzaloalonsod/<package>:^1.2
   

2. Re-discover the provider. If you're not using package discovery, update the providers and aliases arrays in config/app.php and then run php artisan config:clear. A stale cached config is the single most common cause of "class not found" after a vendor rename.
3. Grep before you boot. Run grep -rn "Gonzakpo" app/ config/ routes/ database/ tests/ — every use statement, facade alias, config key, and publish tag needs updating.
4. First use case: re-publish the config (php artisan vendor:publish --provider="Gonzaloalonsod\...\ServiceProvider") and diff it against your existing config/ copy. Config keys frequently change alongside namespaces, and a silently-ignored key is worse than a fatal error.

Start by reading the package's composer.json for its illuminate/* constraints, then the service provider for what it actually binds into the container. Those two files tell you 80% of what you need.

Implementation Patterns

Wrap the package behind your own binding. Because the vendor just changed once, it can change again. Bind the package's client/manager into the container under your own interface and inject that:

// app/Providers/AppServiceProvider.php
$this->app->bind(ReportGenerator::class, fn ($app) => new PackageReportAdapter(
    $app->make(\Gonzaloalonsod\Reports\Client::class)
));

Consumers then type-hint your interface, and a future rename is a one-file change.

Pin the major version and upgrade deliberately. "gonzaloalonsod/<package>": "^1.2" — do not use * or dev-master. Given that a vendor rename happened inside a minor release, your lockfile is your only real safety net.

Test the Symfony bridge explicitly if you rely on it. Symfony 5 support means the package now pulls Symfony components into a Laravel app, where Illuminate already provides overlapping functionality (http client, event dispatcher, console). Check composer why symfony/* after installing and confirm you're not running two HTTP clients or two event dispatchers with different service IDs. Where overlap exists, prefer the Laravel implementation and configure the package to accept an injected instance rather than letting it instantiate its own.

Keep a migration commit separate. Do the rename in one atomic commit (composer.json, lockfile, use statements, config, tests) so that git bisect on a later regression lands on either "before rename" or "after rename" cleanly.

In a multi-package app, if other internal packages depend on the old namespace, update them in dependency order and tag them, otherwise you'll build a partial upgrade that only fails at runtime.

Gotchas and Tips

• The rename is the breaking change, not the Symfony bump. It's shipped as v1.2 (a minor), which means ^1.0 will pull it in silently on your next composer update. Pin to the exact known-good version until you've migrated, or you'll get Class "Gonzakpo\..." not found in production on an unrelated deploy.
• Composer cache lies. After swapping vendors, if you still get the old class, run composer dump-autoload -o and clear ~/.composer/cache (or composer clearcache). Also check for a leftover vendor/gonzakpo/ directory — a failed remove leaves it behind and the old autoloader map can still resolve it.
• Publish tags change with the namespace. vendor:publish --tag=config style tags are often derived from the provider name. Use --provider= explicitly, or list available tags with php artisan vendor:publish (no args) and read the menu.
• Config key renames fail silently. config('gonzakpo.api_key') vs config('gonzaloalonsod.api_key') — the former returns null and your code proceeds with an empty credential instead of throwing. Add a boot-time assertion or a failing test around required config.
• Symfony 5 raises the PHP floor. Symfony 5 requires PHP >= 7.2.5 and, in practice, 7.4+ for the full component set. If you're still on Laravel 6/7 with PHP 7.2, the dependency solver may downgrade or hard-fail. Read the composer update output rather than assuming success because it exited 0.
• Extension points to check before forking: the service provider usually exposes $this->app->bind()/singleton() calls you can override, and many packages ship a Manager with a extend() method. If the Symfony bridge misbehaves in a Laravel context, look for extend()/driver registration before patching vendor code — and never patch vendor code, since the next rename will wipe it.
• Debugging lever: php artisan tinker + app()->make(\Gonzaloalonsod\...\Client::class) tells you fast whether the problem is container binding or your application code. If that resolves but your code fails, the issue is a stale use statement, not the package.
• Given how thin the release notes are, diff the tag directly rather than trusting the changelog: git diff v1.1..v1.2 --stat on the package repo, or unpack both versions into temp dirs and diff -r. Check for signature changes in public methods — a rename plus a changed constructor argument list is a very different upgrade than a rename alone.