Can you please confirm that your file app/Providers/RouteServiceProvider.php has the <?php namespace Auburntree\Providers; namespace at the top?

Also does your application have any sensitive information? Not talking about database, i mean code wise, if not, would you care to email it to me, zipped? I would give it a try on debugging it for you if you want.

Sorry about the delay.

I have tried using L5 with namespace auburntree which I have applied using app:name. I have also tried L5 with just the native App name space.

I have not gotten as far as adding any sensitive data.I get the introductory home page but then it fails when applying the upgrade instructions under "controller".
L5 also fails when you use app:name or clear-compile.

@vincej your first issue is putting me in the same category of @bashy and @bestmomo , I wish ... lol

So I can kind of replicate the problem. It is definitely a compile problem, but cannot pickup exactly where. It is a compile sequence generation problem with services.json and classmap.php.

Here is the issue:

1. If I run php artisan optimize it will regen autoload_classmap.php iand break something in the Service Provider load sequence.
2. Example, In my case I'm unable to load my translator view composer using register in my ServiceProvider, but pretty much all of them fail silently i.e. no error in php artisan commands or compose diag.
3. You can delete services.json and classmap.php and try to regen, but it will keep failing. I think it has something to do with view render as you can get it work work if all you is return a string in class e.g. return “nolros”; will work, but as soon as you attempt to load a blade file it fails.
4. The solution is to get the app up and running so it can update the 2 files. In my case I did the following: 4.1 load up a blade that uses my TranslatorDecorator.php but find any ServiceProvider that will touch the services.json and classmap.php 4.2 I then comment out all logic in the TranslatorDecorator, but add in a boot() method with a very basic command, in my case the boot below. 4.3 I then load the view again which forces an update on services.json and classmap.php and after that I can return all my code to normal and everything works fine as long as I don’t run php artisan optimize

EDIT: Ok, the problem is service.json

If I do a file comparison I can see that the php artisan command lines are building the file incorrectly. Too much too put into this message but it is not eager loading certain ServiceProviders, but moving them to deferred which is a problem. So when you touch the file through app code it builds it the right way. In my case it loading the decorator into defer and removing the translator class so the decorator becomes the root class.

 // I can then remove all of this after the touch
  public function boot()
    {
        View::composer('auth.register.start', TranslatorComposer::class);
    }

My normal register , below, will fail until I touch the files.

    private function registerAuthComposer()
    {
$this->app->make('view')->composer('auth.register.start', TranslatorComposer::class );
$this->app->make('view')->composer('auth.login', TranslatorComposer::class );
    }

@nolros many thanks - you are generous with your skill and time, and you never judge someone with lesser skills than yourself, just like bashy and bestmomo. Plus you have umpteen award points !

Thank you for your effort and your success in replicating the issue. I will admit that I don't fully follow your description as, as the moment, I am not getting past the first steps of upgrading my L4 code, or even just changing the namespace, as per your 3 step plan on page 1. I will try to give it a good study but at the moment, 9.30pm with a couple glasses of wine .. and well.

Just curious, Where are you located ? Many Many thanks !

I'm located in Park City, Utah, but just finished a 2 year assignment in Toronto. btw, as per my edit the problem is services,json file. php artisan is screwing up the write sequence, dont use php artisan.

Here might be easy workaround for you. Install a new version L5. Go into your storage/ framework find services.json, copy it to another location on your hard drive then do whatever you want to your L5 and once you have it all coped across, etc, then copy back your service.json file and overwrite whatever is there. See if that works, if not then run composer dumpautoload - DO NOT RUN php artisan

Many thanks for the more understandable fix. Coming from Codeigniter to Laravel is like going from a tri-cyle to an airbus.

Question: when you say do not run artisan - do you mean ever ??

sorry what I meant is don't run optimize or clear-compile, anything that compiles / regens services.json from the command line. The rest should work fine i.e make, etc. if you do run it and something fails then copy back the services.json file (which I have no really tested).

The real solution is to get the app (Laravel app code vs. artisan) to build the services.json file which can be anything simple like the example above. You can run composer dumpauotload to regen classmap.php. The problem, in my case, is that php artisan creates a services.json file that screws up the SP load. I also inserts a when line that will ensure some of them fail silently which means your will get a different error message because it has simply decided not to load a / a set of SPs.

In my case it was a composer issue which led to me to the SP which then led me to the services.json file. You can easily see the problem when you compare the before and after files. If you have PhpStorm compare them and you will see the logic problem, a very easy file to read.

Ok - I'll give it a try on Monday. I have Storm. Do you agree that this should not be happening ?

@vincej yes definitely a bug.

Great work guys, this thread was a pleasure to read!

I'm getting this error as well, but in connection with a 3rd-party composer package.

Here's what I do to reproduce:

1. Comment out the service provider entry in /config/app.php.
2. Run composer dump-autoload -o and composer update. Everything checks out.
3. Uncomment the entry from step #1, run step #2 again, and it crashes.

As a work-around I am able to get my L5 app to work by commenting out the entry from step #1, running step #2, then enabling the ServiceProvider entry again, but now making sure NOT TO RUN composer update again. This is not a viable solution of course, but let's me keep working until this issue is sorted out.

@mikebronner

Hi Mike - I don't have the answer but here is something posted by @JarekTkaczyk which could be very helpful.

https://laracasts.com/discuss/channels/general-discussion/l5-with-psr-4-package

Please let us know as it has been a mystery and the source of some debate.

cheers !

With some help from my college @adamwathan we were able to narrow down my issue to an incorrect PSR-4 declaration in the package's composer.json file. Your issue sounds like it has nothing to do with 3rd-party packages though, so this probably isn't the answer that will help you.

The package developer originally had set up their package with a PSR-0 folder structure, but then changed it to PSR-4 without updating the target folder.

Problem:

"autoload": {
  "psr-4": {
    "Package\\Namespace": "src"
  }
}

Solution:

"autoload": {
  "psr-4": {
    "Package\\Namespace": "src/Package/Namespace"
  }
}

@vincej I had a similar issue as well, after the step:

In your app/Providers/RouteServiceProvider.php file, set the namespace property to null.

What fixed it for me is I had added my old filters into the boot function of RouteServiceProvider, but missed this next step:

Add use Illuminate\Support\Facades\Route; in the app/Providers/RouteServiceProvider.php in order to continue using the Route Facade.

Once I added the reference, it worked.

Note that I did set the namespace to null as instructed in the Laravel 5 upgrade instructions.

I am having this exact same problem, down to the exact error code and line number.

Did you ever find a solution? I used this guide and this is where I ended up, that seems wrong: https://laravel.com/docs/5.0/upgrade#upgrade-5.0

I got the exact same issue. I didn't hit the issue in development, but I did hit it once I deployed the code. The difference was I developed on a windows machine and deployed to a linux machine. My filename was BackendServiceProvider, but in config/app.php I had BackEndServiceProvider (with a capital E). Windows pathnames are case insensitive, while Linux pathnames ARE case sensitive.