- Can I install landingi/modular-monolith-bundle in a Laravel application?
- No. Despite often being described as a Laravel/PHP package, landingi/modular-monolith-bundle is a Symfony bundle: it is registered through bundles.php and hooks into the Symfony container and compiler-pass lifecycle. A Laravel application cannot install or boot it. Laravel teams can only read it as a reference for modular monolith pattern ideas.
- What Symfony and PHP versions does landingi/modular-monolith-bundle support?
- The package has a single release dated 2021-05-18, so assume a Symfony 4.4/5.x and PHP 7.4/8.0 vintage until proven otherwise. Check the composer.json constraints for symfony/* and php before planning anything. There is no visible PHP 8.2/8.3 or Symfony 6/7 compatibility work. On a modern Symfony 6.4/7.x platform, treat it as non-installable without a fork.
- How do I install landingi/modular-monolith-bundle with Composer?
- Installation is only relevant for Symfony applications: require the package with Composer and register the bundle in bundles.php. There is no Laravel service provider or package discovery support. Because the package is stale and has zero dependents, spike it in a throwaway Symfony app first and confirm the version matrix before adding it to a real deployment path.
- Is landingi/modular-monolith-bundle maintained and safe for production?
- The signals are poor: zero stars, zero dependents, one release in 2021, and no visible community or maintainer activity. It has been unmaintained for roughly four years, with no security response path and no deprecation fixes. Because bundles that own compiler passes and service wiring can break loudly at build time, a failed cache clear could block every deploy. Direct dependency in production is not recommended.
- What does a modular monolith bundle actually do for module boundaries?
- The concept is sound: organize application code into self-contained modules inside a single deployable codebase, with conventions for module registration, service wiring, and an internal contract or event layer between modules. The real value is codifying boundaries so they do not erode under delivery pressure, without taking on distributed-system complexity. What this specific bundle implements beyond structure and conventions needs verification in the source.
- Does landingi/modular-monolith-bundle enforce module boundaries or just suggest them?
- This is the key unknown. The available context does not document whether the bundle fails the build on a forbidden cross-module reference or merely encourages boundaries through conventions and autowiring. Inspect the compiler passes and module registry to find out. If it actively enforces boundaries, the value proposition is much stronger; if it only suggests them, it is mostly a naming convention.
- How are cross-module dependencies handled in landingi/modular-monolith-bundle?
- The repository does not document this clearly. Possible approaches include synchronous service injection, an in-process command/query bus, or domain events between modules. Read the module descriptor format and service wiring code before assuming decoupling. The choice matters because synchronous injection creates runtime coupling even when directories look separate.
- Is landingi/modular-monolith-bundle coupled to Doctrine or a specific directory structure?
- Expect conventions tuned to Landingi's own layout and naming, and possible coupling to Doctrine or an internal module descriptor format. The package appears to be an internal extraction published for convenience rather than a supported open-source product. Verify composer.json and source for hard dependencies before evaluating portability. This coupling is a major reason to adopt the pattern rather than the code.
- Can I generate a module dependency diagram or CI check from landingi/modular-monolith-bundle?
- There is no evidence that the bundle exposes an introspectable module graph. If its compiler passes already validate cross-module references, a CI check might be derivable, but that is not documented. For a Laravel codebase, build an in-house module registry plus a static-analysis check using tools such as Deptrac or PHPArkitect instead. That gives you a dependency diagram and CI enforcement on your own terms.
- What are alternatives to landingi/modular-monolith-bundle for Laravel modular monoliths?
- Laravel has no direct equivalent, so pattern adoption is the pragmatic route. Use nwidart/laravel-modules for module structure if it fits your conventions, and add in-house boundary checks or Deptrac/PHPArkitect rules for dependency enforcement. The recommended approach is to extract the module-descriptor idea and implement a small registry plus boundary validation yourself. Forking the Symfony bundle is only viable if a spike shows it does something non-trivial you cannot reproduce.