- Is lankerd/groundwork-bundle a Laravel package?
- No. It is a Symfony bundle, built around Symfony's Bundle class, DI Extension, compiler passes, and Resources/config service definitions loaded by the Symfony Kernel. Laravel has no bundle loader, and Laravel service providers are not drop-in equivalents. Realistic architectural fit for a Laravel codebase is near zero out of the box.
- Can I install Groundwork Bundle in a Laravel application?
- Composer installation is unlikely to be clean, because a 2019 Symfony bundle will almost certainly conflict on symfony/* and php constraints. Running with --ignore-platform-reqs is a non-starter for production. Even if files land in vendor, Laravel has no bundles.php registration path and no service provider auto-discovery for it, so nothing boots. Treat it as a reference implementation to read, not a dependency to install.
- What PHP and Laravel versions does Groundwork Bundle support?
- The last release was 2019-11-18, roughly six years stale and well past every modern PHP support window. It almost certainly declares PHP ^7.x constraints, while Laravel 10 and 11 require PHP 8.1 or newer. Verify the composer.json require block against your PHP version and Laravel's dependency graph before writing any code. A fork is likely required just to install it.
- Is Groundwork Bundle's GPL-3.0 license safe for a commercial Laravel SaaS?
- GPL-3.0 is copyleft, so this is a legal gate rather than an engineering detail. For internal-only or SaaS deployment where no binary is distributed, it is generally survivable. For a distributed, on-prem, or SDK-embedded product, GPL obligations would extend to your own codebase. Legal review should precede any engineering spike, and you should ask the author about a non-GPL relicense.
- How do I install lankerd/groundwork-bundle with Composer?
- The conventional command is composer require lankerd/groundwork-bundle, but installation alone does not make it work in Laravel. As a Symfony bundle it depends on Symfony kernel bootstrapping, DI extension loading, and compiler passes that Laravel never invokes. Without a documented Laravel adapter or service provider, Composer installation gives you vendor files and no integration. That is why the default recommendation is not to install it in a Laravel app.
- Is Groundwork Bundle still maintained?
- There is no meaningful maintenance signal. The last release was in November 2019, the repository has about two stars and zero dependents, and the bus factor is one. There is no CVE watch, no downstream users surfacing bugs, and no guarantee of maintainer response. Pinning it also pulls unmaintained transitive dependencies into your lockfile.
- How is Groundwork Bundle configured inside Laravel?
- It is not, without custom bridging work. The package assumes Symfony's DI container semantics such as tagged services, compiler passes, and autowiring by service id, plus the Config component's semantic config tree. Laravel resolves primarily by type-hint, uses a flat config repository, and dispatches through its own event system. None of that bridges for free, and there is no documented Laravel configuration path.
- Should I run Symfony alongside Laravel to use Groundwork Bundle?
- That is technically possible through a bridge package, but it is not recommended. It doubles container boot, creates two configuration systems, and produces a debugging surface that no one on the team will own. For a Laravel application, the cost almost always exceeds the value of an undocumented six-year-old bundle. Prefer a Laravel-native package or in-house code instead.
- Are there Laravel-native alternatives to Groundwork Bundle?
- The first discovery task is to determine what Groundwork actually provides, because the package description gives no functional signal. If the capability is commodity, a maintained Laravel-native package or 100 to 200 lines of in-house code is almost certainly cheaper than a permanent fork. If any logic is genuinely framework-agnostic, extract that only. Do not adopt the Symfony wiring as a dependency.
- How do I fork or migrate away from Groundwork Bundle?
- The preferred path, if the capability is valuable, is to copy only the framework-agnostic portions into App\Support, replace Symfony DI and config with a Laravel service provider and config/*.php, and rewrite event usage against Laravel's dispatcher. Track the origin commit and preserve the license header, and confirm PSR-4 autoloading plus PSR-3 and PSR-11 usage before copying. If the capability is a commodity, reject the package and reimplement cleanly instead.