- Is keesschepers/dhlparcelapibundle a Laravel package?
- No. It is a Symfony 2 bundle, not a Laravel package. Bundles depend on Symfony's Bundle class, dependency injection container, and YAML/XML configuration tree, none of which Laravel's service container consumes. In a Laravel codebase it installs as inert weight at best and fails dependency resolution at worst. Treat the repository as reference material for DHL Parcel's API contract rather than as an installable dependency.
- Can I install this DHL Parcel bundle in a Laravel app via Composer?
- Composer may resolve it, but it will pull PHP 5.x and 7.0-era constraints for Symfony, Guzzle, and PHPUnit that conflict with a modern Laravel lockfile, so expect a confusing dead end. Even if it installs, there is no Laravel service provider, facade, or publishable config, so nothing gets wired into your application. The practical answer is do not add it to composer.json. Vendor only specific transport code if the bundle contains non-trivial signing or label assembly logic.
- Which Laravel and PHP versions does this package support?
- No Laravel version is supported, because it is not a Laravel package. On the PHP side, the Symfony 2.x foundation it depends on reached end-of-life in November 2018 and does not support PHP 8.x. That makes it incompatible with any current Laravel release, which requires PHP 8.1 or newer. Plan for a replacement rather than a version compatibility matrix.
- What DHL Parcel features does the bundle actually cover?
- The bundle advertises three capabilities: creating parcel shipments, generating shipping labels, and looking up tracking information for outbound parcels. Credentials and endpoint settings live in Symfony bundle configuration while application code talks to service objects. The real value is the DTOs, request builders, and response parsers that encode DHL's payload schemas, label formats, and error codes, which you can read as a specification. Address validation and return labels are not listed, so verify scope before assuming them.
- Does the bundle wrap an official DHL SDK or hand-roll the API calls?
- The overview and README excerpt do not say whether it wraps an official DHL SDK or hand-rolls HTTP calls, so inspect the request builders and client classes before deciding. The question matters because hand-rolled clients tend to encode an older DHL Parcel contract and often reimplement authentication or signing incorrectly over time. If it delegates to an official SDK, skip the bundle and use that SDK directly. If the transport is hand-rolled and thin, port it or re-derive it from DHL's published documentation.
- How do I configure DHL Parcel credentials in Laravel instead?
- Skip the bundle and put credentials in config/dhlparcel.php backed by .env entries, then bind a small client class in a service provider. Build it on Laravel's HTTP client with timeouts, retries, and logging so requests and failures are observable. Keep DHL-specific request and response shapes in dedicated DTOs so label formats and error codes stay testable without hitting the API. A few hundred lines typically covers shipments, labels, and tracking.
- Is this bundle safe to use in production for shipping and labels?
- No. Symfony 2.x has been end-of-life since November 2018, so there are no security patches and no PHP 8.x support. A dependency anchored to an unsupported framework will not clear a security or compliance review in a payment or shipping path. The zero-star, zero-dependent profile also means no downstream community absorbs breakage and no upstream exists to escalate to. Use it for reading, not for runtime.
- What are the alternatives for DHL Parcel integration in Laravel?
- Your options are an official DHL Parcel SDK if one covers your API version, DHL's published REST/JSON documentation for a native client, or a maintained community shipping package. Note that DHL Parcel has moved from older SOAP/XML conventions toward REST/JSON, so a Symfony 2-era bundle likely encodes the older contract and would surface schema changes as runtime failures. For Laravel specifically, a small HTTP-client-based service behind an interface is usually the lowest-risk route. Isolate whichever option you pick so it can be swapped later.
- How do I migrate from this Symfony bundle to a native Laravel client?
- Follow three steps: extract the contract, build a native client, and isolate it. Read the request builders, DTOs, and response parsers to document endpoints, auth headers, payload schemas, label formats, and error codes; that document outlives the package. Then implement a DhlParcel class on Laravel's HTTP client, bound in a service provider and configured through config/dhlparcel.php and .env. Vendor the transport only if signature calculation or label assembly is genuinely expensive to re-derive, and hide it behind an interface.
- Is the package actively maintained, and how risky is depending on it?
- It shows zero stars, zero dependents, and a composite score of 0.03, which is about as unattended as a package gets. There is no downstream community to absorb breakage and no upstream maintainer to escalate to, and the underlying framework has been end-of-life since 2018. Combine that with expected API drift from SOAP/XML toward REST/JSON and any runtime failure is yours to debug alone. For a shipping path in a Laravel app, that risk profile argues for building and owning a small client instead.