Getting Started

Install the package as a dev dependency and follow the package README for any publish tags or service-provider registration.
Start by opening the package README, config file, and service provider. The key decision is how it discovers Blade views: v0.1.3 defaults to Laravel’s standard resources/views directory.
For a standard Laravel app, the first use case is simple: run your existing feature/HTTP tests that render Blade views, then inspect the generated Blade coverage output.
For a monorepo, look for the new opt-in setting before changing paths. Enable it only when you need to point the plugin at package-specific view roots outside the app’s default resources/views.
Pin v0.1.3 in composer.json while the package is still pre-1.0. Treat its config keys and report format as early-stage until documented otherwise.

Implementation Patterns

Run Blade coverage as a separate CI job from normal unit tests. Use a coverage-capable driver such as Xdebug or PCOV, and keep the job focused on tests that actually render views.
In standard Laravel apps, lean on the new resources/views default and avoid custom path config unless a view root genuinely lives elsewhere.
In monorepos, explicitly opt in and map each package’s view directory. Keep path mappings close to the package that owns the views so coverage ownership stays clear.
Pair Blade coverage with feature tests that exercise real routes, controllers, components, and includes. Coverage is most useful when the rendered view path is obvious from the test name.
Use the coverage output as a PR signal rather than a hard global gate at first. Start with changed views or newly added templates, then tighten thresholds once the baseline is understood.
For local development, run a targeted test file or filter first, then run the broader Blade coverage command before pushing. This keeps feedback fast while the package is still early-stage.
Integrate with existing Laravel test commands where possible. Avoid duplicating test setup; let the package consume the same test suite and environment your app already uses.

v0.1.3’s default is resources/views. If your app uses custom view paths, package views, or a monorepo layout, verify the opt-in configuration instead of assuming discovery works.
Clear compiled views and config caches when coverage looks stale: php artisan view:clear and php artisan config:clear. Blade coverage can be misleading if Laravel is serving cached compiled templates.
Monorepo opt-in support is new. Test it against each package view root and confirm the report attributes coverage to the correct files.
Dynamic includes, runtime component resolution, and view names built from variables may not map cleanly to static coverage. Inspect the report for missing or oddly attributed templates.
Confirm the coverage driver is installed and enabled in the same PHP process that runs the tests. Missing Xdebug/PCOV is a common cause of empty or failed coverage output.
Because this is a 0.1.x release, avoid relying on undocumented config keys, report formats, or extension points in shared tooling. Wrap package-specific commands in your own Composer script if you need a stable internal interface.
Use published config as the extension point when available. Keep overrides in app/package config rather than editing vendor files.
Performance can degrade if Blade coverage runs across the entire test suite. Scope it to view-rendering tests, exclude irrelevant suites, and compare results against a known baseline.