Weave Code
Symfony Bundle Laravel Package
puli/symfony-bundle
Puli Symfony Bundle integrates Puli resource management with Symfony, enabling logical resource paths, centralized asset discovery, and URL generation across bundles and packages. It simplifies referencing and publishing resources in Symfony applications.
Puli Symfony Bundle integrates the Puli resource management system into Symfony applications, giving your project a unified way to reference assets and files across Composer packages. It wires Puli's repository and discovery services into the Symfony DI container, so logical paths like /app/css/style.css resolve to real files regardless of where they live on disk.
- Seamless Puli path resolution in services and Twig templates
- Asset URL generation through Puli's asset plugin
- Automatic repository configuration via the bundle extension
- Console commands for inspecting and debugging resolved paths
- Consistent resource handling across all installed packages
Frequently asked questions about Symfony Bundle
- Is puli/symfony-bundle a Laravel package?
- No. It is a Symfony2 full-stack bundle that wires the Puli resource-management library into Symfony's kernel, dependency-injection container, configuration system, and bundle lifecycle. Laravel has no bundle system and does not boot a Symfony full-stack kernel, so the package's primary integration surface simply does not exist in a Laravel application. Treat it as a legacy Symfony2 artifact rather than a reusable Laravel dependency.
- Can I install puli/symfony-bundle in a Laravel application?
- Composer may resolve it in isolation, but that does not make it usable. The bundle registers through Symfony's bundle and extension mechanisms, not a Laravel service provider, so none of its services, configuration, or Twig support would be wired up correctly. You should also expect Composer conflicts and runtime failures against modern PHP and Symfony component versions that Laravel pulls in. The practical answer for a Laravel stack is no.
- What does puli/symfony-bundle actually do?
- It integrates the Puli resource-management library into Symfony, providing resource path and URL resolution, asset publishing, and repository configuration for applications and bundles. It also exposes service container integration and Twig helpers so templates can locate and expose assets. In short, it maps logical resource paths to physical files across packages and bundles.
- Which Laravel and PHP versions are supported?
- There is no official Laravel support at all, because the package targets the Symfony2 full-stack framework, which Laravel does not use. The last release was 2016-01-14, so its Composer constraints reflect PHP 5.x and 7.x-era tooling, and Symfony 2.x bundle conventions. Modern Laravel releases on PHP 8 or later are very likely to conflict at the dependency level or fail at runtime.
- Is puli/symfony-bundle still maintained and safe for production?
- It appears abandoned: the final release was in January 2016, Symfony2 itself is end-of-life, and community signal is weak (roughly 36 stars, unknown or unlisted repository). The MIT license removes legal friction but does nothing about missing security patches, stale documentation, and unsupported PHP versions. If you depended on it, you would effectively be forking and owning maintenance yourself.
- Laravel already uses Symfony components, so will this Symfony bundle work?
- No. Laravel consumes individual Symfony components such as HttpFoundation and Console, but a Symfony bundle depends on the full-stack FrameworkBundle, kernel bootstrapping, and bundle lifecycle that Laravel never runs. Sharing a few components does not make bundles compatible with Laravel's container, providers, or facades. You cannot register a Symfony bundle as a Laravel service provider.
- How do I replace Puli resource paths in a Laravel app?
- Inventory every place a Puli resource path or URL is referenced, then define an application-owned interface such as a ResourceResolver port. Implement it with Laravel-native primitives: the Storage facade and Flysystem for disks, base_path() and public_path() for local locations, config() for repository mapping, and asset() or url() helpers for URL generation. Migrate call sites incrementally with tests covering path resolution, caching, asset URLs, and environment differences, then remove Puli references entirely.
- How do I configure puli/symfony-bundle in a legacy Symfony2 project?
- Register the bundle in AppKernel, enable it in the application configuration, and define your Puli repositories and resource paths in the bundle's configuration section so the container services and Twig helpers receive them. Because the package is frozen in the Symfony2 era, pin your PHP and Symfony versions in a container or disposable branch and document the exact versions that work. Avoid sharing those bundle internals with any newer application.
- How should I spike-test compatibility before committing to this package?
- Run a short, timeboxed dependency and compatibility spike in an isolated branch or container with pinned PHP and Composer versions, so the main Laravel application is never contaminated. Record the concrete failure modes you hit, such as Composer constraint dead ends, autoload mismatches, or container bootstrapping assumptions. Finish with a written architecture decision: adopt, isolate, replace, or reject. For a Laravel codebase, that decision is almost always replace or reject.
- What are the alternatives to Puli for asset and resource resolution in Laravel?
- For most needs, Laravel's own filesystem abstraction, Storage facade, public_path(), config(), and the asset() and url() helpers cover resource resolution and URL generation behind a small custom resolver. If you want the underlying Puli behavior rather than the dead Symfony bundle, evaluate the Puli library itself or a maintained alternative, wrapped in your own interface so it can be swapped later. Only adopt such a library behind an application-owned abstraction with a funded exit plan.
Weaver
How can I help you explore Laravel packages today?