- Is igdr/manager-bundle a Laravel package or a Symfony bundle?
- The naming and class conventions point to a Symfony bundle, not a Laravel package. The Bundle suffix and ManagerBundle class naming are Symfony idioms, with a DependencyInjection extension, compiler passes, and services.yaml wiring. There is no evidence in the metadata of a Laravel ServiceProvider, facade, or illuminate/* dependency. Treat any claim of Laravel compatibility as unproven until you read the source.
- Can I install igdr/manager-bundle in a Laravel application?
- Not on the assumption that it is PHP so it will just work. Symfony bundles assume symfony/http-kernel, the Symfony event dispatcher, and the Symfony DI container, while Laravel ships its own container and does not load bundles. Framework-agnostic PHP libraries can be adopted behind an adapter, but Symfony bundles generally cannot be adopted into Laravel without reimplementing the container wiring. Verify the composer.json require block against your Laravel and PHP baseline before adding it to composer.json.
- What does igdr/manager-bundle actually do?
- Per its blurb, it provides reusable manager services that centralize common entity operations and keep business logic out of controllers, offering an extendable foundation for CRUD-style workflows. That is the entire documented scope. The repository has no README and no usage examples, so the public API surface is undefined. The word manager is ambiguous and could mean a Doctrine entity manager, an admin CRUD layer, a job or workflow manager, or a file manager, each with very different integration costs.
- How do I install igdr/manager-bundle with Composer?
- There are no documented installation steps in the repository. For a Symfony project you would normally require the package and register the bundle in config/bundles.php, but that assumes a tagged release and known version constraints, neither of which is confirmed here. Before running composer require, check for a license file, a tagged release, and any commit activity in the last 12 months.
- Which Laravel and PHP versions does igdr/manager-bundle support?
- Unknown. The available metadata exposes no PHP or framework version constraints, and there is no Laravel support declared at all. Read the composer.json require block to see whether it targets symfony/* or illuminate/* packages. Confirm compatibility with your current Laravel and PHP baseline before any adoption decision, and pin to a specific commit SHA rather than a version range if you proceed.
- Is igdr/manager-bundle safe to use in production?
- The technical risk is high, concentrated in supply chain and abandonment. This is a 0-star, 0-dependent package from an unknown single vendor, effectively unreviewed third-party code, and installing it puts arbitrary PHP on the autoload path with full application privileges including database credentials and env access. There is no visible security disclosure process, no CVE history, and no community scrutiny that would surface a malicious or negligent release. The license is also unknown.
- Does igdr/manager-bundle have tests or CI?
- There is no evidence of test coverage or continuous integration in the repository metadata. The 0-star and 0-dependent counts mean no downstream compatibility validation exists either. Budget a timeboxed source read to assess quality, and assume you will need to write your own characterization tests if you vendor any of the logic.
- Who maintains igdr/manager-bundle and is it actively maintained?
- It is published by an unknown single vendor, igdr, with no visible identity or organizational backing and a composite score of 0.03. A package with zero adoption typically has zero maintenance budget, so the prior probability of abandonment is high. Check for commit activity in the last 12 months and whether any issues or pull requests have been answered before depending on it.
- What are the alternatives to igdr/manager-bundle for Laravel CRUD workflows?
- For Laravel, use packages built on Illuminate contracts such as dedicated action or repository patterns, or write thin service classes yourself. A manager layer that centralizes entity operations is small enough to build in-house in under a sprint for most domains. That removes the supply chain and abandonment risks entirely while giving you code your team actually understands.
- Should I fork or vendor igdr/manager-bundle into my own codebase?
- Prefer extract over depend. If a source read reveals genuinely useful domain logic, the cheaper and safer path is to vendor the relevant classes into your own namespace under an internal package, with the license verified and attribution preserved. A hard fork on your own GitHub org pinned to a specific commit SHA is the acceptable middle ground if the logic is large enough to justify it. Either route eliminates the abandonment and unreviewed-code risks while keeping the logic.