Symfony Playground Laravel Package

Getting Started

krak/symfony-playground is a skeleton/scaffold, not a library you install. Clone it the way you'd run laravel new scratchpad — a disposable Symfony app you paste code into and throw away. With 0 stars, 0 dependents, and a 0.1.3 tag that is a one-line patch on top of a mid-2020 codebase, treat the value as "the checkout plus whatever convenience it ships," and be ready to hand-edit composer.json for your PHP/Symfony versions.

Minimal steps:

1. git clone https://github.com/krakphp/symfony-playground.git scratch && cd scratch
2. Read composer.json first — it pins the Symfony version and PHP constraint. If it targets PHP 7.2/7.3 and you're on 8.x, bump the constraint or containerize before doing anything else.
3. composer install
4. Check .env / .env.dist for APP_ENV, APP_SECRET, DATABASE_URL; copy to .env if needed.
5. bin/console about to confirm the kernel boots, then bin/console list — this is where you look first. The package ships a playground console command; as of v0.1.3 it only registers itself when the playground file exists, so an empty list entry means "no playground file yet," not "broken install."
6. grep -rn "playground" src/Command/ to find the command class and see the exact path/name it probes for. Create that file, then run the command — that's your entry point, ahead of src/Controller/.

First use case for a Laravel developer: you're evaluating a Symfony bundle or reproducing a bug in Symfony-land code you're about to borrow. Clone, wire the bundle into config/bundles.php, drop the failing snippet into the playground file (not a controller — that's the path the package actually optimizes for), and run the command. Clean environment, no Laravel baggage, fast loop.

Mental-model mapping: routes/web.php → config/routes.yaml / controller attributes; artisan → bin/console; app/Providers → config/services.yaml autowiring; php artisan tinker → the playground command reading the playground file — that's the closest analogue and the reason this repo exists.

Implementation Patterns

Playground file as the scratch pad. The intended workflow as of v0.1.3 is: write your experiment into the playground file, run the command, read the output. Edit-and-rerun in one file beats adding a route + controller + template. Keep it under version control on a branch so you can diff experiments.

Don't fight the conditional registration. The command is deliberately absent when the file is missing. If you want it always available, create an empty/stub playground file at the expected path rather than editing the command class — otherwise your next git pull conflicts.

Scratch controller (for HTTP-shaped work). One PlaygroundController with a route per experiment, or a single /playground route you edit between runs. Use this when the thing under test needs a request/response cycle or middleware, which the console command can't give you.

Bundle evaluation harness. composer require vendor/bundle, add to config/bundles.php, drop minimal usage into the playground file or scratch controller. Highest-value pattern: it proves whether the bundle works without your Laravel app's baggage, and you can diff its behavior against your assumptions.

Vendor-bug reproduction. Copy the failing snippet in, strip it down until it either still fails (minimal repro for an upstream issue) or starts working (you've found what your real app does differently).

Throwaway branch per experiment. git checkout -b try-messenger keeps the sandbox usable. The moment it becomes "real" you've defeated the point.

Introspection over dd(). dump(), bin/console debug:container, debug:router, debug:event-dispatcher, debug:config <bundle> — the closest thing Symfony has to route:list, and the main reason a playground is worth having.

Integration tip: if you're porting behavior back to Laravel, test behavior (input → output, exception types, config semantics), not Symfony wiring. DI and event-dispatcher idioms won't transfer.

Gotchas and Tips

• Silent command absence. New in 0.1.3: the playground command is only registered when the playground file exists. If bin/console <cmd> reports "command not defined," check the file path the command class probes for before you start debugging the container — nothing is wrong with your install. Same trap if you rename or relocate the file: the command disappears with no warning.
• Don't composer require it into anything. It's an application skeleton; you'll pull in bin/console, public/index.php, and a conflicting symfony/framework-bundle constraint. Clone it, don't depend on it.
• Abandoned-adjacent. Last real work mid-2020; 0.1.3 is a guard clause, not a modernization. No security patches, no Symfony 6/7 compatibility work. Pin PHP or containerize, don't expose it publicly, don't let it become load-bearing.
• Check the pinned Symfony version before writing code. Attribute routing, AsCommand, messenger middlewares — many may not exist in what the skeleton pins. composer show symfony/framework-bundle first.
• Cache will bite you. After editing services.yaml, bundles.php, or routes: bin/console cache:clear. "Service not found" is usually stale container cache, not a wiring mistake.
• Environment split. Profiler/debug toolbar are APP_ENV=dev only; if dump() renders nothing, check you're not in prod. Never commit a real APP_SECRET.
• .env.local is the extension point, not .env — override DB creds and flags there, and in config/packages/*_local.yaml, so git pulls on the skeleton don't collide.
• Debugging pattern: debug:container <ServiceName> for autowiring failures, debug:router, debug:config <bundle> for config-key typos. These three resolve most of what you'd otherwise Google.
• Autowiring extension point: the standard App\ resource block in config/services.yaml (with _defaults: autowire: true) covers everything under src/, including your playground command — you rarely need explicit service definitions.
• The real cost is setup, not code. If your PHP fights the 2020-era composer.json, spend ten minutes bumping constraints; if it still fails, symfony new --webapp is a better playground for anything past Symfony 5. There's nothing here you can't reproduce with composer create-project — the one thing you'd lose is the playground-file convenience, which is ~20 lines to reimplement.