Read his post. Any ideas why that method no longer exists? Just cause?

I read somewhere that the way the method worked does not match with how L5 works, and that is would be nearly impossible to convert it to L5. Sorry, I can trace back where I read it.

It has nothing to really do with "matching how L5 works." It was just removed because some things it did were outright removed (like package configs being published/namespaced), migration's using --package aren't around, etc.

However, view namespacing is exactly the same, you just need to manually register it instead of using the package helper in the service provider. You can view the old package method to see how it registered the view namespace and just do that in your Service Provider.

This is a step towards getting developers to be mindful of making packages agnostic instead of just for Laravel. In the future once other projects mature and stabilize then some of the things that were removed can be added back in some fashion in a more uniform way between frameworks and vendors.

@ MisterPhilip is spot on, been messing around with it today. For example, if you are using Image Intervention and need a quick workaround until L5 release you can build up the paths for the SP as MP outlines above or if you that is an issue you can just hard code it in until L5 lands. Hard code is 1. remove any "packages" reference in the boot() and then in register(), just plug in the config string or array (yes I know, source code taboo) but until Waldo lands it is a quick and dirty. Example, for Image Intervention :

replace:

    public function register()
    {

        $app = $this->app;

        $app['image'] = $app->share(function ($app) {
            return new ImageManager($app['config']->get('image::config'));
        });
    }

with

    public function register()
    {

        $app = $this->app;

        $app['image'] = $app->share(function ($app) {
            return new ImageManager(['driver' => 'gd']);
        });
    }

@Garbee and when i have a package like Entrust that uses commands to create your own migrations?

Yeah, custom migrations don't seem to work for me aswell.

@bruno.quaresma and @slovenianGooner, custom migrations might be a problem now, but the package creator/owner can create a custom artisan command that adds the tables to the database or publishes the tables to your migration folder. True some handy L4 commands have been removed, but that does not mean that there are no solutions to them ;)

That is true, I completely agree. All in light of trying to make packages non-Laravel depended or independent of the version, which I completely support.

so, how we must process migration in packages for L5 ?

@Kostik create an artisan command that performs the migration, thats all there is to it.

On the Intervention Image note. You can very easily use this without the service provider. So you can still use it without having to make any changes. If you want to use the Cache package with it, then it does need the service provider.

Hmm.. So if I understand everything correctly, Laravel 5 does not support package configuration. That means that packages can now freely choose how they handle configuration. This can be a custom command to publish the configuration files to the config directly (for example in a subdirectory structure, using the Laravel 4 way) or to somewhere else. Hopefully this will not lead to have configuration files all over the place.

Oh wait.. there is a ConfigServiceProvider. Well, that makes sense.

I've developed a method to bridge packages across without modifying their source code, all you need to do is point to a bridging service provider which handles all the differences. Blog article at @morrislaptop/bridging-laravel-4-packages-to-laravel-5-2081f19643c6" target="_blank">https://medium.com/@morrislaptop/bridging-laravel-4-packages-to-laravel-5-2081f19643c6 and the source code is at https://github.com/morrislaptop/LaravelFivePackageBridges