Composer install causes fatal error

Description

Since the vendor folder was removed v0.13.0 (https://github.com/AxeWP/wp-graphql-gravity-forms/pull/427) after plugin installation composer install command form the plugin folder causes PHP Fatal error due to missing getFacadeAccessor method. Obviously rolling back to previous plugin version that contains vendor folder, solves the issue and works as a temporary workaround.

Steps to reproduce

Install the plugin composer require harness-software/wp-graphql-gravity-forms
cd to plugin folder and run composer install

Additional context

I am running Bedrock WP installation and all relevant plugins to this issue (WPGraphQL, Gravity Forms and wp-graphql-gravity-forms) are installed as mu-plugins.

[20-Jun-2024 07:30:33 UTC] PHP Fatal error:  Uncaught RuntimeException: Facade does not implement getFacadeAccessor method. in /path/to/site/root/bedrock/web/app/mu-plugins/wp-graphql-gravity-forms/vendor/illuminate/support/Facades/Facade.php:178
Stack trace:
#0 /path/to/site/root/bedrock/web/app/mu-plugins/wp-graphql-gravity-forms/vendor/illuminate/support/Facades/Facade.php(166): Illuminate\Support\Facades\Facade::getFacadeAccessor()
#1 /path/to/site/root/bedrock/web/app/mu-plugins/wp-graphql-gravity-forms/vendor/illuminate/support/Facades/Facade.php(255): Illuminate\Support\Facades\Facade::getFacadeRoot()
#2 /path/to/site/root/bedrock/web/app/themes/gadoe/config/app.php(182): Illuminate\Support\Facades\Facade::__callStatic('defaultAliases', Array)
#3 /path/to/site/root/bedrock/vendor/roots/acorn/src/Roots/Acorn/Bootstrap/LoadConfiguration.php(63): require('/Users/jdurkaj/...')
#4 /path/to/site/root/bedrock/vendor/roots/acorn/src/Roots/Acorn/Bootstrap/LoadConfiguration.php(36): Roots\Acorn\Bootstrap\LoadConfiguration->loadConfigurationFiles(Object(Roots\Acorn\Application), Object(Illuminate\Config\Repository))
#5 /path/to/site/root/bedrock/vendor/roots/acorn/src/Illuminate/Foundation/Application.php(263): Roots\Acorn\Bootstrap\LoadConfiguration->bootstrap(Object(Roots\Acorn\Application))
#6 /path/to/site/root/bedrock/vendor/roots/acorn/src/Illuminate/Foundation/Http/Kernel.php(186): Illuminate\Foundation\Application->bootstrapWith(Array)
#7 /path/to/site/root/bedrock/vendor/roots/acorn/src/Roots/Acorn/Bootloader.php(187): Illuminate\Foundation\Http\Kernel->bootstrap(Object(Illuminate\Http\Request))
#8 /path/to/site/root/bedrock/vendor/roots/acorn/src/Roots/Acorn/Bootloader.php(103): Roots\Acorn\Bootloader->bootHttp()
#9 /path/to/site/root/bedrock/web/app/themes/gadoe/functions.php(43): Roots\Acorn\Bootloader->boot()
#10 /path/to/site/root/bedrock/web/wp/wp-settings.php(663): include('/Users/jdurkaj/...')
#11 /path/to/site/root/bedrock/web/wp-config.php(9): require_once('/Users/jdurkaj/...')
#12 /path/to/site/root/bedrock/web/wp/wp-load.php(55): require_once('/Users/jdurkaj/...')
#13 /path/to/site/root/bedrock/web/wp/wp-blog-header.php(13): require_once('/Users/jdurkaj/...')
#14 /path/to/site/root/bedrock/web/index.php(6): require('/Users/jdurkaj/...')
#15 {main}
  thrown in /path/to/site/root/bedrock/web/app/mu-plugins/wp-graphql-gravity-forms/vendor/illuminate/support/Facades/Facade.php on line 178®

Plugin Version

0.13.0

Gravity Forms Version

2.8.12.1

WordPress Version

6.5.4

WPGraphQL Version

1.27.0

Additional enviornmental details

PHP 8.3.6

Please confirm that you have searched existing issues in the repo.

[X] Yes

Please confirm that you have disabled ALL plugins except for Gravity Forms, WPGraphQL, and WPGraphQL for Gravity Forms

[X] Yes
[x] My issue is with a specific 3rd-party plugin.

Thanks for reporting this @jan-clockworkwp !

Our production dependencies don't use Illuminate/Support which means from what I can tell it wasn't included in the previous vendor folder that was stored in the repo.

If you could share a copy of composer.json I could try to reproduce, but based on previous usage of Bedrock, here's some blind suggestions:

Delete the folder copied to mu-plugins and the entire vendor directory and try installing the deps again. (Sometimes composer's cleanup is bad or can get out of sync when install-paths move the library outside of vendor. I'm leaning towards this, since if you're installing the plugins via composer, the deps for wp-graphql-gravity-forms should be in the top-level vendor and not in the plugin directory.)
Try with composer install --no-dev --optimize-autoloader. (It could be possible that there's a conflict between one of your other libraries + and the composer dev deps which shouldn't be included in production anyway and only installed for local development).

Thanks @justlevine for your insights and suggestions. I have removed the downgraded version of the plugin and installed the latest one v0.13.0 without the vendor folder via Composer. After that, as you have suggested, I have installed dependencies with composer install --no-dev --optimize-autoloader, which seems to have done the trick. The only difference from my previous installation is the flags provided to the composer install command. Thanks a lot!

I have one question regarding "since if you're installing the plugins via Composer, the dependencies for wp-graphql-gravity-forms should be in the top-level vendor and not in the plugin directory." Currently, I am installing various 3rd party plugins that are not official WP plugins like wp-graphql-gravity-forms and only installing Composer dependencies in the composer scripts/post-update-cmd section, which obviously results in having vendors within the plugin folder and not in the Bedrock top-level vendors. Is there any issue with that? Other plugins and now even wp-graphql-gravity-forms work just fine with vendors within the plugin folder. I thought that the vendor folder works similarly to the node_modules folder, where dependencies are resolved according to the closest composer.json file, something like package.json for npm.

Thank you!

Currently, I am installing various 3rd party plugins that are not official WP plugins like wp-graphql-gravity-forms and only installing Composer dependencies in the composer scripts/post-update-cmd section, which obviously results in having vendors within the plugin folder and not in the Bedrock top-level vendors. Is there any issue with that? Other plugins and now even wp-graphql-gravity-forms work just fine with vendors within the plugin folder. I thought that the vendor folder works similarly to the node_modules folder, where dependencies are resolved according to the closest composer.json file, something like package.json for npm.

Don't think I'm following.

If you treat your plugins as dependencies (using wpackagist for .org plugins and the repos for non-.org plugins), then each project's composer.json will indeed be used to determine the dependency tree. In this case you should you composer install --no-dev so you only get the production dependencies.

If you want to recursively install the repo dependencies by running composer install --no-dev in a post-install-cwd command or whatever, they will have no knowledge of other composer.json files in other projects, so you'll likely get multiple, and likely conflicting versions of each child dep. I would recommend only using this approach if the repo manually looks for files in a local vendor directory and therefore not compatible for use as a dependency of your project.

@justlevine Thanks for coming back to me so quickly and for the clarification on your statement.

My apologies, I forgot to mention that the composer packages I was talking about are WP official or repo-based plugins taht we use as mu-plugins in most cases. Therefore, they are not meant to be used as project/composer dependencies but rather as WP site dependencies. They should work as "standalone solutions," not relying on dependencies upstream. Thanks for pointing out to consider using --no-dev flag wherever it is needed.

AxeWP / wp-graphql-gravity-forms