Guide Bundle Laravel Package

Getting Started

This package ships with essentially no documentation — the README is a single heading — so treat the source as the spec. Before anything else, read composer.json to see the PHP constraint, the Symfony version it targets, and the autoload roots; that tells you within thirty seconds whether it is even installable in your app.

1. composer require endroid/guide-bundle in a scratch project first, not in your main application.
2. Inspect the tree: src/, DependencyInjection/, Resources/config/ (or config/), and any tests/. A *Bundle.php class at the root is the confirmation that this is a Symfony bundle, not a Laravel package.
3. If a test suite exists, run it immediately: vendor/bin/phpunit. Green tests are your only reliable description of intended behaviour.
4. Grep for the public surface: grep -rn "public function" src/ and grep -rn "tag(" src/ DependencyInjection/ to see which services are exposed and which are tagged for collection.

The first realistic use case is a spike, not a feature: register the bundle in a throwaway Symfony config/bundles.php, boot a kernel, and confirm there is actually a service worth consuming. If the bundle only registers an event subscriber or a Twig namespace, that tells you whether porting the idea to Laravel is a 20-line job or a rewrite.

Implementation Patterns

Because the repository is archived, empty-README, and has zero dependents, the sane pattern is read-and-reimplement, not composer require. Everything below assumes you are evaluating whether the behaviour is worth borrowing.

Port the concept, not the package. A Symfony bundle's value usually lives in two places: a service that holds logic, and a compiler pass or tag that wires it. Copy the service class into app/Support/ (or a small first-party package under packages/), replace constructor-injected Symfony services with Laravel equivalents (Illuminate\Contracts\Cache, Illuminate\Contracts\Events\Dispatcher, Illuminate\Contracts\Config\Repository), and drop the DependencyInjection/ directory entirely.

If you genuinely need to run the bundle as-is, bridge it rather than reimplement it. Create a Laravel service provider that instantiates the Symfony kernel services manually:

public function register(): void
{
    $this->app->singleton(SomeGuideService::class, function ($app) {
        return new SomeGuideService(
            $app->make('config')->get('guide'),
        );
    });
}

This only works if the bundle's services have no hard dependency on Symfony\Component\HttpKernel\KernelInterface or the container itself — check the constructor signatures before committing.

Integration tips when consuming the behaviour:

• Route/controller code in a Symfony bundle translates almost one-to-one to routes/web.php plus an invokable controller.
• Twig templates become Blade views; any {% include %} graph is usually the most time-consuming part to port.
• Asset paths under Resources/public/ need php artisan vendor:publish in Laravel, whereas Symfony uses assets:install. If the bundle references assets by container path, rewrite them to public_path() / asset().
• Config defaults: Symfony bundles hide defaults in DependencyInjection/Configuration.php. That file is the closest thing to documentation you will find — read it before guessing.

Workflow pattern for a first real feature: wire one end-to-end path in a branch (config → service → controller → view), write a feature test that hits the route, and only then decide whether to keep the fork. Without an upstream maintainer, your test suite becomes the package's contract.

Gotchas and Tips

• It is archived. No security fixes, no PHP 8.x/9.x compatibility patches. Pin your fork and treat it as vendored code you now own. If you must keep it in composer.json, point at a VCS repository you control, never at the abandoned original.
• Zero dependents means zero field-testing. You are the first person to hit the edge cases. Budget more time than the LOC suggests.
• Symfony bundle ≠ Laravel package. There is no service provider, no config/*.php to publish, no php artisan surface. Attempting composer require into a Laravel app and expecting it to do anything is the classic mistake here.
• Empty README = no BC promise. There may be no public API at all; everything can be @internal. Assume any class you touch may change shape in a fork you have not yet made.
• Container compilation is where it breaks. Symfony bundles fail at cache:clear, not at request time. If you bridge it, use bin/console debug:container <service> and debug:router in a Symfony harness to see what the bundle actually registers before writing Laravel glue.
• Debugging the source: grep for getDefinition, addTag, and Extension::load. Those three call sites describe 90% of what a bundle does. Start there rather than reading files alphabetically.
• Extension points are probably Symfony-specific — tagged service iterators, event subscribers on kernel.* events. Those do not exist in Laravel; expect the extension story to be "fork it."
• Check the license header per file, not just the repo. MIT on a 0-star archived repo is fine legally, but files copied from elsewhere sometimes carry a different header.
• Recommendation: the opportunity score (0.27) and empty README suggest there is a small, useful idea here with no packaging around it. Spend an hour reading src/; if the idea is good, spend two hours reimplementing it in Laravel and delete the dependency. Do not put this in a production composer.json.