Afip Bundle Laravel Package

Getting Started

v1.2 renames the vendor namespace from Gonzakpo to Gonzaloalonsod and adds Symfony 5 support. That rename is the first thing to deal with — it touches composer.json, every use statement, and any string-based class references.

Fresh install

composer require gonzaloalonsod/<package>:^1.2
php artisan vendor:publish --provider="Gonzaloalonsod\<Package>\<Package>ServiceProvider"
php artisan config:clear && php artisan cache:clear

Confirm the exact Packagist name before requiring — the vendor segment moved, but the package segment is unchanged, so gonzaloalonsod/<same-name> is the expected path.

Upgrading from v1.1 or earlier

1. Bump the constraint in composer.json and run composer update gonzaloalonsod/<package>.
2. Global-replace Gonzakpo\ → Gonzaloalonsod\ across app/, config/, tests/, database/, and any custom service providers.
3. Re-publish config if the provider's publish tags changed (check vendor/…/src/*ServiceProvider.php for $this->publishes([...], 'tag') and diff against your published copy).
4. composer dump-autoload -o and php artisan optimize:clear.

Where to look first

• composer.json in the package: the require block tells you whether Symfony 5 support came from widening a symfony/* constraint, which usually signals the package core is framework-agnostic with a thin Laravel bridge.
• README / CHANGELOG for the v1.2 entry — release notes are one line, so the code is the source of truth.
• The service provider: what it binds, aliases, and publishes determines your integration surface.

First use case: wire the package's primary entry point (facade or injected service) into a single controller or command, run it against a test fixture, and confirm output before touching production config.

Implementation Patterns

Container-first integration. Resolve through the container rather than new, so the Laravel bridge can swap implementations:

public function __construct(private \Gonzaloalonsod\<Package>\Client $client) {}

Config-driven setup. Publish the config and keep environment-specific values in .env, with the config file reading env() only — never hardcode credentials in the published file, since re-publishing on upgrade will overwrite it.

Boundary wrapper. Wrap the package in a single application-level service (App\Services\<Thing>Service) that owns all Gonzaloalonsod\ imports. When the next vendor rename or major version lands, you change one file instead of grepping the codebase.

Testing. Bind a fake or mock in the test container:

$this->app->instance(\Gonzaloalonsod\<Package>\Client::class, $fake);

If the package ships a Fake or testing trait, prefer it — hand-rolled doubles break silently when method signatures change.

Framework-agnostic usage (Symfony 5). If the package core is now documented as Symfony 5 compatible, the Laravel service provider is a convenience layer, not a requirement. That means in Laravel you can also construct the underlying class manually with explicit dependencies — useful in long-running workers where you want to control instantiation.

Queues and events. If the package dispatches jobs or events, ensure any payload objects are serializable by the new namespace — see Gotchas.

Gotchas and Tips

The rename will bite in non-obvious places. use statements are the easy part. Also check:

• Queued/serialized payloads. Jobs already sitting in the queue containing serialized Gonzakpo\... class names will fail to unserialize after deploy. Drain the queue before deploying, or deploy a transitional release that keeps a class_alias('Gonzakpo\\X', 'Gonzaloalonsod\\X') shim.
• Cached config and compiled views. php artisan config:cache snapshots class strings. Clear caches as part of the deploy, not after.
• Database rows storing fully-qualified class names (polymorphic model_type, job batches, failed_jobs payloads). Grep your schema for Gonzakpo before migrating.
• Published configs and migrations are copies — they do not get updated by composer update. Compare yours against the vendor originals.
• IDE / static analysis caches (PHPStan baseline, Psalm stubs, PhpStorm indexes) will report phantom classes until invalidated.
• Composer resolution. composer why-not gonzaloalonsod/<package> 1.2 is the fastest way to see which constraint is blocking the upgrade — often a transitive symfony/* pin.

On Symfony 5 support specifically. Symfony 5 is old (EOL since 2021). Support for it is likely a widened constraint (^4.4|^5.0) rather than new code paths. Two implications:

1. Do not read this as a signal that the package is actively modernized — check whether the require block still permits Symfony 6/7 and Laravel 10/11. If the constraint tops out at Symfony 5, you may be on a maintenance-only branch.
2. If you are on a current Laravel version, verify the package's illuminate/* constraint against your framework version. A Symfony 5-era release may not have been tested against recent Laravel minors; run your integration tests before promoting past staging.

Verification checklist for this upgrade

composer why-not gonzaloalonsod/<package> 1.2   # what's blocking
grep -rn "Gonzakpo" app/ config/ database/ tests/ resources/
php artisan config:clear && composer dump-autoload -o
php artisan test

Debugging. php artisan about confirms the resolved package versions; php artisan tinker + app()->make(...) confirms the binding resolves under the new namespace; composer show gonzaloalonsod/<package> shows the installed version and its declared requirements, which is the authoritative answer to "does this actually support my Symfony/Laravel version."

Extension points. If the package exposes contracts or an abstract base class, implement against the interface rather than extending the concrete class — vendor renames and major bumps tend to preserve interfaces while moving implementations.