- Can I use gnugat/pomm-foundation-bundle in a Laravel application?
- Not natively. The package is a Symfony bundle: a Bundle subclass plus a DependencyInjection extension reading YAML under a pomm: key, with no Illuminate Support ServiceProvider, no facade, no config publisher, and no config/*.php contract. To use it in Laravel you would have to boot Symfony's DI and HttpKernel machinery inside the app purely to register it. The defensible path is to skip the bundle and hand-wire the Pomm class from pomm-project/foundation yourself.
- Does gnugat/pomm-foundation-bundle support Laravel 10 or Laravel 11?
- Nothing in the package targets Laravel versions. v0.7.0 raised the PHP floor to 8.0 and the Symfony constraints to 6, which probably clears Composer resolution on a Laravel 9, 10, or 11 runtime, but that is probable rather than confirmed. The exact constraint ranges and the pinned pomm-project/foundation version are not in the release notes, so read composer.json directly before assuming.
- How do I install gnugat/pomm-foundation-bundle in a Laravel project?
- You would run composer require gnugat/pomm-foundation-bundle, but that is only half the story: Symfony bundles are registered in the kernel bundles list, and Laravel has no equivalent step. There is no package discovery, no artisan vendor:publish, and no config stub shipped for Laravel. Installation only makes sense if you actually intend to boot a Symfony container alongside your Laravel app.
- What changed in v0.7.0 and what are its requirements?
- v0.7.0 is a dependency-constraint bump only: PHP minimum raised to 8.0 and Symfony constraints raised to 6. No packaging or API changes accompany it, so the integration story is identical to earlier releases. Note that PHP 8.0 reached end of life in late 2023, so the 8.0 floor signals install flexibility rather than maintenance discipline. Verify the CI matrix actually exercises PHP 8.3 and 8.4, and check whether the Symfony constraint is a wide ^6.0 that also permits EOL 6.0 to 6.2.
- Do I need this bundle to use Pomm, or can I just use pomm-project/foundation?
- You do not need it. The real dependency is pomm-project/foundation, which owns the session pools, ModelManager registry, entities, and Where DSL. This repository is only a Symfony configuration layer, so as a Laravel dependency it contributes nothing at runtime. Treat it as a configuration reference and depend on the foundation package, ideally bound as a singleton in a service provider you write.
- Is gnugat/pomm-foundation-bundle actively maintained?
- One release after a multi-year gap is a data point, not a cadence. The previous release was 2022-02-28, and v0.7.0 added no dependents, so there is still no troubleshooting corpus, patch pipeline, or second maintainer, and the bus factor remains one. Treat the status as uncertain rather than healthy, and do not let a single compatibility bump be read internally as actively maintained.
- What are the alternatives to Pomm for PostgreSQL in Laravel?
- For most Laravel applications, Eloquent or the query builder against PostgreSQL already covers the workload, with raw expressions or small extensions handling jsonb, arrays, hstore, and RETURNING clauses. If you genuinely need Pomm's PostgreSQL-native feature set, the realistic option is pomm-project/foundation wired directly, not this bundle. Weigh that against the cost of running a second, non-Laravel data layer your team must maintain separately.
- Can I use Eloquent, relationships, or RefreshDatabase alongside Pomm?
- No. Pomm is a PostgreSQL-only object mapper with its own conventions: session pools, a ModelManager registry, flexible entities without an identity map or lazy loading, and a bespoke Where DSL. None of Laravel's data layer carries over, which means no Eloquent relationships, no DB transaction hooks, no query event listeners, no RefreshDatabase, and no Telescope or Pulse instrumentation. Budget for a full data-layer rewrite rather than a swap.
- What technical risks should I expect in production?
- Technical risk is high, even though the dependency-resolution component is now downgraded. The install step probably clears Composer on current Laravel runtimes, but everything downstream is unchanged: a full data-layer rewrite, effectively zero ecosystem signal, one maintainer, and unverified health of pomm-project/foundation where queries actually execute. This repo's version bump says nothing about that project's release activity, security posture, or composer audit coverage.
- What should I verify before spending engineering time on this package?
- First confirm the target application is actually Laravel and not PHP app in disguise; if a meaningful share of the backend is Symfony, the evaluation flips toward plausible, and v0.7.0 is exactly the release that makes the Symfony branch viable again. Then check whether you truly need Pomm's PostgreSQL-native access such as arrays, hstore, jsonb operators, RETURNING, or custom types, or whether Laravel's own query builder covers it. Finally read composer.json for the real constraint ranges and the pinned foundation version before committing.