Search Engine Bundle Laravel Package

Getting Started

• Pull the release with composer require <vendor>/<package>:^0.3.1. The only changes in v0.3.1 are dependency-range expansions (Symfony 3 and PHPUnit 5), so there is no migration work if you are already on 0.3.0 — but the new ranges are what make the package usable on Laravel 5.2/5.3-era applications whose symfony/* constraints resolved to 3.x.
• First place to look is the package's composer.json: confirm the symfony/* and phpunit/phpunit constraints now admit ^3.0 and ^5.0 respectively. That tells you which Laravel versions the release is actually targeting.
• Register the package's service provider if it is not auto-discovered (Laravel 5.5+ auto-discovery does not apply to most 5.2/5.3 apps): add it to the providers array in config/app.php, and publish any config with php artisan vendor:publish if the package ships one.
• First use case: write a single feature test that exercises the package through the container rather than in isolation. Because v0.3.1 explicitly targets PHPUnit 5, write the test against the PHPUnit 5 API (PHPUnit\Framework\TestCase or the package's own test case base class, expectException() rather than the removed setExpectedException() variants) so you validate the compatibility claim immediately.

Implementation Patterns

• Resolve through the container, not static calls. Bind the package's contracts in a service provider and inject them into controllers, jobs, and commands. This keeps your code testable and lets you swap implementations in tests via $this->app->instance(...).
• Feature-test at the boundary. With PHPUnit 5, use RefreshDatabase/DatabaseTransactions as appropriate and assert on the package's public behaviour (HTTP responses, dispatched events, queued jobs) rather than internal classes. This is the pattern that survives future dependency bumps.
• Run a CI matrix that reflects the new support. If you maintain the package or depend on it, add jobs for symfony/*:^3.0 with phpunit/phpunit:^5.0 alongside your existing Symfony 2.7 / PHPUnit 4 jobs. The release is essentially a compatibility statement, so the matrix is the real regression test.
• Pin the major versions you actually support. Composer's ^0.3.1 constraint plus the widened transitive ranges can cause composer update to silently move you from Symfony 2.7 to 3.x. Lock the behaviour with explicit constraints in your root composer.json (e.g. "symfony/console": "3.0.*") and commit composer.lock.
• Use config and env overrides for environment-specific behaviour. Publish the config, keep secrets in .env, and avoid hard-coding values in the package's config file so deployments and tests can diverge cleanly.
• Extend via the package's published extension points (service-provider bindings, config keys, and any documented events/facades) rather than subclassing internals — the 0.x version line gives no backwards-compatibility guarantees across minor releases.

Gotchas and Tips

• This is a compatibility release, not a feature release. Nothing in v0.3.1 changes behaviour; if you were blocked on Symfony 3 or PHPUnit 5, the upgrade is the fix. If you were not blocked, there is little reason to move from 0.3.0 other than staying current.
• PHPUnit 4 → 5 is a real API break in your tests. PHPUnit_Framework_TestCase was aliased to PHPUnit\Framework\TestCase, and several mocking/prophecy APIs changed. If your suite was written against PHPUnit 4, expect failures that have nothing to do with the package itself; fix the test bootstrap first before blaming the release.
• Symfony 2.7 vs 3.x conflicts are the usual composer failure. Run composer why-not symfony/console 3.0 (or composer why-not <package> 0.3.1) to see which dependency is holding you back. Laravel 5.1 is pinned to Symfony 2.7 and will not accept the Symfony 3 path; Laravel 5.2/5.3 can.
• 0.x means no semver guarantees. Treat every minor bump as potentially breaking: read the diff, not just the release note. The terse changelog here ("added support to…") is typical of early-stage packages and hides dependency-range edits that can affect you.
• Debugging tips: composer show <vendor>/<package> --all to confirm the resolved version, composer diagnose for platform issues, and php artisan tinker to resolve the package's bindings and inspect what the container actually returns.
• Extension points to prefer: the package's service provider (rebind contracts there), its published config file, and any documented facade. Avoid monkey-patching vendor code — with a 0.x package you will be re-applying those patches on every release.