- How do I install yab/formmaker in Laravel?
- Run composer require yab/formmaker, let Laravel auto-discover the service provider, then publish the package config and migrations with the vendor:publish command. Run php artisan migrate so the form-definition tables exist, then generate form classes with the package's artisan command. The install itself is routine; the real gate is whether Composer resolves cleanly on your Laravel and PHP version.
- Which Laravel and PHP versions does yab/formmaker support?
- The last release was February 2022, which predates Laravel 10, Laravel 11, and PHP 8.2+. Documented support is effectively Laravel 8 and 9 on PHP 8.0 and 8.1, and nothing newer is proven. Treat newer versions as a spike: install on your target stack and read composer why-not output before committing.
- Is yab/formmaker still maintained?
- No, treat it as unmaintained. There have been no releases since February 2022, the repository has around 37 stars and zero public dependents, and there is no security response path. If you adopt it, plan to vendor or fork it and name an internal owner.
- What license does yab/formmaker use, and can I use it commercially?
- Composer reports NOASSERTION, meaning no recognized OSI license was detected. Commercial use, redistribution, and embedding in a shipped product are legal unknowns until the LICENSE file is read and, ideally, clarified in writing by the maintainer. Do not assume MIT just because the code is on GitHub.
- Is yab/formmaker production-ready for customer-facing forms?
- Only for a small, internal, non-regulated form surface such as back-office or ops data-entry screens. It is a poor fit for API-first services, SPA or headless front ends, multi-tenant products where form schema is customer-facing, or anything where form definitions must be portable. Put it behind an abstraction layer and keep it out of your primary customer intake path.
- Is yab/formmaker safe for user-defined form fields and HTML?
- Form definitions stored in package tables include labels, option lists, and possibly HTML fragments, which makes user-authored schema an XSS and mass-assignment surface. Audit the escaping and authorization model for who can create, edit, and render definitions. Do not assume the package sanitizes arbitrary HTML.
- Does yab/formmaker depend on laravelcollective/html?
- Very likely, given its generation and lineage; laravelcollective/html has been effectively unmaintained for years and is a known friction point on Laravel 9 and above. Inspect the resolved dependency tree with composer show or composer why and check each abandoned package. Transitive dependency rot usually breaks before the package itself does.
- How do I test forms built with yab/formmaker?
- Test through HTTP feature tests: hit the generated routes, post valid and invalid payloads, and assert validation errors and persistence rather than internal rendering details. The facade and convention-heavy field resolution are hard to unit test directly, so keep form classes thin and assert only the HTML fragments you actually depend on.
- How hard is it to migrate away from yab/formmaker?
- Harder than a code swap, because form definitions live in the package's own tables; exit requires a data migration to your own schema plus a rewrite of rendering and validation. Adopting it in a greenfield module behind an interface reduces the blast radius. Budget for that migration before you let the package own your primary form flow.
- Are there maintained alternatives or forks of yab/formmaker?
- There is no known maintained fork, so the realistic options are building a small in-house form-definition layer, choosing a currently maintained schema-driven form package, or vendoring this one and owning it. If you vendor, assign an owner, pin versions, and track Laravel upgrades yourself.