tourze/credit-resource-bundle
A Symfony bundle that models credit accounts and point balances as API Platform resources. It packages Doctrine entities, resource metadata, and serialization configuration so you can expose credit balances and transaction records through REST or GraphQL endpoints with minimal boilerplate.
The 0.0.1 tag ships with no release notes beyond a changelog link, so treat the source as the specification. Budget the first hour for discovery, not integration.
Install and pin
composer require tourze/credit-resource-bundle:0.0.1
Pin the exact version. On a 0.0.x line any patch release may break you; a committed composer.lock plus an exact constraint is the only thing standing between you and a surprise refactor.
Read these four things before writing code
vendor/tourze/credit-resource-bundle/composer.json — check require (Laravel vs Symfony components, PHP floor), autoload.psr-4, and whether extra.laravel.providers / extra.laravel.aliases is present.vendor/tourze/credit-resource-bundle/src/ — the class list is the real API surface. find src -name "*.php" | sort.config/, database/migrations/, resources/ directory — this tells you whether it is publishable configuration or a pure domain library.*Bundle.php or *ServiceProvider.php class — this is where bindings and extension points live, and it is the single most informative file in the repo.Name caveat. The -bundle suffix is Symfony vocabulary. Confirm early whether this is a Symfony Bundle (no Laravel auto-discovery, you will register it manually or use only its domain classes) or a Laravel package with a conventional provider. This decision changes your integration shape more than anything else in the package.
First use case. Don't build your feature first. Open php artisan tinker and drive the smallest possible credit lifecycle: resolve the primary service from the container, create a credit/account record, apply a credit, then apply a debit and read the resulting balance. If any of those steps require a class you have to guess at, the package is not ready for your production path yet and you should wrap it rather than call it directly.
Resolve through the container, never instantiate. Whatever the entry point is — a manager, a ledger service, a repository — pull it via constructor injection. If the package exposes an interface, bind it in your own AppServiceProvider so you can swap in a decorator later without touching call sites.
$this->app->bind(CreditManagerInterface::class, CreditManager::class);
Publish and own the config. If config/ exists:
php artisan vendor:publish --provider="Tourze\CreditResourceBundle\..."
Published config is yours; unpublished config can change under you on any upgrade. Publish everything you depend on.
Treat balances as derived, not stored. "Credit resource" packages generally model an append-only set of entries plus a running balance. Prefer reading the balance through the package's accessor and never writing to a balance column directly — a cached balance that drifts from the entry history is the classic failure mode of this domain.
Wrap money-moving calls in a transaction with a lock.
DB::transaction(function () use ($manager, $account, $amount) {
$manager->credit($account, $amount, reference: $order->id);
});
If the package offers no locking primitive, add lockForUpdate() around your own read-then-write sequences, or use an atomic increment where the package allows it.
Make every operation idempotent at your layer. Pass a stable reference (order ID, job ID) and put a unique index on it in your own table if the package does not. Retried queue jobs crediting twice is the most common production incident in this category.
Migrations. Publish, read, then migrate. Inspect column types for IDs (ULID/UUID vs auto-increment) and foreign keys before running in production, and check whether the package's migration publishes into database/migrations with a timestamp that sorts correctly against your existing migrations.
Testing. Use RefreshDatabase, and if the package ships factories, prefer them over hand-built models. If it does not, write your own factory in tests/ — it will be the first thing you need when the API shifts.
Integration seam. Put a thin application-level service (App\Billing\CreditService) in front of the package and call that from controllers and jobs. On a 0.0.x dependency this is not ceremony — it is the difference between a one-file upgrade and a grep across forty call sites.
git log on the vendor directory (or the GitHub compare view) is your changelog. Before every bump, diff the public API surface, not just the version number.composer require, run php artisan about or php artisan package:discover -v and confirm the provider appears. A missing provider manifests as Target [X] is not instantiable deep in a request, which is a slow way to learn this.Symfony\Component\HttpFoundation or Symfony's serializer, you will be converting at the boundary. Check the composer.json require block before you design your controllers around these types.decimal, or float. If the package uses floats anywhere in the credit path, wrap it and convert to integer minor units at your boundary immediately.php artisan tinker plus app()->make(Foo::class) and app()->bound(Foo::class) resolves most wiring questions faster than reading the provider top-to-bottom.credit_entries table and a CreditService implementation that can be swapped behind the same interface. That path costs a day now and saves a quarter later.How can I help you explore Laravel packages today?