Dload Laravel Package

Product Decisions This Supports

• Developer Onboarding & Tooling Standardization: Eliminates friction in setting up project-specific binaries (e.g., RoadRunner, Temporal, PHAR tools) by automating downloads and version pinning. Reduces "works on my machine" issues by ensuring consistent tooling across teams. As of 1.19.0, tool definitions can now ship inside Composer packages, meaning a platform team can publish acme/tools and have composer install provision every internal binary — no XML files, no installer scripts, no per-repo config drift.

• Build vs. Buy Decision: Buy for projects requiring:

  • Cross-platform binary distribution (Windows/Linux/macOS/ARM, including universal macOS binaries and x86-64 microarchitecture levels).
  • Version-constrained tooling with real SemVer semantics — hyphen ranges, !=/<>, v prefixes, build metadata, numbered pre-releases, and 5+ part versions are all supported as of 1.19.0.
  • .tgz/.tar archives as well as raw binaries and PHARs.
  • Self-hosted / non-GitHub asset hosting — 1.19.0 adds repository URLs, so GitHub-only is no longer a constraint. Build only if needing:
  • Advanced pre/post-download hooks (e.g., license acceptance prompts, custom checksum verification).
  • Non-HTTP transports (internal artifact stores requiring proprietary SDKs).

• Roadmap Priorities:

  • Phase 1: Integrate dload into project templates (e.g., Laravel/Symfony starter kits) to auto-provision tools like rr, temporal, or buf.
  • Phase 2: Ship software definitions as Composer packages in an internal acme/tools meta-package — this is now a supported pattern and should be the default distribution mechanism for internal binaries.
  • Phase 3: Point dload at self-hosted repositories (Nexus/Artifactory/internal GitLab) to remove the last external dependency from the toolchain.
  • Phase 4: Extend to CI/CD pipelines (GitLab/GitHub Actions) for zero-config dev environments, using built-in CI snippets.

• Use Cases:

  • Local Development: Auto-download rr/temporal during composer install (via post-update-cmd).
  • CI/CD: Pre-install tools in GitLab/GitHub Actions (see dload’s built-in CI snippets).
  • Cross-Platform Teams: Ensure Windows/macOS/Linux and Intel/ARM devs use identical tool versions; 1.19.0 ranks universal macOS builds and microarchitecture levels correctly.
  • PHAR Management: Distribute PHP tools (e.g., psalm, phpstan) without manual PHAR downloads.
  • Internal Tooling Distribution: Publish company binaries to a private server and consume them via <package>#<id> addressing.
  • Regulated / Air-gapped-Adjacent Environments: Self-hosted repositories plus single-origin token handling (GitLab tokens are now scoped to the GitLab server and never leaked across redirects).

• Vendor Risk Readiness: Five minor releases shipped between 1.13.1 (May 2026) and 1.19.0 (Oct 2026), with no breaking changes and a documented, incremental surface. This is a healthy signal for a dependency that touches build reproducibility — it is actively maintained and additive rather than churning.

When to Consider This Package

Adopt dload if:

• Your project relies on external binaries/PHARs/archives (e.g., RoadRunner, Temporal, buf).
• You need version pinning with full constraint syntax (e.g., roadrunner:^2025.1.0, >=1.0 <2.0, 1.0.0 - 1.4.0).
• Your team spans multiple OS/architectures (auto-selects correct binaries, including universal macOS and x86-64 levels).
• You want to avoid manual curl/wget scripts for tooling setup.
• You host binaries on internal or self-hosted servers — 1.19.0 removes the previous GitHub-only limitation.
• You want tool definitions versioned and distributed via Composer alongside the code that consumes them.
• You’re building custom RoadRunner binaries with Velox.

Look elsewhere if:

• You require advanced pre/post-download logic — license agreements, interactive acceptance, or custom checksum verification are still not first-class features.
• You need non-HTTP transports or integrations with artifact stores that require proprietary client SDKs.
• Your tools are already packaged in Composer (no need for binaries).
• You’re constrained by legacy systems that can’t run PHP CLI tools.

Migration note: The 1.18 → 1.19 upgrade is additive, but two behaviors changed in ways worth verifying: version constraints now use DLoad’s own ordering (build metadata like +build.5 is ignored, long numeric parts compare numerically), and the downloader now skips OS packages and un-unpackable archives when a binary is expected and names the skipped packages in failure reports. Pin the DLoad version in CI and re-run your tool-install step once on upgrade.

How to Pitch It (Stakeholders)

For Executives:

*"DLoad solves a critical pain point in PHP development: consistent, automated tooling setup. Today, developers waste hours manually downloading and configuring binaries like RoadRunner or Temporal—leading to environment drift and onboarding delays. With DLoad, we:

• Cut onboarding time by 80% by auto-provisioning tools during composer install.
• Eliminate ‘works on my machine’ issues by pinning exact tool versions (e.g., roadrunner:^2025.1.0).
• Support global teams with cross-platform binary handling (Windows/macOS/Linux, Intel/ARM, .tar/.tgz archives).
• Keep our binaries private: the latest release supports self-hosted repositories and scopes access tokens to their own server, so internal tooling no longer has to leave our infrastructure.
• Future-proof CI/CD with zero-config dev environments.

Investment: Minimal (Composer dependency). ROI: faster dev cycles, fewer environment bugs, scalable tooling, and no external hosting dependency."*

For Engineering:

*"DLoad is a batteries-included solution for managing PHP binaries/PHARs. Key benefits:

• Zero-boilerplate downloads: Replace curl | bash scripts with composer require internal/dload + dload get.
• Cross-platform magic: Auto-selects the right binary for the host OS/arch (e.g., roadrunner-linux-amd64 vs. roadrunner-darwin-arm64), correctly ranks universal macOS builds and x86-64 microarchitecture levels, and unpacks .tgz/.tar assets.
• Composer-native distribution: Software definitions can now live in Composer packages and be addressed as <package>#<id>. Publish one acme/tools package and every repo gets the same binaries and versions.
• Self-hosted repositories: Point at Nexus, Artifactory, or an internal GitLab/GitHub Enterprise instance. Repositories fall back gracefully — an invalid URI, unknown type, or failed download moves to the next configured source, and failures report exactly which OS packages were skipped and whether an older release was substituted.
• Safer credentials: GitLab tokens are sent only to the GitLab server and are not forwarded across redirects.
• Custom RoadRunner builds: Use Velox to generate tailored binaries with specific plugins (e.g., Temporal + KV store).
• CI/CD ready: Built-in GitLab/GitHub Actions snippets for pre-installing tools.

Tradeoff: Still not the right fit for complex pre/post-download logic such as license acceptance or bespoke checksum verification. Note that version-constraint semantics changed in this release — build metadata is ignored and long numeric parts compare numerically — so re-verify pinned constraints once. For everything else, it’s 10x faster than manual setup."*

Call to Action:

• PMs: Add dload to project templates and CI pipelines; standardize internal binary distribution through a shared Composer package.
• Devs: Replace manual tool downloads with dload get in composer.json, and migrate hand-rolled curl scripts to repository-backed definitions.
• Architects: Use Velox builds for custom RoadRunner configurations and point dload at self-hosted repositories to eliminate external hosting dependencies.