- Is doyo/modular-bundle a Laravel package?
- No. Despite Laravel-oriented marketing language, the package identifies itself as a Symfony Modular Bundle, and bundles are a Symfony kernel concept (a Bundle subclass, a DependencyInjection Extension, and registration in bundles.php). Laravel has no equivalent primitive — modularity there is expressed through Composer packages, service providers, and PSR-4 autoloaded namespaces. Treating it as a Laravel dependency is a category error rather than a versioning problem. If you need Laravel modularity, look at nwidart/laravel-modules or plain Composer path repositories.
- How do I install doyo/modular-bundle in a Laravel application?
- It is Composer-installable in principle via composer require doyo/modular-bundle, but there is no field-tested install path, no dependents, and no known-good constraint set to copy from. Bundle semantics do not map onto Laravel's service container or package discovery, so the install would be followed by manual glue code with no upstream precedent. The defensible outcome of a Laravel spike here is a documented rejection rather than a scheduled integration.
- Which Laravel and PHP versions does modular-bundle support?
- That is not established by the available information. You would need to read composer.json for require constraints on php, symfony/framework-bundle, and any Laravel components, plus confirm PSR-4 autoload correctness and the presence of a CI matrix. There is no visible test suite or version matrix proving support for any framework major. If the constraints do not cover your current minor and the next major you plan to adopt, that is a hard stop regardless of feature fit.
- What is the difference between a Symfony bundle and a Laravel module?
- A Symfony bundle hooks into the kernel: it is a Bundle subclass registered in bundles.php, ships a DependencyInjection Extension, and often touches container compilation and boot. A Laravel module is simply a Composer package with its own namespace, service provider, routes, views, and migrations. The two are not interchangeable abstractions, and a bundle's kernel-level reach is exactly the area that changes most across Symfony majors.
- What are the Laravel alternatives to doyo/modular-bundle for splitting an app into modules?
- The most common choice is nwidart/laravel-modules if you genuinely want a module scaffold with generated structure. The lighter and often better option is Composer path repositories with one package per module, each exposing its own service provider, routes, views, and migrations. Both stay inside first-party Laravel conventions, which means no third party owns your module discovery.
- Is doyo/modular-bundle safe to use in production?
- The risk profile is high: a single maintainer, zero stars, zero dependents, and no downstream bug reports to learn from. An unfamiliar vendor namespace publishing a framework-internals package warrants a source audit and a check of who actually controls the Packagist entry. If you proceed anyway, pin to an exact version and record an internal owner so the dependency does not become an upgrade blocker later.
- Why is the Composer vendor doyo/ when the GitHub repository is kilip/modular-bundle?
- The mismatch suggests a fork, a re-publish under a new namespace, or a repository transfer. That matters because the vendor name is what ends up in your lockfile and your supply-chain trust boundary. Trace the provenance and confirm maintainer identity and Packagist ownership before the package name is trusted in any dependency manifest.
- Can I use doyo/modular-bundle in a Symfony application instead of Laravel?
- Possibly, but it is a conditional fit that must be re-scoped against native Symfony bundle conventions and Symfony Flex recipes first. Benchmark what the bundle enforces against what a first-party bundle structure gives you for free, because adopting a third-party abstraction to own module discovery is a long-term commitment. If you proceed, do it as an isolated spike: one non-critical module, one branch, no production coupling, and explicit exit criteria.
- Is doyo/modular-bundle actively maintained?
- There are no visible adoption or validation signals: no stars, no dependents, and no evidence of a test suite or CI matrix in the material available. That is the classic profile of a dependency that quietly becomes an upgrade blocker 18 months after adoption. The framework coupling risk is also real, since bundles tend to reach into container compilation and kernel boot.
- How should I test or evaluate modular-bundle before committing to it?
- Start by confirming your target framework, since that single answer determines whether the rest of the evaluation matters at all. Then do a provenance and source audit, followed by a one-engineer-day compatibility read of composer.json and any test suite. If and only if the target is Symfony, run a two-to-three-day sandbox spike on a single non-critical module, keep your module contracts and interfaces in application code so removal is a deletion rather than a rewrite, and close with a written decision record.