PHPackages                             framesnpictures/el-module - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Framework](/categories/framework)
4. /
5. framesnpictures/el-module

ActiveLibrary[Framework](/categories/framework)

framesnpictures/el-module
=========================

Laravel Module Helper

v1.1(3w ago)025.7k↓16%[1 PRs](https://github.com/FramesNPictures/el-module/pulls)6PHPPHP ^8

Since Aug 27Pushed 3w ago1 watchersCompare

[ Source](https://github.com/FramesNPictures/el-module)[ Packagist](https://packagist.org/packages/framesnpictures/el-module)[ RSS](/packages/framesnpictures-el-module/feed)WikiDiscussions main Synced 2d ago

READMEChangelog (10)Dependencies (3)Versions (21)Used By (6)

el-module
=========

[](#el-module)

**A declarative way to build Laravel Service Providers.**

`framesnpictures/el-module` lets you compose a service provider out of small, single-purpose **feature traits** instead of hand-writing `register()` and `boot()` methods. You `use` a trait, implement one short `define…()` method, and the module registers it at the correct point in the application lifecycle for you.

Why this exists
---------------

[](#why-this-exists)

A vanilla Laravel `ServiceProvider` has two lifecycle methods, and you have to remember **which concern goes where**:

- Container bindings (singletons, interface binds) belong in `register()`.
- Routes, views, events, policies, migrations and most wiring belong in `boot()` — and some of it only when running in the console, or only when routes/config aren't cached.

Get that wrong and you end up with subtle, hard-to-spot bugs (binding something in `boot()` that another provider needs in `register()`, registering routes that break when cached, and so on). On top of that, everything piles into the same two fat methods.

`ElModule` removes that burden:

- **No more remembering `register()` vs `boot()`.** Each feature trait already encodes the correct phase. You just declare *what*, not *when*.
- **Separation of concerns.** Every concern lives in its own tiny method (`defineWebRoutes()`, `defineSingletons()`, `definePolicies()`, …) instead of one giant `boot()`.
- **Cleaner, declarative providers.** A module reads as a list of capabilities it opts into, plus the data each capability needs.

Installation
------------

[](#installation)

```
composer require framesnpictures/el-module
```

Requires PHP `^8` and a Laravel application (the `Illuminate\*` components are provided by the host app). It has no other third-party dependencies.

Quick start
-----------

[](#quick-start)

Extend `ElModule`, `use` the features you need, and implement their `define…()`methods:

```