Closed leewillis77 closed 7 months ago
Can confirm. Also happening in my github ci setups
Oops. Should be fixed now. https://github.com/BrianHenryIE/strauss/commit/7a0a927835d50e5db8f0a277fe43df44e430eedc
Thanks for the reply here. While v0.19.0 now no longer throws warnings to the console, autoloading is still broken with v0.19.0 versus v0.17.0 - ie this step in the reproduction:
$ php test.php // Still works
$ composer run phpmd // Does not work under strauss v0.19.0, and throws a Class not found error, despite the class being present under the vendor/ folder
I seem to have that fixed now. I was missing /
in a path.
https://github.com/BrianHenryIE/strauss/commit/07c4945864bc0381919380bb0a0affb5702d162d
Confirming that v0.19.1 resolves the issues we were having - thanks!
Version 0.18.0 contains a change which I believe is breaking strauss in my project:
With strauss v0.17.0 the output of
composer install
[which triggers strauss] ends as follows and everything works as expected:The same configuration run against strauss v0.18.0 throws a bunch of warnings to the console and yields a broken project:
After the install is run, autoloading appears broken for some items, e.g.
Fatal error: Uncaught Error: Class 'Composer\XdebugHandler\XdebugHandler' not found
To reproduce the issue, follow the process below which
strauss
invoking either v0.17.0 or v0.18.0. Everything works as expected under v0.17.0, but fails under v0.18.0:Everything looks good at this point.
At this point strauss v0.18.0 will throw a bunch of PHP warnings and notices to the console, and autoloading will be broken.
Oddly, in my build pipeline, everything fails after the initial install, but I couldn't reproduce that on my local machine, and a
composer install
thencomposer update
is required before things break. Probably just a difference in my actual repo vs the example one I put together, but not quite sure what that might be.