Laravel Dusk Select2 Laravel Package

Getting Started

This package sits on top of laravel/dusk and is intended to be used inside your Dusk test suite rather than in application runtime code. Minimum steps:

1. composer require --dev <package> — it is a test-only dependency; keep it out of production.
2. Confirm laravel/dusk is installed and php artisan dusk:install has been run, so tests/DuskTestCase.php and the tests/Browser directory exist.
3. Register anything the package exposes (service provider, helper trait, or base test case) in tests/DuskTestCase.php or in the specific browser tests that need it.
4. Run a single smoke test first: php artisan dusk --filter=YourTestName to prove the wiring works before writing broader suites.

Where to look first: the package's README for the supported Dusk version, then its src/ for the base test case/traits you are expected to extend or use. The 2.1.0 release moved back to depending on laravel/dusk directly instead of pulling in the full framework, so if you are upgrading from 1.x, check that your Dusk version satisfies the new constraint before anything else.

First realistic use case: replace hand-rolled browser-test boilerplate (login helpers, selectors, page objects) with the package's abstractions, and verify a single critical flow — login → dashboard — end to end.

Implementation Patterns

• Base test case inheritance. Extend the package's Dusk test case (or apply its trait) so every browser test inherits the same browser setup, helpers, and teardown behaviour. Avoid mixing the package helpers into only some tests; consistency matters more than minimalism here.
• Page objects over inline selectors. Keep selectors in page/component classes and have tests call intent-revealing methods ($page->loginAs($user)). This is where Dusk-based packages pay off — when the markup changes you edit one class, not thirty tests.
• CI as the primary runtime. Because this is a Dusk package, the workflow is: local smoke run → CI matrix run. Treat your CI browser job (headless Chrome in the container the package ships/expects) as the source of truth, and keep the local run for fast feedback only.
• Feature-flag and state isolation. Use RefreshDatabase (or the Dusk equivalent with a dedicated testing database) plus explicit factories per test. Browser tests are slow and stateful; any shared state turns into flaky failures that are painful to bisect.
• Screenshots and console logs on failure. Wire Dusk's failure screenshot/console-log capture into your test case so CI artifacts contain the reason a test failed, not just the assertion message.
• Group and tag. Separate slow end-to-end suites from fast smoke suites with PHPUnit groups so developers can run a subset locally and the full set only on CI.

Gotchas and Tips

• The 1.x → 2.x dependency change is the real breaking surface. 1.x depended on the full framework; 2.x depends on laravel/dusk. If your app pins an older Dusk or an older Laravel, composer resolution will fail or silently downgrade. Pin laravel/dusk explicitly in composer.json and verify with composer why laravel/dusk.
• No composer.lock in the package is normal, but not for you. The package removing its lock file only affects contributors. Your application must commit its own lock file so CI browser jobs are reproducible.
• PHPUnit schema migration. The move to the new PHPUnit schema means phpunit.xml attribute names differ from older Dusk setups. If you copied an old phpunit.dusk.xml, expect warnings or ignored settings — regenerate from dusk:install and re-apply your customisations.
• Test namespacing. Tests moving into a namespace means any test that relied on global class names, string-based --filter, or require-style includes may break. Check your composer.json autoload-dev mapping covers tests/Browser.
• Docker image swap. If you run the package's provided container in CI, the image changed. Pin the image by tag or digest rather than latest, and re-validate that the Chrome/driver versions inside still match your local Dusk.
• Debugging flakiness: run with --browse locally to watch the browser, and add $browser->pause(500) temporarily rather than sprinkling sleep(). Persistent flakiness is almost always a wait-condition problem, not a package bug.
• Extension points to prefer: the package's base test case and page-object base classes are the stable extension surface. Subclassing internal classes or overriding protected methods is where upgrades will hurt you.

Overall: 2.1.0 is mostly a maintenance and tooling release — the dependency narrowing from the full framework to laravel/dusk is the one change that can actually break an install, and it is worth verifying before adopting.