Module EventServiceProvider

[solomon-ochepa]

Create an EventServiceProvider class on module creation and an artisan command php artisan module:EventServiceProvider Blog to create a new EventServiceProvider for an existing module.

• Auto registered.
• Auto-discovery enabled by default.
• Enables module's Observers and Events to be registered locally instead of using the App\Providers\EventServiceProvider

[dcblogdev]

can you fix the failing tests.

Also, EventServiceProvider should not be created by default instead use the new command to generate them as needed. No benefit in creating a provider when in most cases it won't be used.

Better to generate the provider when its needed.

[solomon-ochepa]

Can you fix the failing tests?

I didn't work on the test, but I'll try and fix it.

Also, EventServiceProvider should not be created by default instead use the new command to generate them as needed. No benefit in creating a provider when in most cases it won't be used.

Better to generate the provider when it's needed.

It should be created by default, it's not an optional Provider!

EventServiceProvider is part of the default Laravel architecture EventServiceProvider - Laravel API.

Other services depend on it to function. For instance, the Module Events/ and Observers/ can't work without EventServiceProvider.

[dcblogdev]

it's not essential or it would be part of the package. It's only needed when using events which can be accomplished by using the command so there is no issue with it being off by default.

I know you haven't written any tests but the changes you've applied are breaking the existing tests.

[solomon-ochepa]

it's not essential or it would be part of the package. It's only needed when using events which can be accomplished by using the command so there is no issue with it being off by default.

I know you haven't written any tests but the changes you've applied are breaking the existing tests.

It's not part of the package because the package is not a complete system, the essence we continuously contributing new upgrades and updates.

This is a core feature, required by the package. No events or observers will work without this file.

The essence of Modularity is code absolution, of which this is one of the core.

[dcblogdev]

No events or observers will work without this file.

yes so generate an events provider when you need to use events or observers otherwise its simply not needed.

Events can work without an events provider I've used events in existing modules using the module service provider. It's not essential.

[solomon-ochepa]

I need you to create an Event or Observer within any Module and check if it will work.

Note that Events and Observers are not modules.

This package is a solution, and of what use is it if everyone need to modify the core code to make it work?

This is not an ordinary class, it's a Laravel API class.

I don't know if you understand what this is all at.

This class is rooted inside the core class, if we expect each dev to create this class themselves, them each dev will need to folk this repo and maintain it individually or alternatively, modify the vendor files of which will be overridden on each updates!

Take a moment to research more about this API and you can come back to continue this review.

Thank you.

[dcblogdev]

The reason you've created the module:EventServiceProvider command is to generate the provider, surely you can use that when needed.

Also the command would be better to be renamed to 'module:event-providerto match themodule:route-provider` style.

Every module does not need an events service provider. I've worked on systems with around 20 modules only a couple had event service providers since they used observers the rest did not and still work absolutely fine.

[solomon-ochepa]

Events can work without an events provider I've used events in existing modules using the module service provider. It's not essential.

Is that the correct method to register Events & Observers?

It might not be essential to you, but it is.

From your comment above, it shows clearly you've been doing it the wrong way yourself.

This is a core Laravel API, not just a random class. I need you to read the official documentation please

[dcblogdev]

It might not be essential to you, but it is.
what?!

From your comment above, it shows clearly you've been doing it the wrong way yourself.

if you're going to be rude I'm just going to close this PR. Be respectful.

You are submitting a command to generate event service providers, use that when you need an events service provider. It's not needed all the time.

Remember this is a package, packages do not need an event service provider out the box, when needed they can be registered. I.E https://www.laravelpackage.com/10-events-and-listeners/#registering-the-event-service-provider

[solomon-ochepa]

It might not be essential to you, but it is.
what?!

From your comment above, it shows clearly you've been doing it the wrong way yourself.

if you're going to be rude I'm just going to close this PR. Be respectful.

Sorry, but I'm not trying to be rude here.

I only pointed out that you are not using the service correctly, sorry if you find it offensive.

You are at the liberty to close any PR you seems not fit, you are the admin and we'll respect any outcome of your decisions.

Once again, I truly sorry if I offended you. It wasn't intentional.

[dcblogdev]

okay a misunderstanding, lets move on.

My understanding is that the PR is a command to generate module EventServiceProviders.

You can use that command to generate EventServiceProviders for modules that need it. Help me to understand why you cannot use that?

[solomon-ochepa]

It might not be essential to you, but it is.
what?!

From your comment above, it shows clearly you've been doing it the wrong way yourself.

if you're going to be rude I'm just going to close this PR. Be respectful.

You are submitting a command to generate event service providers, use that when you need an events service provider. It's not needed all the time.

Remember this is a package, packages do not need an event service provider out the box, when needed they can be registered. I.E https://www.laravelpackage.com/10-events-and-listeners/#registering-the-event-service-provider

When we submit a PR, it's not for our personal gain (we must have implemented the solution in our own system already), but for the benefits of the entire community.

I'm not expecting any reward or payment for my contributions. I only submit solutions that's essential to the growth of the package and the community.

[solomon-ochepa]

okay a misunderstanding, lets move on.

My understanding is that the PR is a command to generate module EventServiceProviders.

You can use that command to generate EventServiceProviders for modules that need it. Help me to understand why you cannot use that?

The PR consist both the command and stub to create the EventServiceProviders.

Your concern is that it should not be created by default, right?

What about we add a option to the config to allow dev choose when to enable or disable the auto creation feature? I believe that will solve the problem, right?

Talking about what's essential or not, there are many features already built into the package I've never used. I can't say they are not essential, simply because I don't use them.

I hope you get my point of view.

[dcblogdev]

What about we add an option to the config to allow dev choose when to enable or disable the auto creation feature? I believe that will solve the problem, right?

yes, that would be ideal.

[solomon-ochepa]

What about we add an option to the config to allow dev choose when to enable or disable the auto creation feature? I believe that will solve the problem, right?

yes, that would be ideal.

Great. I'll fix it over the week.

Thanks for your understanding.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.