php-docs-samples: Class 'BeyondCode\DumpServer\DumpServerServiceProvider' not found

@PrimeException I now understand the issue better, after talking to someone on the project. The App Engine build server installs dev dependencies so that if scripts need to be run which are not used in production, the dev dependencies are there.

Because Laravel creates bootstrap/cache/services.php as part of the artisan package:discover command, the beyondcode/laravel-dump-server package is discovered, loaded into services.php, and then fails to load in production.

So the good news is, your dev dependencies are NOT being loaded into production. The bad news is, your services.php file inaccurately reflects the dependencies loaded into the Cloud Build environment.

The best workaround is to run composer remove --dev beyondcode/laravel-dump-server. A more complete workaround would be to add the following to composer.json:

{
    "scripts": {
        "gcp-build": [
            "composer install --no-dev"
        ]
    }
}

This workaround will remove all dev dependencies on the build server.

The correct solution is to run: php artisan config:clear

Running that command created the same error:

The solution for me was to run the following command to install this module: composer require --dev beyondcode/laravel-dump-server

now my website run properly when i downgrade my Laravel version to 5.7.5 i remove beyondcode/laravel-dump-server from my composer.json on Laravel 5.7.6+

this my last working composer.json

{
    "name": "laravel/laravel",
    "description": "The Laravel Framework.",
    "keywords": ["framework", "laravel"],
    "license": "MIT",
    "type": "project",
    "require": {
        "php": "^7.1.3",
        "fideloper/proxy": "^4.0",
        "laravel/framework": "5.7.*",
        "laravel/tinker": "^1.0"
    },
    "require-dev": {
        "filp/whoops": "^2.0",
        "fzaninotto/faker": "^1.4",
        "mockery/mockery": "^1.0",
        "nunomaduro/collision": "^2.0",
        "phpunit/phpunit": "^7.0"
    },
    "autoload": {
        "classmap": [
            "database/seeds",
            "database/factories"
        ],
        "psr-4": {
            "App\\": "app/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/"
        }
    },
    "extra": {
        "laravel": {
            "dont-discover": [
            ]
        }
    },
    "scripts": {
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate --ansi"
        ],
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ]
    },
    "config": {
        "preferred-install": "dist",
        "sort-packages": true,
        "optimize-autoloader": true
    },
    "minimum-stability": "dev",
    "prefer-stable": true
}

Using the flexible environment also resolves the issue because the flexible environment does not install development dependencies by default, like it’s supposed to.

Development dependencies should never be installed by default and any workarounds should be to install development dependencies, not prevent their installation.

This is a bug, regardless if someone “intended” to do it.

On Fri, Feb 1, 2019, 20:36 Brent Shaffer <notifications@github.com wrote:

@PrimeException https://github.com/PrimeException I now understand the issue better, after talking to someone on the project. The App Engine build server installs dev dependencies so that if scripts need to be run which are not used in production, the dev dependencies are there.

Because Laravel creates bootstrap/cache/services.php as part of the artisan package:discover command, the beyondcode/laravel-dump-server package is discovered, loaded into services.php, and then fails to load in production.

So the good news is, your dev dependencies are NOT being loaded into production. The bad news is, your services.php file inaccurately reflects the dependencies loaded into the Cloud Build environment.

The best workaround is to run composer remove --dev beyondcode/laravel-dump-server. A more complete workaround would be to add the following to composer.json:

{ // … “scripts”: { // … “gcp-build”: [ “composer install --no-dev” ] } }

This workaround will remove all dev dependencies on the build server.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GoogleCloudPlatform/php-docs-samples/issues/736#issuecomment-459922263, or mute the thread https://github.com/notifications/unsubscribe-auth/AqB81QNi_hGWZmBmwX7EBMIog5SyA1iSks5vJOu0gaJpZM4XbawP .

There is a bug in “update-vendor-directory” in app engine that runs composer update and installs development dependencies regardless of settings.

You should never update production code, that’s why the lock file exists.

The build script needs to be changed from “composer update” to “composer install --no-dev”

I submitted a bug report and they claimed that updating and installing development dependencies in production is intended behavior.

They clearly have no idea what they’re doing.

On Fri, Feb 1, 2019, 18:02 Brent Shaffer <notifications@github.com wrote:

I had to include beyondcode/laravel-dump-server in the require section, as I have been installing production dependencies with composer require –no-dev.

Can anyone explain to me why a dev dependency is required in production? I may have confugred something wrong.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GoogleCloudPlatform/php-docs-samples/issues/736#issuecomment-459897745, or mute the thread https://github.com/notifications/unsubscribe-auth/AqB81csADEhNXmNV0jD84DSm8Ea9DILGks5vJMeHgaJpZM4XbawP .