Add auto-detection and guidelines support for nwidart/laravel-modules

[lukeskw]

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:

• Auto-detection logic: Automatically detects if nwidart/laravel-modules is installed by scanning composer.lock
• Comprehensive AI guidelines: Added detailed guidelines covering:
  • Complete Artisan commands reference (30+ commands organized by category)
  • Module Facade methods and Module instance methods
  • Events and listeners management within modules
  • Publishing modules as Composer packages
  • Best practices and module structure conventions
• Version-specific support: Includes both core guidelines and Laravel Modules specific features
• Zero configuration: When nwidart/laravel-modules is detected, guidelines are automatically included without
  user intervention

Implementation details:

• Added projectUsesLaravelModules() method in InstallCommand that scans composer.lock
• Extended GuidelineConfig with usesLaravelModules property
• Enhanced GuidelineComposer to conditionally include Laravel Modules guidelines
• Created comprehensive documentation in .ai/nwidart-laravel-modules/ following the established structure

Files changed:

• src/Console/InstallCommand.php - Added auto-detection logic
• src/Install/GuidelineConfig.php - Added configuration property
• src/Install/GuidelineComposer.php - Added conditional guideline inclusion
• .ai/nwidart-laravel-modules/core.blade.php - Core guidelines (v6+)
• .ai/nwidart-laravel-modules/12/core.blade.php - Version 12 specific enhancements

---

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.

[Plytas]

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]

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.

[lukeskw]

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?