Weave Code
Dload Laravel Package
internal/dload
DLoad simplifies downloading and managing binary artifacts for PHP projects. Automatically fetch tools like RoadRunner, Temporal, and custom binaries at pinned versions, ensuring consistent, cross-platform dev environments without committing binaries to version control.
Helps to download binaries from release assets
Frequently asked questions about Dload
- How do I install and configure DLoad in a Laravel project?
- Install it with Composer using composer require internal/dload, then initialize an XML configuration that lists the software and pinned versions your project needs. DLoad is schema-validated, so configuration errors are caught early. In Laravel, you can run dload get from a Composer script or wrap it in a service provider and Artisan command. This keeps binary setup reproducible without committing binaries to version control.
- How does DLoad integrate with Composer install and update scripts?
- Add dload get --no-interaction to your composer.json post-install-cmd and post-update-cmd scripts. Composer then downloads the configured binaries automatically whenever dependencies are installed or updated. This is the standard Composer-first integration and typically takes less than five minutes to set up. It replaces manual curl and tar steps or committing binaries to the repository.
- Can DLoad download RoadRunner, Temporal, and other CLI binaries?
- Yes. DLoad is designed for tools like RoadRunner, Temporal, and custom binaries or PHARs that PHP projects depend on. It fetches release assets at pinned versions and manages them alongside your Composer dependencies. This ensures every team member and CI job uses the same tool versions.
- Does DLoad support .tgz and .tar release archives?
- Yes, DLoad 1.19.0 added archive extraction for .tgz and .tar artifacts, not just raw binaries and PHARs. That covers many Go, Node, and Rust release assets that are distributed as tarballs. It removes the need for bespoke curl piped into tar scripts in your setup. Archive extraction is a newer code path, so include it in upgrade regression tests.
- How do I pin binary versions so every developer gets the same tool?
- Define the software and version constraints in DLoad's XML configuration, then run dload get to resolve and download matching artifacts. Because the configuration is committed while the binaries are not, all developers and CI jobs resolve from the same pinned constraints. DLoad 1.19.0 reworked its constraint engine, so review and diff resolved versions after upgrading to confirm nothing drifts.
- Can DLoad use self-hosted repositories or work in air-gapped environments?
- Yes. DLoad 1.19.0 added support for self-hosted repository URLs, so relying on GitHub's release API is now an architectural option rather than a hard requirement. Mirroring and air-gapped operation become configuration instead of a retrofit. You can also configure fallback across repositories for invalid URIs or unknown types. This improves reliability for private infrastructure and restricted networks.
- How do I define custom binaries or use software definitions shipped by Composer packages?
- DLoad uses an XML software registry plus a plugin-like registry, and 1.19.0 lets installed Composer packages contribute software entries addressable as package#id. That makes the internal-registry pattern first-class instead of a hand-rolled shared package. Shadowed entries are reported, but any package can influence what binary your build downloads. Treat package-provided definitions as a supply-chain surface and maintain an explicit allowlist with review.
- How does DLoad handle cross-platform binaries and macOS architectures?
- DLoad resolves platform-specific release assets so the same configuration works across operating systems. Version 1.19.0 added macOS universal and x86-64 microarchitecture ranking, which reduces the works-on-my-machine class of CI failures. Repository fallback also helps when a URI is invalid or an artifact type is unknown. Test the platform matrix you support in CI after upgrading.
- Is DLoad safe for CI/CD and production builds?
- DLoad is Composer-first and runs non-interactively with dload get --no-interaction, which fits CI pipelines. Its repository fallback and improved platform ranking make builds more reproducible, but archive extraction and Composer-distributed software definitions are new risk surfaces. Pin versions, allowlist packages that ship definitions, and avoid letting transitive dependencies silently choose binaries. Run the install path in a staging CI job before production rollout.
- What changed in DLoad 1.19.0 and how should I test the upgrade?
- DLoad 1.19.0 is a substantive release that adds archive extraction, self-hosted repository URLs, package-provided software definitions, and a reworked version constraint engine. It also rebuilds the installer and registry paths as pipelines, which is a large diff in code that runs on every composer install. Upgrade cost is low but non-zero: review constraint re-resolution, capture and diff resolved versions before and after, and run an install-path regression test. Optionally adopt archives, repository URLs, and package definitions after the core upgrade is stable.
Weaver
How can I help you explore Laravel packages today?