Lem Laravel Package

Getting Started

• Install and pin. composer require railken/lem — then immediately check the package's composer.json for its Laravel constraint. This package predates modern Laravel releases; if you're on Laravel 9+, expect to fork or patch before it will boot. Pin the exact version in composer.json.
• Look at the tests first. With zero stars, zero dependents, and a README that is likely thinner than the code, the test suite is your source of truth. Read the fixture/app setup and one end-to-end test before touching the README examples.
• Identify the three entry points. You'll be working with (1) a base Logic class you extend, (2) a facade/manager that resolves and dispatches logic classes, and (3) the return object the logic produces. Locate all three in src/ on day one.
• First use case: take the fattest action in an existing controller — one with inline validation, an authorization check, and model mutation — and move it into a single Logic class. Call it from the controller and return the result. That's the smallest end-to-end slice that proves the package works in your app.
• Register anything you need. If the package ships a service provider that isn't auto-discovered (common for older packages), add it to config/app.php manually and publish config with php artisan vendor:publish --provider=....

Implementation Patterns

• One Logic class per operation. CreateOrder, CancelSubscription, IssueRefund. Name them as verbs. Resist the urge to build a generic BaseCrudLogic — the readability win comes from each class stating exactly what it does.
• Thin controllers, fat logic, dumb models. Controller does HTTP parsing and response formatting only. The Logic class owns validation, authorization, orchestration, and returns a domain object or entity. The Eloquent model stays a data container.
• Declare validators on the class, don't call $request->validate(). The value of the package is that validation rules are declared as part of the operation's contract and are testable outside HTTP. Keep rules as class-level declarations so they're introspectable.
• Put domain authorization in the logic layer. Middleware is fine for "is this user logged in"; domain rules like "can this user refund this specific order" belong next to the operation. This also makes it testable without spinning up a request.
• Return data, not responses. Have the logic return an entity/result object. Let the controller (or a dedicated transformer) map that to JSON. This keeps the logic reusable for console commands, jobs, and internal API calls.
• Compose by injection, not by calling other logic classes inside logic classes. Inject repositories or services. Chaining LogicA → LogicB → LogicC makes failures hard to trace and tests brittle.
• Test the logic classes directly. The whole point is that CreateOrder::dispatch([...]) (or however the facade resolves it) is callable in a unit test without a request. Build your test suite around this seam.
• Wrap it in one adapter. Create an internal app/Actions/ layer with a single base class extending the package's Logic, so if the package dies you change one file, not two hundred.

Gotchas and Tips

• Abandonment risk is the headline risk. 0 stars, 0 dependents, 0 forks of note. Treat this as vendored code you happen to install via Composer. Fork it into your org and point Composer at your fork, or vendor it, before you build anything real on top.
• Laravel version drift. Older packages break on Container resolution changes, Illuminate\Contracts renames, and PHP 8 type-strictness. Check the package's PHP constraint and test on your actual runtime before committing to an approach.
• Container resolution order. Validators and collaborators are typically resolved via the container; the order in which they're instantiated can surprise you if a validator depends on something the logic sets up in its constructor. Keep validators stateless and dependency-free where possible.
• Don't leak the result shape to clients. Whatever the package returns (result object, array, entity) is an internal contract. Map it to your own response DTO immediately so an upgrade/fork doesn't break your API consumers.
• Facade caching. Facades and managers often memoize resolved classes. If you change config, swap implementations, or register a custom resolver, clear the cache or restart the worker — otherwise you'll chase ghosts.
• Extension points worth knowing: the base Logic class (override handle/authorize/validators), custom validator classes, and any resolver/manager binding in the service provider. These are where you customize without forking logic everywhere.
• Debugging tip: when a logic class silently returns nothing, check whether the facade swallowed an exception from a validator. Log at the resolution boundary, not inside the validator, to see the real failure.
• Write a one-page internal doc. With no community or Stack Overflow presence, the next developer on the team has nothing to Google. Document the three entry points, the base class contract, and your fork location.