1

After updating to Laravel 5.7, I'm all of a sudden experiencing this error when I push to my testing server: "ReflectionException: Class config does not exist".

I don't experience it in my dev environment.

I took the steps outlined here: Laravel Dusk - Class config does not exist

I don't have any spaces in my .env file -- I've gone through it line-by-line 4 times.

I'm not using Dusk for anything yet -- (side note that might be helpful to someone stumbling like I was: at first I ran into problems where Dusk was telling me not to use Dusk in prod. It turned out that was because my deployment scripts weren't moving my .env file - if no .env file exists it throws the same error.)

I'm running:

  • PHP 7.1.26
  • Laravel/Framework 5.7.24
  • Laravel/Dusk 4.0

Composer.json:

    "require": {
        "php": ">=7.1.3",
        "laravel/framework": "5.7.*",
        "fideloper/proxy": "^4.0",
        "cartalyst/sentinel": "2.0.*",
        "guzzlehttp/guzzle": "~6.0",
        "imgix/imgix-php": "^1.1",
        "Jasekz/Laradrop":"1.*",
        "browner12/helpers": "^1.0",
        "mtdowling/jmespath.php":"2.4",
        "davejamesmiller/laravel-breadcrumbs": "5.*",
        "league/flysystem-aws-s3-v3": "~1.0",
        "laravel/passport": "~7.0",
        "laravel/tinker": "~1.0",
        "facebook/webdriver": "^1.6",
        "laravelcollective/html": "^5.7"
    },"require-dev": {
        "fzaninotto/faker": "~1.4",
        "mockery/mockery": "0.9.*",
        "phpunit/phpunit": "~7.3",
        "symfony/css-selector": "3.1.*",
        "symfony/dom-crawler": "3.1.*",
        "reliese/laravel": "^0.0.13",
        "laravel/dusk": "^4.0",
        "filp/whoops": "~2.0"
    },

I've tried composer dump-autoload to no avail. I attempted to switch phpunit versions with no luck.

Aaron
  • 1,575
  • 10
  • 18
Kevin Foster
  • 139
  • 1
  • 12

2 Answers2

2

After three days of racking my brain, I figured out my dumb mistake and thought I'd share.

My situation was this:

  1. I had previously committed the vendor folder to my repo because I was deploying from my repo without a build step.
  2. I now have a deployment pipeline set up that compiles and deploys my code when I commit to specific branches.
  3. I have composer update as a command within that pipeline, so decided it was time to follow best practices and add /vendor to my .gitignore file.
  4. I did not delete the /vendor folder from my repo before adding it to my .gitignore file.
  5. This resulted in the /vendor folder getting locked into my repo, and not deleted from it.

I had taken all kinds of actions trying to figure out what was going on with no luck. I tried downloading the version that was on the server onto my local machine, and ran into the same problem.

TL;DR:

Finally, I stumbled across something that recommended to simply delete the /vendor folder, and then run composer install to refresh the whole vendor folder. That did the trick for me anyway. It seems like the error message for this particular problem isn't very guiding, but that's probably because no one expected anyone to be so dumb as to completely disregard the guidance of "don't commit the/vendor folder to your repo". So it seemed to be stemming from a dependency mismatch that wasn't getting resolved on composer update for my scenario.

Kevin Foster
  • 139
  • 1
  • 12
1

I had the same problem. simply removed files in bootstrap/cache/ and problem solved.

cd bootstrap/cache/
rm -rf *.php
mohammadreza khalifeh
  • 1,510
  • 2
  • 18
  • 32