Dashed Forms Laravel Package

Getting Started

Because dashed/dashed-forms is an early-stage package (0 stars, 0 dependents, generic description), treat it as a read-the-source-first package rather than a drop-in dependency. Start by inspecting the repository before writing any application code.

1. Read these first

   • README.md for the intended API surface (likely thin or missing).
   • composer.json — check require.php, require.laravel/framework, and autoload.psr-4 to see which Laravel versions are supported and where the classes live (e.g. Dashed\Forms\).
   • src/ for the service provider, facade, and core form/field classes — this is your real documentation.
   • config/ — the config file often reveals the package's mental model (field types, view namespaces, validation rules).

2. Install and wire up

   composer require dashed/dashed-forms
   php artisan vendor:publish --provider="Dashed\Forms\FormsServiceProvider"
   

   Confirm the provider is auto-discovered (extra.laravel.providers in composer.json). If not, register it manually in bootstrap/providers.php (Laravel 11+) or config/app.php.

3. First use case: a single "contact us" form

   • Define one form with 3–4 scalar fields (text, email, textarea).
   • Render it in a Blade view via whatever render method the package exposes.
   • Handle the POST, run validation, and confirm the form re-renders with old input and errors.
   • This one flow exercises: field definition → rendering → request binding → validation → error state. If any of those four steps isn't covered by the package, you've found its real boundary early.

4. Pin the version. With a 2026-03-31 release date and no dependents, the API may still shift between minors. Use an explicit constraint (^x.y) rather than *.

Implementation Patterns

Form-as-class pattern. Most Laravel form packages expect you to define a form as a class (or an array/fluent builder) and let the package handle rendering and binding. Follow the package's idioms rather than wrapping your own abstraction around it on day one — you'll fight the package otherwise.

Keep validation in your FormRequest. Do not let the package own validation rules if it offers its own validation DSL. Laravel's FormRequest + $request->validated() is more testable, more familiar to your team, and survives a package swap. Use the package for definition and rendering, not for business rules. Bridge them:

public function store(ContactRequest $request, ContactForm $form)
{
    $form->handle($request->validated());
    return back()->with('status', 'sent');
}

Rendering in Blade. Expect a view namespace (check loadViewsFrom in the provider). Publish the views if you need to match your design system:

php artisan vendor:publish --tag=forms-views

If the markup is opinionated (Bootstrap/Tailwind), publishing and editing the views is usually faster than overriding field renderers.

Field composition. Reuse the package's field types before writing custom ones. For anything custom (e.g. a money field, a country select backed by your own data), look for a registration or macro hook in the service provider or a Field base class — extension is typically cheaper than forking.

Integration with Livewire / Inertia. If the package renders server-side Blade only, it composes fine with Livewire (drop the rendered form into a component) but is a poor fit for Inertia, which expects JSON props. Check for a toArray() / JsonResource path before committing.

Testing pattern. Assert on rendered output and on submitted payloads, not on internal package state:

$this->get('/contact')->assertSee('name="email"', false);
$this->post('/contact', [...])->assertSessionHasNoErrors();

Gotchas and Tips

• The description is a placeholder. "This is my package dashed-forms" suggests the README was never finished. Budget time for source-reading and expect undocumented behaviour. Open issues or PRs upstream rather than working around silently.
• Zero dependents is a real signal. You are the first serious integrator. There's no Stack Overflow corpus, no battle-tested edge cases. Add a thin application-level wrapper (your own Form base class or trait) so a future package swap touches one file, not fifty.
• Service provider discovery. If composer require succeeds but the facade/class isn't found, run composer dump-autoload and php artisan optimize:clear. Missing extra.laravel entry is the most common early-stage package bug.
• Publish-then-diff. Always run vendor:publish and diff the published config/views against the package originals. This tells you what's actually configurable versus hard-coded, and catches missing publish tags.
• Version drift risk. With very few releases, a composer update can break you. Lock the version in composer.lock (commit it) and add a composer test step in CI that runs your form tests before merging dependency bumps.
• Debugging render issues. When a field renders blank or malformed, drop to dd($form->fields()) (or the package's equivalent accessor) to confirm the definition reached the renderer — that separates definition bugs from view bugs.
• Extension points to look for: custom field registration, view namespace override, config-based rule injection, and event/macro hooks. If none exist, prefer wrapping the package behind your own interface over patching vendor/.
• License is MIT — safe to vendor-patch or fork if you need a fix urgently. If you do fork, maintain it under your org namespace (yourorg/dashed-forms) so Composer resolves it deterministically.