Repository Laravel Package

Product Decisions This Supports

• Build vs. buy for a resource-abstraction layer. Puli is a template for how to model "resources" (files, assets, configs, translations) as addressable paths that can be mounted from multiple repositories. If we're considering a unified locator for plugin/theme/package assets, this is the reference spec.
• Modularity and plugin/extension strategy. If the roadmap includes third-party plugins, a theme marketplace, or tenant-specific asset overrides, Puli's vocabulary — path schemes, mount points, pluggable repositories — is the right frame for the design conversation.
• How packages ship resources. Laravel's own mechanism (loadViewsFrom, loadTranslationsFrom, mergeConfigFrom, publishes) is what actually decides this today; Puli informs whether we need an additional discovery layer beyond it.
• Legacy portfolio and migration scoping. If any inherited codebase depends on Puli (plausible in Symfony 2/3-era apps), this assessment quantifies the cost of staying vs. removing it, and feeds a "sunset dependency" line item.
• Storage/backend abstraction. Relevant conceptually for local vs. S3 vs. CDN resolution, but Flysystem and Laravel Disks are the operative decision there — Puli is a talking point, not a candidate.
• Use cases to score against: plugin asset discovery, multi-tenant theming, package-provided seeds/config, static asset publishing, CMS-style resource resolution.

When to Consider This Package

Adopt only in these narrow cases:

• You are maintaining a legacy Symfony 2.x/3.x application that already depends on Puli, and a migration isn't funded this cycle.
• You need a reference implementation of resource-repository design — read the source, don't require the package.
• You are doing dependency archaeology on an inherited codebase and need to understand what this layer was doing.

Do not adopt for any new Laravel application. Signals against it:

• Unmaintained since 2016-02-05 — no releases, no security patches, no PHP 8+ compatibility work, upstream archived. Composer installs will typically conflict with PHP 8 and Laravel 9–11.
• Zero Laravel integration — no service provider, no facade, no container bindings. We would own 100% of the glue code, tests, and future patching.
• Transitive surface area — it is one component of a larger (also abandoned) ecosystem; pulling it in drags 2016-era Symfony components along.
• Maturity signal is historical, not current — 440 stars and a 3.54 score reflect 2014–2016 interest, not present-day viability. MIT license means we could fork, but that's a permanent maintenance tax for a solved problem.

Look elsewhere when you need:

• Filesystem/storage abstraction → league/flysystem, Laravel Storage + disks.
• Package-provided views/config/translations/assets → Laravel service-provider conventions (loadViewsFrom, publishes, mergeConfigFrom).
• Module/plugin discovery → nwidart/laravel-modules or Composer-based discovery (spatie/laravel-package-tools).
• Path/mount resolution → symfony/filesystem plus a small in-house resolver; realistically 100–200 lines.
• URI/stream handling → PSR-7 implementations (nyholm/psr7, guzzlehttp/psr7).

How to Pitch It (Stakeholders)

Executive summary. Puli is a well-designed but abandoned 2016 PHP library for treating files and other resources as mountable, addressable paths. It solved a real problem — letting packages and plugins contribute assets, views, and config from anywhere in the filesystem — but it has had no release or security patch in roughly a decade and targets a PHP 5/Symfony 2–3 world that is incompatible with our stack. Recommendation: do not add it as a dependency. The capabilities it represents are already covered by supported, free components we run today: Laravel's filesystem disks and service-provider resource publishing, plus Flysystem underneath. The 440 stars and 3.54 score are a historical-interest signal, not an endorsement.

For engineering. Treat this as a design document, not a vendor. Its value is the model: named path schemes, mount points, and pluggable repositories as a clean way to decouple "where a resource lives" from "who consumes it." If we hit a genuine plugin/theme asset-discovery requirement on the roadmap, the cheap path is a 1–2 day spike on Laravel's provider conventions plus Flysystem, borrowing Puli's concepts. Adopting the package itself means: unresolvable Composer constraints on PHP 8, forking to patch abandoned internals, writing our own service provider and test suite, and a permanent maintainer burden with a bus factor of zero. The build cost is small; the carry cost is not.

For product. No customer-facing feature is gated on this package. The only decision it should influence is whether to invest in a first-class resource-locator capability at all — and if we do, the implementation will not be Puli. Budget it as design inspiration, not as a line item.