### **As Bootstrapper** ### A Laravel service provider is a class that registers IoC container bindings. In fact, Laravel ships with over a dozen service providers that manage the container bindings for the core framework components. Almost every component of the framework is registered with the container via a provider. A list of the providers currently being used by your application can be found in the ``providers`` array within the ``app/config/app.php`` configuration file. A service provider must have at least one method: ``register``. The ``register`` method is where the provide binds classes to the container. When a request enters your application and the framework is booting up, the ``register`` method is called on the providers listed in your configuration file. This happens very early in the application life-cycle so that all of the Laravel services will be available to you when your own bootstrap files, such as those in the ``start`` directory, are loaded. > ### **Register Vs. Boot** ### > > Never attemp to use services in the ``register`` method. This method is only for binding objects into the IoC container. All resolutions and interaction with the bound classes must be done inside the ``boot`` method. > Some third-party packages you install via Composer will ship with a service provider. The package's installation instructions will typically tell you to register their provider with your application by adding it to the ``providers`` array in your configuration file. Once you've registered the package's provider, it is ready for use. > ### **Package Providers** ### > > Not all third-party packages require a service provider. In fact, no package requires a service provider, as service providers generally just bootstrap components so they are ready for use immediately. They are simply a convenient place to organize bootstrap code and container bindings. > Not every provider that is listed in your ``providers`` configuration array will be instantiated on every request. This would be detrimental to performance, especially if the services the provider registers are not needed for the request. For example, the ``QueueServiceProvider`` services are not needed on every request, but only on requests where the queue is actually utilized. In order to only instantiate the providers that are needed for a given request, Laravel generates a "service manifest" that is stored in the ``app/storage/meta`` directory. This manifest lists all of the service providers for the application, as well as the names of the container bindings they register. So, when the application asks the container for the ``queue`` container binding, Laravel knows that it needs to instantiate and run the ``QueueServiceProvider`` because it is listed as providing the ``queue`` service in the manifest. This allows the framework to lazy-load service providers for each request, greatly increasing performance. > ### **Manifest Generation** ### > > When you add a service provider to the ``providers`` array, Laravel will automatically regenerate the service manifest file during the next request to the application. > As you have time, take a look through the service manifest so you are aware of its contents. Understanding how this file is structured will be helpful if you ever need a debug a deferred service provider.