happenv-com/laravel-true-modular

This system is a Laravel package that enables the construction of modular monoliths by managing module lifecycles, dependencies, and boot ordering. It provides tooling for scaffolding modules, analyzing architectural dependencies, and converting existing applications into a modular structure. The system also includes features for granular module activation, performance caching, and health check integration.

Added documentation and AI assistant skills for the \happenv-com/laravel-true-modular\ architecture, guiding developers to build features within self-contained modules rather than the \app/\ directory. The new \core.blade.php\ guidelines and \modular-monolith-development\ skill explain the declarative \Module\ builder pattern, the three-phase lifecycle (register, initialize, boot), and cross-module wiring rules. They also document how to disable modules via environment variables or configuration files without removing them from \composer.json\, and provide CLI commands like \module:list\ and \module:impact\ for inspecting dependencies.

resources · high confidence

This entry introduces the \happenv-com/laravel-true-modular\ package, which transforms a Laravel application into a modular monolith. The package provides a custom \Application\ class that sorts module service providers in topological dependency order and adds an \initialize()\ lifecycle phase between \register()\ and \boot()\. It includes a \ModuleProvider\ base class for auto-wiring module assets, routes, and configs, along with CLI commands for architecture analysis (\module:graph\, \module:impact\, etc.) and module scaffolding. The package requires PHP 8.3+ and Laravel 12/13.

(repo-wide) · high confidence

This change introduces a new Architecture SDK and a suite of new Artisan commands for module management and analysis. Users can now scaffold new modules with \module:make\, validate activation states with \module:check\, and cache module registries for performance via \true-modular:cache\ and \true-modular:clear\. The update also adds architecture analysis commands (\module:graph\, \module:impact\, \module:why\) to visualize dependencies and impact, alongside an interactive \true-modular:setup\ command to convert existing applications into a modular monolith structure. Existing commands like \module:list\, \module:seed\, and \module:make:migration\ have been refactored to use the new architecture index and registry, supporting new output formats and vendor-agnostic naming.

src/Commands · high confidence

This release introduces a stub-driven module scaffolding system (ModuleGenerator) that generates modules from publishable stubs and registers them in composer.json, alongside a fluent ModularApplication entry point for configuring module directories and namespaces. It adds a ModelExtension system allowing modules to dynamically register Eloquent attribute resolvers and relationship methods on core models. Performance is significantly improved by caching the module registry and sorting service providers once per process rather than per boot, and by using a namespace matcher to avoid repeated lookups. The Application class now includes a fallback for getNamespace() to prevent crashes when the root autoload is removed during setup, and the module\_path helper now respects the configured modules directory.

src · high confidence

This change introduces the Architecture SDK within the src/Architecture directory, providing a new capability to analyze and visualize module dependencies. It includes a DependencyGraph for tracking direct and transitive relationships, an ArchitectureIndex to aggregate module descriptors and dependency edges, and specialized analyzers (Graph, Impact, Why) to compute dependency trees, impact assessments, and dependency paths. The SDK also features a pluggable renderer system supporting multiple output formats, including text, JSON, DOT (Graphviz), Mermaid, and tree views with box-drawing glyphs, allowing users to inspect module structures in various ways.

src/Architecture · high confidence

The module scaffolding system now uses a set of new stub files to generate module structures, making the generated code publishable and customizable. This includes a composer.json stub for autoloading and service provider registration, a config stub for versioning, a web route stub pointing to a welcome controller, a controller stub that returns the module version, and a service provider stub that configures the module's name, config, and routes.

stubs, stubs/module · high confidence

The new \true-modular:setup\ command automates the conversion of a standard Laravel application into a modular structure. It moves the existing \app/\ directory into a \core\ module, rewrites all PHP namespaces from \App o the new core module namespace, and scaffolds a \CoreServiceProvider\ to maintain compatibility with the original \AppServiceProvider\. The command also updates \bootstrap/app.php\ to use the new \ModularApplication\, registers the core module as a Composer path package in \composer.json\, and empties \bootstrap/providers.php\ to rely on module auto-discovery. A final scan identifies any remaining files that still reference the old \App amespace for manual cleanup.

src/Setup · high confidence

The module provider traits have been refactored to significantly reduce boot-time overhead by deferring expensive file-system operations (such as listing migration directories and resolving publish targets) until they are actually needed by the migrator or the vendor:publish command, rather than computing them on every application boot. Additionally, the system now safely handles missing module directories (common in fresh checkouts where empty directories are not tracked by Git) by logging warnings and skipping capabilities instead of crashing, and module assets, routes, and other resources are now resolved via the module's vendor path rather than relative base paths.

src/ModuleProvider/Concerns/PackageServiceProvider · high confidence

The module package concerns have been migrated to the \Happenv\\LaravelTrueModular\\ModuleProvider\\Concerns\\Package\ namespace, requiring updates to any code referencing the old \Happenv\\LaravelTrueModularModuleProvider\ path. A new \HasHealthChecks\ trait allows modules to register health check classes via \hasHealthCheck\ and \hasHealthChecks\. Several traits (\HasBroadcasts\, \HasCommands\, \HasMigrations\, \HasRoutes\, \HasSchedule\) now use a shared \MergesFlattened\ trait to simplify how they accept and merge lists of items. The \HasConfigs\ trait now throws an \InvalidModule\ exception if a config file is declared more than once, preventing silent overwrites. The \HasInertia\ trait introduces a dedicated \inertiaNamespace\ property, separating it from the general view namespace. Additionally, \HasMorphMapDefinitions\ now requires the module name to be set before defining morph maps, throwing a clear error if called prematurely.

src/ModuleProvider/Concerns/Package · high confidence

The ModuleProvider classes have been migrated to the new \Happenv\\LaravelTrueModular\\ModuleProvider\ namespace, updating all internal trait imports and return types to \static\. This change introduces support for health checks by adding the \HasHealthChecks\ trait to the \Module\ class and the \GuardsModulePaths\ trait to \ModuleProvider\. Additionally, the provider now registers the \ModuleManifestRepository\ singleton during the module registration phase, and migration processing has been moved to the main boot sequence rather than being console-only.

src/ModuleProvider · high confidence

The module system has been refactored to significantly improve boot performance and introduce granular module control. A new caching layer (ModuleRegistryCache) stores the module scan and topological order to disk, eliminating the need to parse every module's composer.json on every boot. Module discovery now supports filtering by module type and exposes both runtime and development dependencies for accurate graph ordering. A new ModuleActivation component allows modules to be disabled via environment variables or a JSON file, automatically excluding their owned vendor packages from Laravel's package manifest to prevent dangling aliases. Additionally, a ModuleActivationAudit tool validates the configuration, reporting issues such as orphaned modules, broken dependencies, and contested package ownership.

src/ModuleSystem · high confidence

Added comprehensive test coverage for the modular architecture and module management system; Added test fixtures for module service provider ordering.

The project's development dependencies have been expanded to include Laravel Access Control (^2.0), Laravel Pint (^1.29), Orchestra Testbench (^11.1), Rector (^2.5), Larastan (^3.10), and Livewire (^3.0), while the minimum stability has been raised from 'dev' to 'stable'. Additionally, a new set of test fixtures under \tests/fixtures/app-modules\ has been introduced, defining a sample modular dependency graph (kernel, core, sale, pim, amazon) to support testing of the library's module management capabilities.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 83 → 78 (-5.3)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 100 (+0.0)
• Architecture 100 → 99 (-0.5)
• Maturity 75 → 72 (-3.7)
• Readiness 81 → 69 (-11.2)
• Security 100 → 100 (+0.0)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• LLM evaluation failed
• No exposed public API
• Test reliability not included
• early-stage repository — too few commits for a meaningful bus factor
• early-stage repository — too little history to judge knowledge freshness

• Ambiguous distinction between getModuleNames and getAllModules. 'getModuleNames' returns an array of strings, while 'getAllModules' likely returns an array of Module objects or descriptors. However, the naming is not immediately obvious about the return type difference, leading to potential confusion.
• Dependency hygiene PARTLY measured — Composer dependencies read, no committed lock to grade for currency
• Duplicate intent between ModuleLocator and AppModulesLocator. Both classes expose identical methods (byClass, byPath, byComposerPackage, resolve, resolveOrFail, all) with identical signatures. AppModulesLocator appears to be a specialized or context-aware version of ModuleLocator, but the API surface is redundant.
• Inconsistent naming for provider registration. 'register' is used for standard providers, while 'registerDeferredProvider' is used for deferred ones. This breaks the symmetry expected in a fluent or consistent API, where one might expect 'registerProvider' and 'registerDeferredProvider', or a single 'register' method with a flag.
• Inconsistent naming for reverse operations. 'findFilesReverse' and 'findClassesReverse' use 'Reverse' in the method name, but it's unclear what 'reverse' means in this context (e.g., reverse topological order, reverse file search, or reverse namespace matching). This is ambiguous compared to standard naming conventions.
• No dependency advisory monitoring
• Two different classes (ArchitectureIndexBuilder and IndexAccumulator) both have a 'build' method that returns an ArchitectureIndex. This suggests two different ways to construct the same object, which can confuse users about which entry point to use.

• 8 commits — 6 feature/other, 2 fixes

• src/ModuleSystem — 3 commits
• tests/Unit — 2 commits
• stubs/module — 1 commit
• tests/Feature — 1 commit
• tests/fixtures — 1 commit

• fix: fix: getNamespace() po true-modular:setup + mylący prompt namespace'u (#10)
• fix: fix: keep getProvider() answering after boot has sorted the providers (#9)
• change: feat: expose the dependency graph including require-dev (#12)
• change: feat: make the module scaffold stub-driven and publishable (#7)
• change: feat: switch modules off without removing them from composer.json (#8)
• change: perf: sort the service providers once per process, not once per boot (#14)
• change: perf: stop paying for module discovery on every boot (#13)
• change: perf: take the per-boot module scan off the hot path (#11)

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

happenv-com/laravel-true-modular was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.