Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Hello Bundle Laravel Package

liip/hello-bundle

LiipHelloBundle is a small Symfony bundle providing a simple Hello World example with controller, routing, and template setup. It serves as a lightweight reference for learning Symfony bundle structure or testing basic app integration.

View on GitHub
Deep Wiki
Context7

Getting Started

Day-to-day, this package never enters a Laravel dependency manifest. It's an archived, self-declared [DEPRECATED] Symfony 2 reference application ("alternative Hello World" wiring FOSUserBundle, FOSRestBundle, Doctrine extensions, and a JS front end), and Composer will not resolve it against a modern Laravel app. Treat it as read-only documentation of a pre-Flex Symfony pattern — the value is in translating what it does into Laravel idioms, not installing it.

Minimal steps:

  1. git clone https://github.com/liip/LiipHelloBundle into a scratch directory. Do not composer require it — pinning is Symfony 2.x / PHP 5.x-era and will conflict on symfony/*, Doctrine, and every abandoned FOS package.
  2. Read composer.json first. It is your compatibility map: it tells you which API era each pattern belongs to (FOSRestBundle 1.x annotations, FOSUserBundle 1.x, Assetic, Bower assets).
  3. Read app/config/config.yml and app/config/security.yml next. This is where most of the reusable knowledge lives: bundle registration order, REST format/view listener rules, firewall and provider wiring, Doctrine extension listeners.
  4. Pick one vertical slice — the Hello controller + entity + routing + template — and read it end to end before generalizing.

First use case for a Laravel developer: you've inherited a legacy Symfony 2.8/3.x service, or you're porting one, and need a working example of a REST endpoint behind a stateless API firewall, alongside a session-based login — then map that straight onto a Laravel route group + Sanctum/Passport setup. Budget under an hour to skim; under a day if you actually port a pattern.

Implementation Patterns

The useful workflow is a concept translation pass, not a code copy. Read a slice in Symfony, write the Laravel equivalent from scratch, and keep the repo only as a checklist of concerns you might otherwise forget.

  • Bundle + DI extension → Service provider. The bundle's Extension::load() with XML/YAML service definitions maps to register()/boot() in a service provider. Where Symfony autowires by FQCN and tags services, Laravel binds interfaces in the container and uses tagged()/when() for context-specific implementations. Copy the set of bindings, not the XML.
  • Kernel event listeners → middleware or event listeners. Symfony's kernel.request / kernel.response listeners have direct Laravel analogs in HTTP middleware (per-request, ordered) and framework events like RequestHandled. Prefer middleware for anything touching the response; use listeners for cross-cutting side effects.
  • Dual firewall (form_login + stateless api) is the single most-copied idea. In Laravel this becomes two route groups: web middleware with session auth for humans, and a routes/api.php group with auth:sanctum and no session/CSRF. The access_control ordering that keeps /api out of the session firewall maps to middleware group assignment and route ordering — define the stateless group before any catch-all.
  • fos_rest.format_listener.rules → route-group defaults or middleware. If /api/* must default to JSON while the site stays HTML, do it with Route::prefix('api')->middleware('force.json') (or a group-level ->defaults('_format', 'json')), not with per-controller checks.
  • @View(serializationGroups=...) → API Resources. JMSSerializer groups exist to control field exposure. In Laravel, JsonResource with explicit toArray() is the direct equivalent and is where you enforce "never leak the user entity." Do not serialize Eloquent models raw.
  • Gedmo Translatable + companion translation entity → spatie/laravel-translatable (JSON column) or a translation-model package if you need per-locale rows and fallback. The reusable part is the config: locale provider + fallback behavior. The entity structure, copy only if you're deliberately mirroring the schema.
  • Fixtures + Behat/Mink scenarios → factories, seeders, Pest/PHPUnit feature tests. Keep the scenarios as executable documentation of expected request/response shapes; port the intent, not the Gherkin.
  • FOSJsRoutingBundle Routing.generate() → Ziggy. Only relevant if you still render server routes into JS; on an Inertia/Livewire stack, this concern disappears.
  • Annotation-routed controllers → invokable or resource controllers. The demo mixes annotation and YAML routing to show both; in Laravel, pick route-file style consistently and don't re-create annotation-based routing.

If a pattern is genuinely needed across projects, publish it as an internal Composer package under your own namespace where you control lifecycle — do not vendor this repo.

Gotchas and Tips

  • Archived + deprecated by name. No security fixes, no PHP 8, no Composer 2 hygiene, Symfony 2 is EOL. Any composer require attempt ends in resolution failure or, worse, a forced install that drags in abandoned transitive packages and fatals on kernel/bundle classes. This is a hard no as a dependency.
  • Don't port Symfony idioms 1:1. Recreating bundles, XML service definitions, or annotation routing inside Laravel fights the framework. Translate the concern (auth boundary, format negotiation, translation fallback) into the native primitive.
  • API drift if you do copy syntax. FOSRestBundle changed @View semantics and the view_handler service between 1.x and 2.x; composer install --ignore-platform-reqs succeeds only to fail at runtime. Verify any snippet against the version you're actually targeting — or just don't copy syntax at all.
  • Ordering is load-bearing in both frameworks. In Symfony it's bundle registration + firewall order; in Laravel it's provider registration, middleware priority ($middlewarePriority), and route order. If the legacy app "works by accident," figure out why before translating — the ordering constraint is the thing you're porting.
  • Extension points to reuse: treat the repo's config.yml fragment list as a checklist — REST format rules, firewall/provider wiring, Doctrine listener registration, exposed routes. Each one has a Laravel counterpart; none requires the package.
  • Debugging legacy boot failures: the failure sequence is almost always resolution error → class-not-found on Symfony kernel classes → container compile error. If you only need a shape example, read the controller and config; don't try to boot the app.
  • Replacement references: symfony/demo or symfony/maker-bundle for a modern Symfony starting point; Laravel Breeze/Jetstream for auth scaffolding; API Platform or Laravel API Resources for REST. Use this repo only as historical context and a worked example of what the "assemble many small bundles" era looked like — and why Flex-style recipes replaced it.
  • Dependency hygiene: if it (or its FOS-era siblings) already exists in a tree you own, flag it for removal and record the rationale; use it as the canonical example for an "archived / EOL-framework / zero-dependents" intake tripwire.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
uni-method/symfony-lib
tacticmedia/scim-server-bundle
neika-ai/symfony-bundle
mattleads/agent-publishing-bundle
glavweb/framework-bundle
glavweb/extra-bundle
glavweb/api-bundle
glavweb/admin-bundle
adachsoft/api-version-bundle
elsayed85/laravel-api-exceptions
ouhssini/laravel-demo-mode
daworks/ncloud-outbound-mailer-driver
gp247/cms
ignibyte/aic-gates
nexa-merchant/blog
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
cgv/localized-resource