✨ [Feature] Support Package Development about goravel

[anabeto93]

@hwbrzzl , I created a new issue which I think holds more priority to this current issue. I think if we can have the IoC implementation done, this current issue would become so much easier to do. I took a look at the laravel vendor/laravel/framework/src/Illuminate/Contracts/Container/ directory and everything inside it is quite easy to implement in golang on the goravel framework. The implementation is found in vendor/laravel/framework/src/Illuminate/Container/Container.php and it is not complicated to replicate. I also noticed the Illuminate\Contracts\Foundation interface extends the Container interface and the Application implementation also extends the Container implementation.

[hwbrzzl]

I checked the Laravel document and I found some components that we need to implement in the first version:

1. Service Providers
2. Configuration, not contain Default Package Configuration
3. Routes
4. Migrations
5. Commands
6. Public Assets
7. Publishing File Groups

There is a key point: we need a standard, let the third package can use the basic ability of goravel/framework.

[anabeto93]

Suggested plan for developing the important components for a third party package for goravel.

1. Service Providers: Implement service providers to allow packages to register their services, event listeners, and middleware with the goravel/framework.

2. Configuration: Set up a configuration system for third-party packages, but exclude default package configuration for now, as suggested.

3. Routes: Enable packages to define their own routes that integrate seamlessly with the goravel/framework.

4. Migrations: Implement migrations to allow packages to manage their database schema changes over time.

5. Commands: Enable packages to define custom console commands that can be executed using the goravel/framework CLI.

6. Public Assets: Establish a system for packages to publish and manage their public assets, such as CSS, JavaScript, and images.

7. Publishing File Groups: Implement a feature that allows package developers to define groups of files that can be published together.

Regarding the first component ServiceProvider, I noticed that the stancl multitenancy package has two service providers. One in the assets/ directory, assets/TenancyServiceProvider.php and the one in the main src/ directory, src/TenancyServiceProvider.php. The one in the assets/ is the one that is auto-discovered and the one in the src/ is the one that actually does the work of publishing routes/, migrations/, configs/, etc. All other commands of the Tenancy package depended on this src/ service provider in order to be able to do things like tenancy:install, where config is copied over, etc.

My notes here are:

1. Goravel framework itself needs a BaseServiceProvider that implements the contracts.ServiceProvider that all other service providers can "compose"/inherit
2. A third party package developer needs 2 service providers, the publishable and configurable one, and the main "unpublishable" service provider that is responsible for doing the actual work of publishing assets, routes, configs, etc
3. Goravel needs a way to "auto-discover" packages but this is not necessarily important at this time. It is going to be a little bit complex but I'll expand on this later. We would have to create a requirement for a JSON, YAML or TOML file, like the composer.json in laravel packages to enable this auto-discovery. Top of head example { "providers": [ "github.com/vendor/package/package_service_provider.go" ], "aliases": { "Package": "github.com/vendor/package/facades/package_service_provider_facade.go" } }

[hwbrzzl]

Thanks for your summary!
About your notes:

1. Sounds good, let's make a simple example first when implementing;
2. I think one or more service providers should be supported, will have wider adaptability.
3. Yes, we can have it in the future, but not now;