Symfony Bundle Skeleton Laravel Package

Getting Started

This is not a Laravel package. It is a Symfony bundle skeleton — a composer create-project template for scaffolding a distributable Symfony bundle. For a Laravel codebase there is nothing to composer require, no service provider to register, and no Artisan command to publish. Treat this assessment as "relevant only if you maintain code that must run inside Symfony."

Minimal steps if you do have a Symfony use case:

composer create-project tito10047/symfony-bundle-skeleton my-bundle

1. Run the command in an empty, dedicated directory — create-project scaffolds a project, it does not install into an existing app.
2. Read the generated composer.json first. Confirm the name (vendor/my-bundle), type, autoload PSR-4 map, and the require/require-dev split before writing any code. The namespace baked into the skeleton is what every generated class and the DI extension reference, so renaming later is a find-and-replace across src/, tests/, config/, and composer.json — cheaper to fix now.
3. Walk src/ and the bundle class, then src/DependencyInjection/ (the extension + Configuration pair) and config/services.yaml. That trio is where Symfony bundle behaviour actually lives, and it maps to nothing in Laravel.
4. Confirm your local PHP satisfies the framework constraint. The skeleton targets Symfony 7.4 LTS and 8.1; those lines have different PHP floors, so check composer.json's php constraint rather than assuming.
5. First real use case: a bundle you intend to publish to Packagist or require from several Symfony apps via a VCS/path repository — shared clients, shared domain services, or an integration with a third-party API you want versioned independently.

Verify before trusting the scaffold: the branch/tag actually generated, the maker version resolved, and that composer install && composer test is green in the fresh directory.

Implementation Patterns

One-time scaffold, not a runtime dependency. The generated bundle is a standalone repo you own and commit. tito10047/symfony-bundle-maker is a dev-time generator referenced as ^1.0; it belongs in require-dev (or is invoked via a Composer script), never in a consumer's require. Pin it, since ^1.0 on a freshly stabilised package means minor-version churn is permitted.

Template-repo pattern. Because the skeleton is derived from yceruto/bundle-skeleton, the most reliable workflow is: generate once, push to your own VCS, then use that repo as the template for future bundles rather than re-running create-project against an upstream you don't control. You keep the namespace rename and CI config as your opinionated baseline, and you're insulated from upstream changes.

Symfony/Laravel mental translation. If you're a Laravel developer reading Symfony bundle code, map it deliberately:

Write bundle config in the Configuration tree, not with ad-hoc env() reads — the tree is what gives consumers validation, defaults, and IDE-friendly docs.

Integration tips.

• Consume the bundle from a host app using a path repository during development ("repositories": [{"type": "path", "url": "../my-bundle"}]) so you iterate without tagging.
• Tag semver releases for consumers; dev-main plus a path repo is a local-only convenience.
• Keep tests/ self-contained. A bundle that needs a full host app to test is hard to maintain; the skeleton's test harness exists precisely to avoid that.
• Wire CI (matrix across the Symfony versions and PHP versions you claim in composer.json) before the first tag. The support claim in the release notes is only real if CI exercises it.

If you're bridging into Laravel. A Symfony bundle cannot be dropped into Laravel. Reusing the domain/services layer means wrapping it in a Laravel package with its own service provider and config file, and making sure the bundle's Symfony-specific bootstrapping (extension, compiler passes, tagged services) is not on the code path. Only the plain-PHP service classes travel cleanly.

Gotchas and Tips

• Wrong ecosystem is the headline gotcha. The release notes mention Symfony, bundle-maker, and a Symfony skeleton lineage. Nothing here targets Laravel. Do not add this to a Laravel composer.json, and do not expect php artisan to see anything.
• create-project is destructive-ish in the wrong place. It expects an empty target directory. Running it inside an existing app directory will fail or scatter files. Always scaffold outside the consuming project.
• Freshly stable 1.0.0 on both packages. The skeleton and the maker it depends on both just hit their first stable release with no prior assessment history to draw on. There is no changelog trail, no deprecation record, and no real-world mileage yet. Read the generated files rather than assuming the scaffold is complete or idiomatic, and expect 1.0.x patch releases.
• Version constraint mismatch. "Supports Symfony 7.4 LTS and 8.1" is a claim about the generated composer.json constraints and CI matrix, not a guarantee for your machine. Check the php and symfony/* constraints against your runtime; the 7.4 and 8.x lines have different PHP minimums, and a too-loose constraint will resolve to a version your host app can't run.
• Namespace residue. The single most common post-scaffold bug is a leftover vendor/namespace string in composer.json autoload, the DI extension's alias, config/services.yaml resource paths, or a test namespace. A mismatch surfaces as "class not found" or, worse, a silently empty service container. Run composer dump-autoload and your test suite immediately after any rename.
• Missing/extra DI extension. If services aren't appearing, check that the bundle class's getContainerExtension() resolves to your extension and that Configuration returns a tree (not null) when you expect validated config. A null tree silently skips validation and makes config/packages/*.yaml keys look like they do nothing.
• Don't ship the maker. If the generator ends up in require rather than require-dev, every consumer downloads it. Audit the split before tagging.
• Extension points are the standard Symfony ones: compiler passes (for tagged-service collection and build-time wiring), the Configuration tree (for user-facing knobs), and the bundle class's boot phase. Prefer a compiler pass over runtime container introspection for anything resolved at build time — it's cacheable and fails loudly at compile rather than at request time.
• Attribution/licence. The skeleton is based on yceruto/bundle-skeleton by Yonel Ceruto. Keep the upstream licence and attribution intact in your derived repo; check what the upstream and the maker require before publishing under your own name.
• Debugging first move: in the host app, bin/console debug:container --tag=... and debug:config <alias> confirm whether your extension and config tree actually registered. In Laravel terms, that's the equivalent of php artisan about plus a dd() in register().