repository·master·Indexed 27 days ago
https://github.com/nwidart/laravel-modulesA Laravel package for managing large applications by organizing them into modular components. Each module acts as a mini-package with its own views, controllers, and models. It provides a comprehensive suite of Artisan commands for module lifecycle management, including installation, enabling/disabling, deletion, and module-specific database migrations and pruning.
The module autoloading mechanism relies on wikimedia/composer-merge-plugin. During installation, you must allow this plugin to execute. If you did not answer y during the interactive prompt, you must manually enable it in your composer.json under the config.allow-plugins section.
"config": {
"allow-plugins": {
"wikimedia/composer-merge-plugin": true
}
}By default, module classes are not loaded automatically. To enable autoloading, add the merge-plugin configuration to the extra section of your composer.json.
Note for v11.0+: The manual autoloading entry "Modules\": "modules/" is no longer required and should be removed from your composer.json if it exists.
After updating composer.json, run composer dump-autoload to apply the changes.
"extra": {
"laravel": {
"dont-discover": []
},
"merge-plugin": {
"include": [
"Modules/*/composer.json"
]
}
},Install the package using Composer. The package automatically registers its service provider and alias upon installation.
To publish the configuration file, run the vendor:publish command for the Nwidart\Modules\LaravelModulesServiceProvider provider.
composer require nwidart/laravel-modules
# Optionally publish configuration
php artisan vendor:publish --provider="Nwidart\Modules\LaravelModulesServiceProvider"The location and namespace of generated services are determined by the following configuration settings:
modules.paths.generator.services.namespace. It defaults to Services.services configuration via GenerateConfigReader::read('services')->getPath(). If not found, it defaults to the path defined in modules.paths.app_folder appended with Services.This allows you to customize where service classes reside within your module structure.
The location and namespace of generated interfaces are determined by the following configuration settings:
interfaces configuration group via GenerateConfigReader::read('interfaces'). If this is not configured, it falls back to config('modules.paths.app_folder') . 'Interfaces'.modules.paths.generator.interfaces.namespace. If not set, it defaults to Interfaces.The InertiaPageMakeCommand relies on several configuration keys to determine file paths and default behavior:
modules.inertia.frontend: Defines the default frontend framework (vue, react, or svelte).modules.inertia.path: (Via GenerateConfigReader) Sets the base path for Inertia pages within a module. If not set, it defaults to resources/js/Pages.modules.paths.generator.inertia.namespace: The default namespace for generated Inertia pages.modules.paths.generator.inertia.path: An alternative way to define the path for the namespace.modules.paths.app_folder: Used as a prefix when determining the default namespace.You can customize the behavior of the Inertia component generator via the modules configuration file:
modules.inertia.frontend: Defines the default frontend framework (vue, react, or svelte) if no flag is provided. Defaults to vue.modules.inertia-components.path: Defines the base path within the module where components are stored. If not set, it defaults to resources/js/Components.modules.paths.generator.inertia-components.namespace: Defines the default namespace for the generated component.scopes configuration. You can customize this path using the GenerateConfigReader::read('scopes') configuration setting. If not explicitly configured, the command defaults to appending /Scopes to the path defined in config('modules.paths.generator.model.path') within the target module.When creating a module, you can use the provided Vite stub to configure asset compilation. The stub uses a placeholder $LOWER_NAME$ which is replaced by the module's name in lowercase during scaffolding.
Key configuration details in the stub:
../../public/build-$LOWER_NAME$ to ensure module assets are isolated from the main application's public directory.laravel-vite-plugin is configured with a buildDirectory of build-$LOWER_NAME$ and a publicDirectory pointing to the application's root public folder (../../public).resources/assets/sass/app.scss and resources/assets/js/app.js relative to the module root.@ alias is configured to point to the module's resources/js directory.import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
export default defineConfig({
build: {
outDir: '../../public/build-$LOWER_NAME$',
emptyOutDir: true,
manifest: true,
},
plugins: [
laravel({
publicDirectory: '../../public',
buildDirectory: 'build-$LOWER_NAME$',
input: [
__dirname + '/resources/assets/sass/app.scss',
__dirname + '/resources/assets/js/app.js'
],
refresh: true,
}),
],
resolve: {
alias: {
'@': __dirname + '/resources/js',
},
},
});module:publish-inertia command supports the following options to specify the frontend framework or force file overwriting:The following options are available for the module:migrate-refresh command:
--database=<connection>: The database connection to use.--force: Force the operation to run even when in a production environment.--seed: Indicates if the module's seed task should be re-run after the migrations are refreshed.When using the module:seed command, you can pass several options to refine how the seeding process executes:
--class: Specify a specific class name to append to the root seeder. This is useful if you want to run a specific seeder class instead of the module's main database seeder.--database: Specify the name of the database connection to use for the seeding operation.--force: Use this flag to force the seeding operation to run even when the application is in a production environment.