- Is php-tui/cassowary a Laravel package?
- No. It is a framework-agnostic userland PHP port of the Cassowary constraint solver, with no Laravel service provider, config file, facade, or published Laravel version constraints. You can still install it with Composer in a Laravel application and wrap it in your own binding if you need container access. Treat it as a layout-layer library, not Laravel infrastructure.
- How do I install php-tui/cassowary in a Laravel app?
- Install it with Composer using the package name php-tui/cassowary, then instantiate its Solver, Variable, Constraint, Expression, and Strength classes directly. There is no auto-discovery or configuration step because it is not a Laravel package. Before adopting, confirm the current version and repository metadata, since the available assessment flags missing metadata and weak release signals.
- What Laravel and PHP versions does php-tui/cassowary support?
- The package publishes no Laravel version constraints because it is not Laravel-specific, so compatibility depends on your app's PHP version and Composer resolution. The minimum PHP version, changelog, and whether it is pre-1.0 are not confirmed in the provided context. Inspect composer.json and test numeric behavior on your target PHP runtime before committing.
- What can I use php-tui/cassowary for in Laravel?
- Use it where declarative geometry helps: TUI dashboards, dynamically sized console reports, PDF or HTML grid generation, form layout engines, and chart axis arrangement. It fits presentation and layout code, not request validation, queue workers, or domain business logic. It is especially relevant if you are already building terminal interfaces with PHP-TUI.
- How does php-tui/cassowary handle constraint priorities and strengths?
- The package exposes Variable, Constraint, Expression, Strength, and Solver primitives, and the overview states that you can add and remove linear equality and inequality constraints with priorities. Required, strong, medium, and weak strength behavior should be verified empirically against the reference Cassowary implementation, because ports often diverge in priority ordering and floating-point tolerance. Unsatisfiable systems are expected to surface as UnsatisfiableConstraintException, so plan error handling around that.
- Is php-tui/cassowary fast enough for per-frame terminal layouts?
- Cassowary is CPU-bound, and this userland PHP implementation is likely slower than a native Kiwi binding or an FFI wrapper. A static layout solved once is feasible; re-solving every frame at 30 to 60 FPS in a terminal loop is risky. Benchmark solve time for 50, 200, and 1,000 constraints plus incremental updates on a realistic layout before production use.
- Does php-tui/cassowary support incremental solve or edit variables?
- The provided assessment does not confirm whether it implements edit variables and incremental re-solve via addEditVariable and suggestValue, or only full solve. That distinction materially changes the performance ceiling for interactive layouts. Inspect the API and test repeated updates before assuming incremental behavior.
- How should I integrate php-tui/cassowary without coupling my Laravel app to it?
- Keep the dependency out of your domain layer by defining an internal LayoutSolver interface you own, with one implementation for your existing imperative layout code and one backed by php-tui/cassowary. Bind it as a singleton in Laravel if needed, ship it behind a feature flag, and diff rendered output against golden fixtures before cutover. The interface also gives you an exit ramp to a native Kiwi binding or FFI wrapper if PHP throughput disappoints.
- How do I test php-tui/cassowary layouts in Laravel?
- Test it with golden layout fixtures that compare solver output against known-good widget sizes and positions, and add cases for under-constrained systems, priority ordering, floating-point tolerance, and unsatisfiable constraints. The package's own test suite presence and coverage are not confirmed, so you should not rely on upstream tests alone. Also benchmark realistic constraint counts in your CI or a dedicated performance check.
- Is php-tui/cassowary production-ready, and what alternatives should I consider?
- Adoption signals are weak: roughly 20 stars, missing repository metadata, no meaningful community corpus, and a likely single-maintainer bus factor under the php-tui org. Treat every behavior as unvalidated until you test it, and avoid ripping out existing layout logic. If throughput or maintenance becomes a problem, alternatives include keeping imperative layout arithmetic, using a native Kiwi binding, or building an FFI wrapper behind the same LayoutSolver interface.