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

Module Loader Laravel Package

kodicms/module-loader

A Laravel module loader for KodiCMS that discovers, registers, and boots modular packages, wiring service providers, routes, and resources into the application lifecycle. Organizes feature modules and simplifies extending the CMS.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Modular monolith vs. microservices: This package is a concrete option for teams weighing a modular monolith against service sprawl. It enables registering and bootstrapping self-contained modules (routes, views, migrations, service providers) inside a single Laravel application — a lower-operations-cost alternative to standing up separate services for each feature domain.
  • Build vs. buy on module scaffolding: If product direction requires a plug-in or extension ecosystem (e.g., customer-specific add-ons, marketplace modules, white-label verticals), this package is a reference implementation for the "buy" side of the decision — but one that likely needs forking rather than direct dependency.
  • Roadmap sequencing for extensibility: Committing to a module boundary early constrains later decisions about package extraction. Adopting a loader now can defer — but not eliminate — the decision to split modules into independent services.
  • Use cases it fits: Internal admin platforms, multi-tenant back-offices, CMS-style products with installable feature packs, and legacy Laravel estates being stabilized rather than rewritten.
  • Use cases it does not fit: Greenfield SaaS on current Laravel, anything needing an actively patched dependency, or any product whose distribution model is incompatible with GPL-2.0.

When to Consider This Package

Consider it only when all of the following hold:

  • You are maintaining an existing Laravel 5.x-era application and need module registration that matches that generation's conventions.
  • You are comfortable vendoring or forking the code — the last tagged release is from 2016, so expect to own maintenance, security review, and compatibility patches.
  • Your team has deep Laravel service-provider and autoloading expertise; this is infrastructure, not a batteries-included framework.
  • GPL-2.0 is acceptable to your legal/distribution model — e.g., internal-only use, or a product already distributed under a compatible license. GPL is a hard blocker for most closed-source commercial products.
  • You need a thin, readable reference for how module discovery, registration, and bootstrapping can work, rather than a supported dependency.

Look elsewhere when:

  • You need active maintenance, security patches, or a responsive issue tracker. Fifteen stars and zero dependents means no community safety net and effectively no de-risking from third-party usage.
  • You are on Laravel 8+ and want a maintained solution — nwidart/laravel-modules is the de facto choice, with broad adoption, documentation, and permissive licensing.
  • You require a permissive license (MIT/Apache-2.0) for proprietary distribution.
  • You need first-class tooling: module generators, migration orchestration, asset publishing, testing harnesses.
  • Your architecture decision hinges on long-term vendor support; a decade-old, single-maintainer package is a liability on a roadmap.

How to Pitch It (Stakeholders)

For executives: This is a small, unmaintained 2016 package for organizing a Laravel application into pluggable modules. It is not a candidate for new investment. Its value is as a design reference: it shows how a modular monolith can be structured without splitting into microservices, which is often the cheaper operating model. The licensing (GPL-2.0) and dormancy make direct adoption a governance risk rather than an engineering convenience.

For engineering leadership: Treat this as a pattern source, not a dependency. If modularity is a genuine roadmap requirement, budget for either (a) adopting a maintained alternative like nwidart/laravel-modules, or (b) a short internal spike to build module registration in-house — likely 1–2 engineer-weeks, and cheaper than the long-term cost of owning a decade-stale fork. Recommend a spike to evaluate the maintained alternative against our Laravel version and licensing constraints before committing.

Bottom line: Low strategic weight, high maintenance burden, licensing friction. Do not add to the product stack; harvest the idea, not the code.

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.
frankyso/ipaymu
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
diephp/sequences
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator
itstructure/laravel-multilingual-tools
pdustdar/elasticsearch
markupai/php-sdk
rlacerda83/lumem-microservice-shipment