Autodiscovery loading Form alias after my custom package alias Form

[kaidoj]

So i load both packages using laravel auto discovery and for me laravelcollective providers and aliases are loaded after so they override my package "Form" alias. I cannot override Formbuilder class. Only workaround was dont-discover laravelcolletive package, but its annoying that i have to do it. Could we maby implement something to auto discover that it uses order of composer json packages. So if i put laravel/framework before my custom pacakage it will load all laravel/framework packages before my custom package. I think this is something that is needed. You cannot expect that aliases are not repeating.

Laravel: 5.5

[ragingdave]

I would disagree pretty heavily with making the order of packages in the composer.json translate to discover order. There are tons of ways this could go wrong, that would most likely be hard to track down and would require an understanding of the auto discovery that really shouldn't be needed.

That being said, Based on how extensible the laravel collective form/html stuff is, what are you trying to do that can't be accomplished by either the macros, or a custom component?
Also you could make use of container events to set some defaults of some kind when it's being resolved (https://laravel.com/docs/5.6/container#container-events)?

[kaidoj]

@ragingdave
Let say im using a package that has alias Form and now i install new package that has also alias Form. Now my old alias is not working so the app fails. Yes, i could change the alias on the new package by just doing it manually. But why? if we have auto discovery why not make it fully automated using somekind of order that is taken from composer packages order. Im not saying we have to use that. Like you said i can use plenty of ways, but why? Point of auto-discovery is to load packages automatically so i do not have to make any more coding moves. If you get what i mean. Am i getting it wrong, why auto-discovery was implemented?

[ragingdave]

I don't thin kyou are getting it wrong as to why autod-discovery exists in the first place, but I think you are asking it to be too intelligent. If we take order into account, there are just far too many edge cases, between aliases or providers, to cover successfully. What if you need a provider from one package but an alias from another as it seems like you might here. Well which one takes priority? It heavily depends on your intention, which can different project to project, and developer to developer. The old saying of KISS, I think truly drove the simplicity of the auto-discovery.

I would even go so far as to argue that if you are including 2 packages that have the same alias and serve the same function but slightly differently then it is your job as the developer to weed out your very specific use case for including 2 nearly identical packages. Even further, as I said before for this specific example case, what can't you accomplish via extend or resolving event that requires this very unique situation?

[kaidoj]

@ragingdave
Yes you give some good arguments but my problem was and is with laravel native packages that are not third party like laravelcollective that is included by default. Usually third party plugins that have same alias are overriding or extending laravel package. Can't we maby do it that third party packages are loaded after laravel default/native packages? What you think of that idea? i think this is far better solution.

[crynobone]

I personally against 3rd party packages to declare auto discovery unless it a plug-n-use or development only packages.

You could use laravie/html which is essentially a fork of laravelcollective/html without auto discovery.

[kaidoj]

@crynobone but why are you against it? I mean third party as in packages that extend laravel packages like laravelcollective. I have made some packages to use it and i think it's awesome and easy. I do not have to do any extra moves for using that package after composer update.

[crynobone]

@kaidoj

The concerns has been voiced out before and the expected solution to the problem is to disable auto discovery, see #19420 (comment)

I personally against 3rd party packages to declare auto discovery unless it a plug-n-use or development only packages.

It is awesome for certain packages as I mention above. If you working with packages that some if not most people need to extends you be facing the same problem and the solution is disable auto discovery. Is that awesome?

[kaidoj]

Okay seems like disable is the only way. This is not the way i would go. I will close this issue then, because it has been addressed already as in referenced above.