- How do I install nextbyte/laravel-couriers in a Laravel application?
- Install it with Composer using composer require nextbyte/laravel-couriers, then publish the package config file. Laravel package auto-discovery should register the service provider and facade, after which you configure a courier driver and credentials. Expect the real work to be mapping your order, address, and parcel models onto the package's DTOs rather than wiring the package.
- How do I configure courier credentials and choose a default driver?
- Publish the package config and define credentials, endpoints, and defaults per carrier account, preferably through environment variables rather than hard-coded values. Choose a default driver in config so shipping can be swapped per environment without code changes. Confirm credential resolution goes through Laravel config/env, especially for production.
- Which Laravel and PHP versions does nextbyte/laravel-couriers support?
- The provided context does not list exact Laravel and PHP constraints, so check the package's composer.json for v1.5.0 against your pinned runtime before adopting it. A package lagging a Laravel major version becomes upgrade tax, and minor Laravel releases can change container and config behavior. Confirm the declared ranges bracket your current PHP and Laravel versions.
- What can I do with laravel-couriers: shipments, tracking, rates, and labels?
- The package is presented as a unified API for shipments, tracking, rates, and labels, with typical operations such as createShipment, track, cancel, and rate or label retrieval. Exact methods and response shapes depend on the courier driver, so map your order, address, and parcel models onto its DTOs and vocabulary. Do not assume every driver covers every capability.
- How do I add a custom courier driver to laravel-couriers?
- The package resolves per-carrier drivers from config, so a custom courier normally means implementing the package's driver contract and registering it through the manager or config. Keep carrier-specific HTTP and payload translation inside that driver, not in domain code. Check the driver interface against the release diff before upgrading, because that is one place a minor version can break consumers.
- How can I test Laravel courier integrations without live carrier credentials?
- Wrap courier calls behind your own gateway and use a stub implementation for most tests, then mock driver HTTP calls for package-specific tests. The TPM assessment says to confirm whether the package's suite mocks carrier calls or gates live tests, because live-gated tests are not suitable for CI. Never require production credentials in unit tests.
- Does laravel-couriers log addresses, phone numbers, and customs data in production?
- Shipping integrations touch names, addresses, phone numbers, and customs data, so treat shipment payloads as PII. Before production, confirm the package does not log full payloads at debug level by default and review your Laravel logging configuration. Keep credentials in config/env and redact sensitive fields in your own logs.
- What changed between v1.4.3 and v1.5.0, and should I upgrade?
- The v1.4.3 to v1.5.0 release notes are a bare compare link, so semver suggests an additive minor bump but does not prove it. Read the diff and commit list and check whether driver interfaces, config keys, exception classes, or response shapes changed. If any public contract moved, pin to v1.4.3 and open an upgrade ticket; if the change is only new drivers or additive options, v1.5.0 is reasonable to adopt.
- Is nextbyte/laravel-couriers actively maintained, and what are the alternatives?
- The TPM assessment flags a single-maintainer package in the logistics path as a continuity risk, so check issue and PR responsiveness and release cadence before committing. Alternatives include direct carrier SDKs, a custom internal shipping gateway, or another Laravel multi-carrier abstraction. Whichever you choose, keep it behind your own interface so you can swap or exit if maintenance stalls.
- How should I structure Laravel code that uses the Courier facade?
- Put the package behind an internal ShippingGateway interface with a package-backed implementation and a null or stub implementation for tests. Domain code should depend only on your interface, not on Courier facade calls in controllers. This roughly one-day layer lets you swap carriers, test without credentials, and exit the package if maintenance stalls.