Module Support Laravel Package

Getting Started

This is the first assessment for saeedhosan/module-support, based on the v0.0.1 release. Treat the package as early-stage: the 0.0.x version line signals that public APIs and conventions may still move quickly.

1. Require the package:

   composer require saeedhosan/module-support
   

2. Check whether the package's service provider is auto-discovered. If not, register it in config/app.php or bootstrap/providers.php depending on your Laravel version.

3. Look first at the package's ServiceProvider and the v0.0.1 fix for views path resolution. That change is the clearest signal about how module view paths are expected to be registered and resolved.

4. Start with the smallest useful case: create a module directory with a resources/views folder, register that module through the package's conventions, and confirm that a namespaced view resolves:

   return view('my-module::welcome');
   

   If that works, the core module registration and view path resolution are functioning. If it does not, the problem is almost certainly in the module path, the namespace string, or cached views.

Implementation Patterns

• Register modules through the package's provider base or registration API. The v0.0.1 fix specifically concerns view path resolution inside the ServiceProvider, so module providers are the central integration point. Keep module-specific bootstrapping (views, config, routes, migrations, translations) in each module's provider rather than in AppServiceProvider.

• Use namespaced views consistently. Modules should expose views under a distinct namespace, e.g. my-module::admin.index. This avoids collisions with application views and makes it obvious which module owns a template. Verify the namespace matches the string used during registration.

• Publish only what needs overriding. If the package supports publishing module views, publish them selectively into the host application's resources/views/vendor/{namespace} directory. Keep the module's own views as the source of truth unless the application genuinely needs to customise them.

• Keep module paths explicit. The views path fix suggests path resolution was previously fragile. Define module resource paths relative to the module root (for example, using __DIR__ or a package helper) rather than relying on the application's current working directory. This is especially important when modules are installed via Composer into vendor/.

• Integrate with Laravel's standard module concerns. In each module provider, register views alongside the other resources the module owns: config (mergeConfigFrom), migrations (loadMigrationsFrom), routes, translations, and commands. This keeps a module self-contained and makes it portable between applications.

• Pin the version for now. Because this is v0.0.1, use a constrained requirement such as "saeedhosan/module-support": "0.0.1" or "^0.0.1" and review changelogs before upgrading. The 0.0.x line should not be treated as API-stable.

Gotchas and Tips

• Cached views can mask path fixes. After upgrading to v0.0.1, run:

  php artisan view:clear
  php artisan view:cache
  

  A stale compiled view or cached view hint can make it look like the path resolution fix did not apply.

• Check registered view hints when debugging. If a namespaced view cannot be found, inspect the view finder's registered namespaces:

  dump(app('view')->getFinder()->getHints());
  

  Confirm the module namespace exists and points to the expected absolute path. A relative or incorrectly resolved path is the most likely failure mode given the v0.0.1 change.

• Watch for namespace collisions. Two modules registering the same view namespace will silently shadow each other. Use unique, predictable namespaces and avoid generic names like admin or core.

• Verify behaviour in both local and Composer-installed contexts. Path resolution that works when the module lives in the application root can fail when the same module is installed under vendor/. Test the module in the same layout you intend to deploy.

• Do not assume broader module features are stable. v0.0.1 only documents a views path fix. Other module-support behaviour — config merging, route registration, asset publishing, autoloading conventions — should be verified against the package source before relying on it in production.

• Extension point to watch: the module ServiceProvider is where the package is most likely to expose customisation. If you need to adjust view path behaviour or add module-level bootstrapping, extend or configure the provider rather than patching vendor code.

• Report issues upstream. Given the package is at its first tagged release and the only change so far is a path-resolution fix, precise bug reports with the module layout, namespace, and registered hints will be valuable and will likely influence the 0.0.x API.