Edit: I have updated the “Correct Service Provider” with code provided by William Cahill-Manley in his comments. Thanks for the contribution William!
Watching Laravel 4 grow has been spectacular. Its great to see so many libraries building service providers and facades for Laravel to make them feel more native to the framework. That said, I have noticed small but troubling trend with some packages available for Laravel.
The problem lies in how configuration is handled for the package. Configuration should not be done within the service provider. This concept is not unique to Laravel. However, for this post I will be discussing Laravel packages specifically. Below is simple example of one such package.
At a glance, this file doesn’t appear to require configuration. If you look deeper (or refer to the documentation) you will find the developer can change the geocoding provider and adapter used for geocoding services. The ability to pick which geocoding provider and adapter to use is tremendous in allowing developers to build applications to do exactly what they want. The problem lies in the implementation of such configuration.
As you can see above, to use a different geocoding provider and/or adapter the developer must adjust the service provider to instantiate an alternate geocoding provider and/or adapter. Let’s say the package receives an update and the developer pulls down that update via composer. What happens to the “configuration”? It gets wiped out. Now the application is broken and the developer must update the service provider again. Wash. Rinse. Repeat.
To solve this issue the package should (and now does) implement a publishable configuration file. The configuration file allows the developer to specify which geocoding provider and adapter to use for geocoding services.
So what do the new service provider and configuration look like? Take a look.
Now you may ask, “How do you configure this package?”
Simple. Run the following command after installing the package via composer.
After the configuration has been published the developer can edit it to use the geocoding provider and adapter of their choice. The published configuration file will allow the developer to update via composer without worrying about breaking their application (from a configuration stand point at least).
Configurable packages are a great thing. That said, let’s wear our “best practice hats” and make sure we keep the configuration out of Composers reach.