0

this one has me stumped. I'v git cloneed my repo on Digital Ocean (LEMP stack) and checked out the development branch. All good at this point. Then I do a composer install to install the deps, this dies with:

PHP Fatal error:  Class 'App\MyApp\Api\Transformers\ProjectTransformer' not found 
in /home/greg/MyApp/app/Providers/DatabaseServiceProvider.php on line 67

The DatabaseServiceProvider has a use statement at the top like:

use App\MyApp\Api\Transformers\ProjectTransformer;

This is a laravel 5 project for what it's worth. The DatabaseServiceProvider.php has the namespace namespace App\Providers; The contents of the ProjectTransformer that composer is complaining about is:

<?php namespace App\MyApp\Api\Transformers;

class ProjectTransformer extends Transformer
{
    /**
     * @var array
     */
    protected $visible_fields = [
        'id',
        'title',
        'client_id',
        'division_id',
        'project_manager_id',
        'probability',
        'total_contract_value',
        'description',
        'devs'
    ];
}```

So, composer is stating that I'm using ProjectTransformer in DatabaseServiceProvider and that can't be found. The file absolutely exists, the namespaces appear to be correct...what else am I missing? The other odd issue is that I can composer install this branch from scratch locally (on homestead) with no issue. Only on digital ocean is it complaining. Thanks for any advice!

Greg
  • 6,453
  • 9
  • 45
  • 61
  • Could it be a file permission problem? – zeratulmdq May 12 '15 at 16:02
  • Thanks for the response @zeratulmdq, doesn't seem to be a file permission issue, all files are owned by my user, and live in my home folder. Other files in the same directory seem to load as expected. – Greg May 12 '15 at 16:09

1 Answers1

1

In the shell, try this:

composer install --no-scripts

If that runs successfully, then try it again without the --no-scripts tag.

The --no-scripts tag will prevent composer from running any of the Laravel-specific set up/tear down scripts that are usually run as part of the composer operations. The error message you're seeing is likely due to the fact that your Laravel installation is not completely set up yet (which is not surprising, since you're trying to install it in a new place).

It's kind of a chicken-and-egg problem: the autoloader is not set up yet so it can't resolve the namespaces. But it can't set up the autoloader because it fails because Laravel is complaining that it can't resolve the appropriate namespaces.

Running composer without the scripts will give composer a chance to do its work - install the appropriate packages, initialize the autoloader - without failing because Laravel can't find the packages it needs. Then, once composer has had a chance to do it's thing, you can run it again and Laravel will find what it needs.

Kryten
  • 15,230
  • 6
  • 45
  • 68
  • So the --no-scripts flag allows composer to finish it's work. Removing the flag brings the error back. I'm certain now that I'm missing *something* or something is misspelled, but I can't for the life of me track it down. I appreciate the response @kryten! – Greg May 12 '15 at 20:56
  • Weird. Here's a thought: on your local machine clone the repository from its origin into a temporary location. Then run `diff --brief -r old_repo/ new_repo/`. (from [this answer](http://stackoverflow.com/a/4997724/2008384))This will give you a list of files which differ between the two repositories (including files which may be missing in one or the other) – Kryten May 12 '15 at 20:59
  • Thanks @Kryten! Heading home from work and will give this a shot tonight. Appreciate you taking the time to respond! – Greg May 13 '15 at 02:06
  • So bizarre, I rsync'd the project folder from digital ocean to my local laravel homestead install. Ran composer install and it finishes without issue. So there is something specific to DO it seems that would be causing the issue...now to narrow down what that is... – Greg May 13 '15 at 05:24
  • Is there something that you're NOT committing to your repository? That wouldn't be copied to DO via a `git clone`. – Kryten May 13 '15 at 15:12
  • Not that I'm aware of, the file it's complaining about is in the branch I'm currently check out in. I can `vi path/to/myfile.php` and it's all good. No typos and namespaces are all imported correctly. So as a test I destroyed the box and created a new droplet with the LAMP stack. Same server setup otherwise, and running `composer update` installed all deps as expected, no errors. – Greg May 13 '15 at 15:38