Form Laravel Package

Getting Started

Reality check before step one: this is a 0.0.1 "Init commit" release with zero stars, a 2022 date, and no verifiable public API. Treat everything below as a discovery plan, not usage instructions. Do not add it to an application you intend to keep.

1. Clone the repo, do not composer require it yet. Read composer.json first: check autoload.psr-4, extra.laravel.providers, PHP constraint, and whether a FormServiceProvider class actually exists in src/.
2. Spin up a throwaway Laravel app (composer create-project laravel/laravel sandbox) that matches your production major version. Add the package via a path or VCS repository entry, not Packagist.
3. Verify discovery. Run php artisan package:discover and inspect bootstrap/cache/packages.php. If the provider isn't registered, there's no extra.laravel block and integration is manual.
4. First use case to attempt: render a single <input> in a Blade view. Based on the description, this is likely something like {!! Form::text('name') !!} or a component tag — but you will have to read src/ to find the actual entry point, because it is not documented.
5. Stop there. If steps 1–4 fail, the package is scaffolding and the assessment is complete: recommend building your own form component or adopting a maintained package (spatie/laravel-html, Livewire's native form objects, or Blade components).

Implementation Patterns

Because the released tag contains no observable API surface, the patterns below describe what to design for if you proceed — mapped to the capabilities claimed in the description. Validate each against the source before writing code.

• Fluent field builder in a form class. The description promises chainable builders. The idiomatic Laravel shape is a form class with a fields() method returning builder instances, instantiated per request and rendered by a Blade component. If the package offers this, wrap it in your own App\Forms\* classes so a future replacement is a one-file change.
• Validation integration. Expect request()->validate() or a rules() method to be authoritative. Never let the package own validation rules — keep them in FormRequest subclasses so you retain control if the package is abandoned.
• Old-input handling. The description mentions old-input support. Confirm it reads old() from the session flash (standard) rather than a custom store; if it's custom, wire it into HandleInertiaRequests or your Blade middleware explicitly.
• Custom macros / extension points. If macros exist, register them in a dedicated service provider (FormMacrosServiceProvider) rather than AppServiceProvider, so macro surface is auditable and removable.
• Livewire context. The repo name says "Livewire," but Livewire wasn't a hard dependency as of 2022 in the way it is now. Check for livewire/livewire in require. If present, prefer native Livewire wire:model binding and treat the package as a view helper only.
• Publishable views and config. If vendor:publish tags exist, publish everything into resources/views/vendor/lariele-form/ and config/lariele-form.php immediately — this is your escape hatch if upstream vanishes.

Gotchas and Tips

• Version pinning is non-negotiable. "lariele/form": "0.0.1" exact, no caret. There is no 0.1.0 yet, so caret semantics on 0.x mean ^0.0.1 resolves only to 0.0.x — that's fine, but document it in your ADR.
• Package discovery is unconfirmed. If extra.laravel.providers is missing, you must manually register the provider in config/app.php. This is a signal the package was never wired for standard Laravel consumption.
• No compatibility matrix exists. Verify against your actual PHP version first — 2022-era packages frequently cap at PHP 8.1 and break on 8.3+ with deprecation errors in composer install (symfony/* constraints are the usual culprit).
• Blade escaping. Fluent form builders that echo HtmlString frequently skip escaping. Grep the source for {!! in published views and confirm e() is applied to user-supplied values before you trust it with model attributes.
• Extend via wrapper, not inheritance. Don't subclass package classes; wrap them in your own component that you can delete. Subclassing couples you to internals that may be rewritten in the next commit.
• Debugging: php artisan tinker → app()->getProvider(class_basename(YourPackageProvider::class)) tells you instantly whether the provider resolved. If null, discovery failed silently.
• Fork contingency now. Given zero stars and no release since 2022, assume upstream abandonment. git subtree or a GitLab mirror of the 0.0.1 tag should exist before any code depends on it.
• Do not use for auth or payment forms. No security disclosure process, no audit trail. User-facing forms with security implications (login, checkout) must use framework-native components.
• If you must adopt: gate on (a) a composer.json with extra.laravel, (b) at least one published view tag, (c) a smoke test rendering a text input with old-input round-trip. Missing any of the three → build a Blade component instead; it's ~40 lines and eliminates all of the above risk.