-
Notifications
You must be signed in to change notification settings - Fork 134
Add auto-detection and guidelines support for nwidart/laravel-modules #198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
...dules - Add projectUsesLaravelModules() detection method in InstallCommand - Extend GuidelineConfig with usesLaravelModules property - Enhanced GuidelineComposer to conditionally include Laravel Modules guidelines - Add comprehensive AI guidelines for Laravel Modules (v6+) and v12 features - Support 30+ Artisan commands, Facade methods, events, and publishing workflow - Updating docs to reflect the changes
I think ideally boost would expose hooks for 3rd party packages to hook in. Then all this content would live inside those packages and it would (either automatically or via config) just work.
Otherwise there will be tons of PRs for different packages and it's not responsibility of boost to maintain them.
HichemTab-tech
commented
Aug 26, 2025
I agree with @Plytas , I don't think it's ideal to have support to every package, for the laravel first party packages I think it's fine, but for the rest it would be better if we can have their support as a separated package like a plugin for boost or something.
This way we can have support for any package and when needed we just install the right plugin.
I agree with @Plytas , I don't think it's ideal to have support to every package, for the laravel first party packages I think it's fine, but for the rest it would be better if we can have their support as a separated package like a plugin for boost or something.
This way we can have support for any package and when needed we just install the right plugin.
Sure, I see your point and I agree — that’s exactly why I asked in the first place. For now, I’ll go ahead and create a separate package that hooks into Boost. Later, when I have some spare time, I’d be happy to explore contributing towards adding those extension hooks directly into Boost. Does that sound like a good direction?
This PR introduces automatic detection and AI guidelines support for the nwidart/laravel-modules package,
following the same pattern established for other packages.
Motivation:
The nwidart/laravel-modules package is widely used (11M+ installs) in the Laravel ecosystem for managing large applications through a modular structure. In my experience, it's essential in the 3 main projects I work on daily, making this integration highly valuable for developers working with modular Laravel applications.
What's included:
user intervention
Implementation details:
Files changed:
Question:
Is this the appropriate place for this PR? I'd like to understand if Laravel Boost will focus exclusively on
official Laravel packages or if it will also support popular third-party packages like nwidart/laravel-modules.
If the policy is to support only official Laravel packages, I'm happy to create this as an extension to the
official library instead. I just want to ensure I'm contributing in the right direction for the project's vision.