Closed rmdefi closed 3 years ago
Please report this on https://github.com/Ocramius/PackageVersions and link the issue here so that we can sync the code if needed later on.
@rmdefi please migrate to https://getcomposer.org/doc/07-runtime.md#installed-versions where possible, which matches reality better. That said, if you run install incl dev packages then dump --no-dev, IMO you should be seeing dev packages, because they are there. It's just such a broken composer usage pattern to do this.. Run install --no-dev if you don't want dev packages.
I don't use it, it is a transitive dependency. I will just use my workaround.
@rmdefi ok but so I understand things better, may I know what is the use case of running dump --no-dev
vs install --no-dev
?
To re-generate an optimized classmap, if the dependencies didn't change it is a lot faster than install. (of course, dumpautoload must be called with the same parameters than a previous install)
Ok I see, thanks.
Now that I think about it, a better workaround may be to execute dumpautoload with the --no-scripts option, as the list of dependencies didn't change.
When running
composer dumpautoload --no-dev
(using composer 2.0.9), the generated Versions.php contains the dev dependencies. (withcomposer install --no-dev
, dev dependencies are ignored, as expected)I think the problem is that the environment variable COMPOSER_DEV_MODE is only set by composer's Installer, and not by the AutoloadGenerator.
Instead of relying on that environment variable, you could use the isDevMode() method from the Event class, if I am not mistaken it was already available in composer 1.9
My workaround is to run dumpautoload while explicitly setting the environment variable:
COMPOSER_DEV_MODE=0 composer dumpautoload --no-dev