Swagger Bundle Laravel Package

Getting Started

Treat 2.0.0-alpha4 as a pre-release. Start by checking the package’s composer.json constraints before installing, especially any symfony/* requirements.

Minimal steps:

1. Require the alpha with an exact constraint so a later alpha/beta does not surprise you.
2. Run composer update --with-dependencies in a branch, not directly on production.
3. Run the package’s own test suite and your application’s smoke tests.
4. Publish/configure any service provider or config file exposed by the package.
5. Exercise one real entry point: a command, job, route, or container binding.

First use case: wire the package into a small Laravel feature test or artisan command that resolves its main service from the container. Since the release removed the SymfonyKernel alias in tests, do not rely on that alias in your own test bootstrap. Prefer Laravel’s TestCase, application container, and package service provider.

Implementation Patterns

Use the package behind Laravel’s container and configuration rather than calling Symfony components directly from application code. This keeps upgrades isolated if the package’s Symfony constraints change again.

Common patterns:

• Bind the package service in a service provider and inject it into commands, jobs, or controllers.
• Wrap Symfony-component interactions in a small adapter or package-specific service so application code does not depend on Symfony class names.
• In tests, boot the Laravel application normally and resolve the package from the container instead of recreating a Symfony kernel.
• Pin Symfony component versions in the root composer.json when the package’s constraints are broad or conflict with your app.
• Add a feature test that covers the package’s main integration path, not just unit tests.
• If you maintain multiple Laravel/Symfony versions, test the lowest and highest supported dependency sets separately.

Workflow for this alpha:

1. Install in a branch.
2. Run composer why-not if dependency resolution fails.
3. Run application tests plus the package’s documented smoke test.
4. Check logs for container-binding or kernel-bootstrap errors.
5. Only then merge into a staging branch.

Gotchas and Tips

• Alpha instability: 2.0.0-alpha4 is not a stable API. Expect breaking changes before final 2.0.0.
• Symfony 3.2 support removed: v2 drops legacy Symfony 3.2 compatibility. If your app still depends on Symfony 3.2-era components, stay on the v1 line or upgrade the dependency chain first.
• Removed SymfonyKernel alias: tests or bootstrap code that referenced the alias may fail. Update tests to use Laravel’s test harness or the package’s current test helpers.
• Symfony version conflicts: the release fixes some component conflicts, but broad constraints can still collide. Use composer diagnose, composer why-not, and explicit version pins where needed.
• CS tests removed: coding-standard CI is not currently enforced. Run Pint or PHP-CS-Fixer locally if style consistency matters.
• .gitattributes added: this mainly affects distribution archives and export-ignore behavior, not runtime. It is not a reason to upgrade by itself.
• Travis-only fixes: CI changes do not guarantee compatibility with your PHP/Laravel matrix. Verify locally or in your own CI.
• Debugging tip: after install, run php artisan clear-compiled, composer dump-autoload, and a single container-resolution test before debugging higher-level behavior.
• Extension points: prefer the package’s service provider bindings, config file, and published contracts/adapters over subclassing internals. Those are the safest places to customize while the alpha API settles.