Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Laravel Steroids Laravel Package

escapework/laravel-steroids

EscapeWork Laravel Steroids is a small utility package that adds handy extras to Laravel, offering convenience helpers and tools for everyday development. It aims to reduce boilerplate and speed up common tasks without heavy dependencies. Useful for Laravel developers wanting a lightweight boost.

View on GitHub
Deep Wiki
Context7

Getting Started

  • Install with composer require escapework/laravel-steroids. On Laravel 5.5+ the EscapeWork\LaravelSteroids\LaravelSteroidsServiceProvider is auto-discovered; on 5.0–5.4 add it manually to config/app.php under providers.
  • First place to look: the src/ directory. This package is small (a handful of files) and under-documented, so spend the first 30 minutes reading source end-to-end — you'll probably find Traits/, Validators/, and a service provider. Treat the source as the documentation.
  • Run php artisan vendor:publish --provider="EscapeWork\LaravelSteroids\LaravelSteroidsServiceProvider" to see whether a config file ships; if nothing publishes, there is no config to tweak.
  • First use case: drop the model traits (e.g., PresentableTrait) into an Eloquent model and define a present() method that returns a presenter class, so views render formatted data (currency, dates, status labels) without clogging Blade. The second most likely use case is Brazilian document validation (CPF/CNPJ) plugged into FormRequest::rules() via Validator::extend or the package's bundled rules.
  • Verify your Laravel version against composer.json's require block before you go further — this targets Laravel 5.x and will not resolve cleanly on 8/9/10/11 without forking.

Implementation Patterns

  • Trait-in-model pattern. Add the presentable trait directly to models (use EscapeWork\LaravelSteroids\Traits\PresentableTrait;), implement present(), and access $model->present()->someAttribute in views. Keep presenter classes thin (app/Presenters/) so they stay testable.
  • Blade / macro extension. Anything the provider registers as a Blade directive or Str/Collection macro should be wrapped in a project-level helper or Blade component so that if you later drop the package, call sites don't change.
  • FormRequest integration. Put CPF/CNPJ and other domain validators into dedicated FormRequest classes rather than controllers. If the package provides validator extensions, register them in a ValidationServiceProvider you own — not in AppServiceProvider — so they're easy to find and easy to remove.
  • Fork-and-trim pattern. Given zero dependents and 5 stars, the realistic workflow is: fork the repo, delete everything you don't use, keep 1–3 helpers, and point your composer.json at the fork via a VCS repository. This is the pattern that survives the package being abandoned.
  • Repository/Service layering. If you adopt presenters broadly, don't let them leak into controllers or repositories — presenters should only be called at the view boundary. This keeps JSON API responses clean and lets you swap the presenter implementation later.
  • Wrap for testability. Any validation rule or helper you pull from the package deserves one or two PHPUnit tests in your own suite, because upstream tests are minimal and this is code you're now responsible for.

Gotchas and Tips

  • Version lock-in is the biggest risk. The package targets Laravel 5.x. Attempting to install on modern Laravel will hit Composer constraints — do not --ignore-platform-reqs your way into production. Fork, update the illuminate/* constraints, and test.
  • Abandonware signal. 5 stars, 0 dependents, no recent activity. Assume no security patches and no framework-compat updates. Pin the exact version, or vendor the code.
  • Brazilian-locale bias. Many helpers are CPF/CNPJ/currency oriented. If your domain isn't Brazilian, most of the package is noise — fork just what you need rather than pulling the full dependency in.
  • Magic trait collisions. Presenter traits often override __get/toArray() behavior. If your models already implement similar magic (or use packages like spatie/laravel-presentable), expect conflicts. Probe with php artisan tinker — (new YourModel)->present() — to confirm the trait resolves as expected.
  • Hidden global helpers. Small "steroids" packages typically register global helper functions or macros in the service provider. Grep the source for function_exists, Blade::directive, and Str::macro before assuming nothing escapes into the global namespace, then verify with php artisan about (or inspect Blade::getCustomDirectives() in a tinker session).
  • Debugging tips. (1) composer show escapework/laravel-steroids confirms the version actually installed. (2) If a trait method appears undefined, check whether the service provider is registered at all — a missing provider means macros and validators never register, even though the class autoloads fine. (3) Clear php artisan config:clear and view:clear after any change to publisher config.
  • Extension points are thin. Don't assume config-driven overrides exist. If you need to change behavior, fork. Document that decision in your repo README so future developers know why the package is vendored.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
socialdept/tenant-domains
tautvydasr/blade-class-names
socialdept/color-scales
maherelgamil/controller
coleus/widgets
coleus/table
coleus/users
coleus/music
coleus/health
coleus/calendar
coleus/notes
coleus/support
coleus/settings
coleus/apps
seampact/laravel
emmyconceptng/laravel-ng-postcode
jjsquady/round-robin
skyraptor/chatter
edlugz/sasapay
abbasudo/artisan-route