- Can I use mi/puli-metadata-file-locator-bundle in a Laravel application?
- No. This is a Symfony bundle that decorates Symfony's file_locator service so MetadataFileLocator consumers can resolve logical Puli resource paths, and Laravel has no MetadataFileLocator, no bundle kernel, and no compiler passes to hook into. Laravel's own mechanisms such as service providers, vendor:publish, resource_path(), and package discovery already handle package-provided config and assets. There is no idiomatic place to register a Puli-backed locator in Laravel, and doing so would create a parallel discovery system competing with the framework's own.
- Which Symfony versions does this bundle support?
- It targets the Symfony 2.8 and 3.x era, where Puli integration still existed. Symfony deprecated its Puli integration in 3.3 and removed it entirely in 4.0, so this bundle cannot work with Symfony 4, 5, 6, or 7. Expect PHP 5.5 to 7.x constraints in the composer.json, and verify those before committing to anything.
- How do I install mi/puli-metadata-file-locator-bundle?
- Install it with Composer and register the bundle in AppKernel near FrameworkBundle so its compiler pass runs. You also need a puli.json manifest bound at container compile time, which pulls in puli/manager, puli/discovery, and the Puli Composer plugin. Be aware that the Puli Composer plugin changes install behaviour, which is a CI reproducibility concern on its own.
- What does this bundle actually do?
- It registers a metadata file locator as a Symfony service that discovers puli.json files across your project root and vendor directories. The locator decorates Symfony's file_locator, so consumers such as the validator, serializer, Doctrine, translation, and routing loaders resolve logical Puli paths like /acme/blog/doctrine instead of filesystem paths or @AcmeBundle notation. Search paths are configurable through bundle configuration.
- How do I configure which directories are searched for puli.json files?
- Search paths are exposed through the bundle's configuration, so you can declare which project and vendor directories the locator should scan. After changing configuration, clear the container cache and inspect the compiled container with debug:container file_locator to confirm the service class has actually been replaced. If the class is unchanged, the decoration did not take effect and Puli paths will not resolve.
- Is Puli still maintained, and is this bundle safe to depend on?
- Puli itself is abandoned upstream, and this bundle has zero stars, zero dependents, and zero forks, which means no external validation, no downstream bug reports, and nobody else hardening this path. Any CVE in the Puli dependency tree becomes permanently yours because no one is patching it. The risk here is lifecycle-driven rather than code-quality-driven, and it sits on the container compilation hot path.
- What are the alternatives to using Puli for finding package metadata files?
- For most projects, an explicit ordered path list resolved by the framework's native locator is enough. In Laravel, resource_path(), vendor:publish, and extra.laravel package discovery already cover package-provided config without a resource abstraction. In Symfony, %kernel.project_dir% plus a small custom FileLocatorInterface decorator of roughly 200 to 400 lines with unit tests will typically satisfy the requirement without inheriting an abandoned dependency tree.
- How can I verify the locator is working before adopting it?
- Timebox a one-to-two-day spike in an isolated branch: resolve dependencies, boot a minimal kernel, and prove one validator metadata file loads through a Puli path. Then confirm the path-not-found failure mode is observable and that both Puli and filesystem paths still resolve. Check debug:container file_locator to see which class is actually wired, and expect PHPUnit and static-analysis tooling conflicts along the way.
- Is it safe to run this bundle in production?
- Only if you already run Puli in a maintained Symfony 2.8 or 3.x application and have a named engineer willing to own a fork for the life of the product. The failure surface is container compilation and file-not-found exceptions, which is a poor place to carry an unmaintained dependency. For any greenfield project or Laravel application, the answer is not to adopt it.
- Does this bundle affect Doctrine, validator, serializer, and translation metadata loading?
- Indirectly, yes, because those Symfony components are MetadataFileLocator consumers and will resolve Puli logical paths once the locator is decorated. That only holds on legacy Symfony versions where Puli integration still exists, so the benefit disappears on Symfony 4 and above. If you are not already using Puli resource paths, this bundle adds a dependency without changing how those loaders find files.