Epitre Laravel Package

Getting Started

• Install via Composer and keep the constraint tight while you evaluate: composer require blackpig/epitre:^2.0.1. v2.0.1 is a patch on top of 2.0.0, so nothing should break, but the release is specifically about override behaviour — pin it and read the diff rather than floating on *.
• Publish the package's assets first (php artisan vendor:publish --provider="Blackpig\\Epitre\\EpitreServiceProvider") and check config/epitre.php before touching anything else. The published config is the primary knob for how the package wires itself into your app.
• Read the diff, not the changelog. The v2.0.1 notes are a single line ("Override tweaks"), so https://github.com/Blackpig/epitre/compare/v2.0.0...v2.0.1 is the only reliable source of truth for what moved. It is a small diff — read it in full before your first integration.
• First use case: get the default behaviour working end-to-end with zero overrides. Confirm the package's routes/views/commands respond as documented on a fresh install, then layer your customisations on top. If you start by overriding, you cannot tell a package bug from your own.

Implementation Patterns

• Override deliberately, one layer at a time. Because override resolution is the thing v2.0.1 changed, adopt a discipline of testing each override in isolation: add one override, hit the relevant route or run the relevant command, then add the next. Batched overrides make regressions from a patch release impossible to attribute.
• Prefer config over code overrides. Anything expressible in config/epitre.php should stay there — it survives package upgrades with far less churn than class or view overrides, and it's the surface most likely to remain stable across patch releases.
• Keep overrides in a dedicated, greppable location. Namespace your published views under a recognisable path (e.g. resources/views/vendor/epitre/) and your swapped classes under something like App\\Overrides\\Epitre\\. When v2.0.1-style "override tweaks" land, a single grep tells you your entire blast radius.
• Bind overrides through the container, not by editing vendor code. If the package resolves services from the container, rebind in a service provider ($this->app->bind(...) / singleton(...)) so your customisation is version-controlled application code, not a patched vendor tree that composer update will silently discard.
• Wrap the package behind a thin application-level seam. If Epitre touches models, expose it through your own service or repository class rather than calling its API directly from controllers. Then a future minor/major that reshapes overrides costs you one file, not fifty call sites.
• Integration tip — test the override, not just the feature. A feature test that asserts your overridden response shape catches the exact class of breakage a patch like this can introduce. Prefer one test per override.
• Integration tip — CI matrix. If you support multiple Laravel versions, run the package at 2.0.0 and 2.0.1 in CI before bumping production. The diff is small enough that this is cheap; it removes all guesswork.

Gotchas and Tips

• The changelog is not the changelog. "Override tweaks" tells you where to look, not what changed. Treat the compare link as mandatory reading during upgrade review, and check the PR (#3) description for the intent behind the tweak.
• Override semantics can change without a breaking version. Nothing in a patch release promises that override resolution order or precedence is stable. If you depend on a specific precedence — your view beating the package's, your binding beating the default — assert it in a test so the next patch can't quietly reorder it under you.
• Cached config and compiled views will mask the change. After upgrading, run php artisan config:clear && php artisan view:clear && php artisan route:clear (or optimize:clear). A stale compiled override is the most common reason "the upgrade did nothing" or "the upgrade broke everything".
• Don't fork to customise. Overrides via published assets, container bindings, and config are the supported path; a forked or vendor-patched package makes every future patch release a manual merge, and this package is actively releasing patches.
• Read the actual source of the override mechanism before relying on it. Locate the class or trait responsible for resolving overrides in the 2.0.1 tree and read it — that's the extension point this release touched, and it's the one place worth understanding deeply rather than by inference.
• Attribution/context. v2.0.1 is a single contributor patch from a third party; there's no migration guide, no deprecation notice, and no test-coverage statement in the notes. That's fine for a patch, but it means the burden of verification is on you — budget a short smoke-test pass rather than assuming low risk because the version number is low.
• Watch for the next release. v2.0.0 → v2.0.1 being "override tweaks" suggests the override API is still settling. Hold off building deep customisation against 2.x internals until the pattern stabilises across a couple more patches, and keep your overrides thin and well-isolated in the meantime.