Staticfakedesign Laravel Package

Getting Started

Reality check first: despite being listed under a generic "package" heading, this is a Symfony bundle, not a Laravel package. There is no ServiceProvider, no config/staticfakedesign.php publish step, and no Illuminate integration. If you're a Laravel dev, treat it as a separate small Symfony app you run alongside your Laravel project (or as a source of ideas to port), not something you composer require into a Laravel app and expect to boot.

Minimal path if you're evaluating it:

1. composer require erdnaxelaweb/staticfakedesign in a Symfony 6/7 skeleton (or a standalone Symfony app in tools/design/).
2. Register the bundle in config/bundles.php.
3. Read the README in this order: Component Declaration → Fake Data Generation → Showroom — the showroom is useless until at least one component exists.
4. Declare one component (typed parameters, a Twig template) as a tagged service.
5. Boot the app and open the showroom route to see it rendered with generated data.

First real use case: you have a card/list/detail template but no backend yet. Declare the component, let the bundle fill its typed params with fake data, and screenshot the showroom for design sign-off. The second use case — and the more valuable one — is the static template rendering step: dump fully populated HTML pages so a client can click through a "demo" with no database behind it.

If you can't justify spinning up Symfony, stop here. Nothing in this bundle is worth fighting the framework boundary for on a single Laravel project.

Implementation Patterns

Component-first workflow. The unit of work is a component: a typed parameter set plus a Twig template. Declare it once, and you get three things for free — fake data, a showroom entry, and a static-render target. Build your UI as a library of these rather than as whole pages, then compose pages out of components.

Model the domain, not the markup. The bundle leans on value-object definitions (ContentDefinition, TaxonomyEntryDefinition, PagerDefinition, BlockDefinition, LayoutDefinition). This is the interesting bit: your fake data mirrors a CMS/content model, so a "block" fake knows it has a title, a body, an image, and a taxonomy term attached. If your real app has a content model, mirror it here — the generated HTML will look plausible instead of lorem-ipsum soup. If your app is a simple CRUD form, this machinery is overkill.

Showroom as a living style guide. Keep the showroom route dev-only (gate on kernel.environment === 'dev' or a dedicated firewall). Use it as the review surface for designers and PMs: every component variant rendered with realistic fake data, in one place. Treat adding a component to the showroom as part of "done" for that component.

Static render for handoff. The static rendering feature is where day-to-day value actually lives. Pattern:

• Define layouts that reference blocks, blocks that reference content.
• Generate a set of fake entities (5–10 articles, a couple of taxonomy terms, a paginated list).
• Render each template variant to /dist or /public/demo.
• Zip it and send it. No server, no DB, no credentials.

This is the pattern that replaces "can you just hardcode some content so we can show the client?"

Seed your fakes. Generate fake data from a fixed seed so re-renders are diffable. Designers will report "it looked different yesterday," and reproducible snapshots make component regressions visible.

Integration tip for Laravel teams: the pragmatic pattern is a tools/design sub-app in the same repo, with Twig templates symlinked or copied from resources/views. Your real Blade templates stay untouched; the design app is a throwaway proof-of-concept surface. Port learnings back by hand.

Gotchas and Tips

• Framework mismatch is the big one. Symfony's tagged-service discovery is doing the heavy lifting for component registration. Laravel's container won't find those tags. You'd be reimplementing the registry. Don't.
• One star, single maintainer, no dependents. Pin the exact version in composer.json, commit composer.lock, and assume you may need to fork. The "last release 2026-05-26" future date relative to any real evaluation is itself a signal to verify what you're actually pulling.
• Showroom in production. The showroom exposes rendered templates and generated data over HTTP. If the route isn't behind an env check, you've shipped a public demo endpoint. Add it to your deploy checklist.
• Stale component definitions. Symfony caches container/service metadata aggressively. After changing a component's typed parameters, bin/console cache:clear before concluding it's broken — this is the #1 "the bundle doesn't work" cause.
• Fake data that's too fake. Generated strings that violate your real constraints (title lengths, image aspect ratios, character sets with accents) produce designs that break the moment real data arrives. Constrain the fake providers to match production field limits — the bundle supports this, and it's the difference between a useful prototype and a misleading one.
• Asset paths in static renders. Rendered HTML written to disk often breaks on relative CSS/JS/image paths. Set the base URL explicitly and test the exported folder opened via file://, not just served by the dev server.
• Extension points worth knowing: custom fake-data providers (so fakes match your domain vocabulary), template overrides (keep design templates out of vendor/), and the value-object definitions themselves — subclassing a block/layout definition is the intended way to add domain-specific fields rather than cramming extra params into component signatures.
• Debugging tip: when a component renders blank or the showroom 500s, check the typed parameter definition first. Type mismatches between the declared parameter and the fake generator fail silently-ish in the rendered output far more often than with an explicit exception.