Bill Order Bundle Laravel Package

Getting Started

• Install with composer require tourze/bill-order-bundle — but pin exactly ("tourze/bill-order-bundle": "0.0.1") while you evaluate. At 0.0.x Composer interprets ^0.0.1 as <0.0.2, so every bump is deliberate anyway.
• First places to look, in order: composer.json (check type, require, autoload — is this a Symfony bundle or a plain library?), src/ top-level for the domain objects (bill/order/item, status enum), the README, then tests/. At 0.0.1 the tests are the only trustworthy spec.
• Settle the framework question before anything else. "Bundle" implies a Symfony bundle with a *Bundle class and a DI extension. Laravel has no equivalent and will not auto-register it. If there is no Illuminate\Support\ServiceProvider, treat it as framework-agnostic PHP and wire it yourself in AppServiceProvider.
• First use case: in a throwaway feature test, create one order through the package's service/repository, read it back, and drive a single status transition. Do not start from your real checkout flow.

Implementation Patterns

• Put a boundary around it. An App\Orders\OrderService (or a couple of action classes) that depends only on the package's interfaces. When 0.1.0 renames something you edit one file instead of forty.
• Config: if the package ships config/ or Resources/config, mergeConfigFrom() the file and expose only the keys you actually set. Do not vendor:publish a Symfony YAML/XML file — Laravel will not read it.
• Schema: if it ships Doctrine mappings or raw SQL, hand-translate to Laravel migrations (unsigned bigint FKs, indexes on order_id, status, created_at) and keep the migration files in your repo. Don't run vendor SQL ad hoc; you lose schema history.
• Status changes: let the package's status enum be authoritative, but emit your own OrderStatusChanged event at the boundary so reporting and notifications don't read internal tables.
• Money: establish up front whether amounts are integer minor units or a Money value object, and add a cast/accessor at your boundary either way. Retrofitting this later is painful.
• Factories: if none are provided, write your own in database/factories against the package's models/entities so feature tests stay readable.
• Side effects: queue jobs, mail, and webhooks belong in listeners on your own events — outside whatever transaction the package opens.

Gotchas and Tips

• No BC promise at 0.0.1. Read the src/ diff of every tag before upgrading; the release notes here are just a compare link.
• Missing bindings show up as Target [X] is not instantiable in Laravel. That's not a package bug — bind the interfaces explicitly in a service provider.
• Never let Doctrine and Eloquent write the same rows. Pick one write path; if you must use both, wrap the entity in your own model or keep the package's writes inside a single transaction boundary.
• Transactions: check whether the package opens its own and on which connection. Nesting its transaction inside DB::transaction() on a separate connection can deadlock or silently fail to roll back. Force a single connection in config if needed.
• env() inside the package returns null once config:cache runs. Look for it in src/ and override via your own config file.
• Hardcoded table prefixes/schema names are common at this maturity. Check before pointing it at a non-default schema.
• Debugging: composer show tourze/bill-order-bundle, then read vendor/tourze/bill-order-bundle/src directly — the surface is small at 0.0.x. Use php artisan tinker to instantiate the service in isolation and get a clean stack trace.
• Extension points to look for: repository/calculator interfaces, event dispatcher usage, and any *Extension or compiler pass. The Symfony ones you will have to reimplement manually as Laravel bindings.
• Pin and watch: with no changelog beyond the compare link, subscribe to repo releases and diff src/ yourself before every bump.